George, Wes
2014-05-01 17:42:00 UTC
I see that you have submitted two drafts for IPv6 router IDs in ISIS and OSPF, noting that the existing router ID is only 4 octets. This has also come up in IDR for BGP. The authors of that draft are copied. Iâll give you a similar set of feedback to what I gave them -
It is important to distinguish between places where a unique identifier is needed, and by convention an IPv4 address assigned to the device has been used to provide that unique ID, vs. places where the actual IP address has some sort of importance to the protocol (I.e. That information must be available to take action on).
In other words, is the protocol requirement that the ID be unique across some domain, but that the actual value does not matter, or is the protocol requirement that the value must correspond to something on the router? In many of the former cases, the fact that the value isnât relevant has been used to make recommendations that are easier for humans to deal with (I.e. Tying the router ID to an IP address) but that value as a human-readable set of info does not necessarily justify changes to the protocol to support that convention as we move to IPv6.
I would argue that the router ID used in routing protocols must merely be unique, but it doesnât have to be an IP address at all. Thus it is not strictly necessary to create a new field to carry IPv6 addresses when operating without IPv4 addresses on a network. If you believe otherwise, the justification needs to be documented in the draft.
There are many places in IETF protocols where a 32 bit unique identifier is needed, and by convention an IPv4 address has been used. It would be far more useful to write a general draft identifying this problem and discussing several solutions, including simply generating unique IDs manually, systematically generating a random ID, etc. the place for such a draft may be in Sunset4, either as a part of the existing gap analysis draft or as another standalone draft.
There was rather a long discussion about this on IDR, thread here: https://mailarchive.ietf.org/arch/search/?qdr=a&email_list=idr&q=%22%5Bidr%5D+%5Bv6ops%5D+BGP+Identifier%22&as=1&gbt=1
And in the IDR meeting, minutes:
http://www.ietf.org/proceedings/89/minutes/minutes-89-idr (see page 11)
Iâd encourage the authors of these drafts to work together on this.
Thanks,
Wes George
Anything below this line has been added by my companyâs mail server, I have no control over it.
-----------
________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
It is important to distinguish between places where a unique identifier is needed, and by convention an IPv4 address assigned to the device has been used to provide that unique ID, vs. places where the actual IP address has some sort of importance to the protocol (I.e. That information must be available to take action on).
In other words, is the protocol requirement that the ID be unique across some domain, but that the actual value does not matter, or is the protocol requirement that the value must correspond to something on the router? In many of the former cases, the fact that the value isnât relevant has been used to make recommendations that are easier for humans to deal with (I.e. Tying the router ID to an IP address) but that value as a human-readable set of info does not necessarily justify changes to the protocol to support that convention as we move to IPv6.
I would argue that the router ID used in routing protocols must merely be unique, but it doesnât have to be an IP address at all. Thus it is not strictly necessary to create a new field to carry IPv6 addresses when operating without IPv4 addresses on a network. If you believe otherwise, the justification needs to be documented in the draft.
There are many places in IETF protocols where a 32 bit unique identifier is needed, and by convention an IPv4 address has been used. It would be far more useful to write a general draft identifying this problem and discussing several solutions, including simply generating unique IDs manually, systematically generating a random ID, etc. the place for such a draft may be in Sunset4, either as a part of the existing gap analysis draft or as another standalone draft.
There was rather a long discussion about this on IDR, thread here: https://mailarchive.ietf.org/arch/search/?qdr=a&email_list=idr&q=%22%5Bidr%5D+%5Bv6ops%5D+BGP+Identifier%22&as=1&gbt=1
And in the IDR meeting, minutes:
http://www.ietf.org/proceedings/89/minutes/minutes-89-idr (see page 11)
Iâd encourage the authors of these drafts to work together on this.
Thanks,
Wes George
Anything below this line has been added by my companyâs mail server, I have no control over it.
-----------
________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.