Hi Jeff, Personally I think Option 1 is not neat so I won't vote for it.
For option 2, if both DR and Router advertise intra-area-prefix-lsa with same from-network metric info contained, it will be a duplication and waste. And also it will be a problem if these two pieces of info have different metric. Which one it should be? As stated below the reason DR do this advertisement is to take advantage of "affecting-all event" so that only one intra-area-prefix-lsa re-originated from DR is enough. Question is when " affecting-all event " happened, maybe all routers need to re-originate their LSAs, including intra-area-prefix-lsa? -----邮件原件----- 发件人: OSPF [mailto:[email protected]] 代表 [email protected] 发送时间: 2014年5月9日 16:58 收件人: [email protected] 主题: OSPF Digest, Vol 99, Issue 12 Send OSPF mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/ospf or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of OSPF digest..." Today's Topics: 1. draft-zzhang-ospf-two-part-metric (Jeffrey (Zhaohui) Zhang) 2. Re: ??: ??: [Isis-wg] [sunset4] IPv6 router IDs (Xuxiaohu) 3. Re: ??: ??: [Isis-wg] [sunset4] IPv6 router IDs (Karsten Thomann) ---------------------------------------------------------------------- Message: 1 Date: Thu, 8 May 2014 19:32:53 +0000 From: "Jeffrey (Zhaohui) Zhang" <[email protected]> To: "[email protected]" <[email protected]> Subject: [OSPF] draft-zzhang-ospf-two-part-metric Message-ID: <fd88f4ce2f6d45bba3eddd16e4709...@bl2pr05mb066.namprd05.prod.outlook.com> Content-Type: text/plain; charset="us-ascii" Hi, Finally I am getting back to this draft after the London meeting. I believe in London we got good understanding of the problem and solution, but need further discussions on how to encode the from-network cost. Option 1 is to encode as an MT metric (slide #9, http://www.ietf.org/proceedings/89/slides/slides-89-ospf-4.pdf). It is straightforward for IPv4, but requires Extended LSA support for IPv6. Option 2 is to encode as Stub Link metric (slide #10). Again it is straightforward for IPv4 but for IPv6 it needs a bit more elaboration that I did not do in London (thanks for Abhay to point out that it is different for IPv6). I am leaning toward Option 2, so that an implementation of this feature does not have to rely on the bigger changes needed for Extended LSA. Before I put the details into the draft and present it in Toronto, I'd like to outline it here to start the discussion. Currently, RFC 5340 states that only the DR will advertise the prefixes for a transit network in the intra-area-prefix-lsa. The proposed change is to allow non-DRs to also do that, with the same reference info as the DR includes for the corresponding prefixes in its intra-area-prefix-lsa, but the metric is set to the from-network cost. For the DR itself, it also sets the metric to its from-network cost (instead of 0) in corresponding prefixes in its intra-area-prefix-lsa. The above assumes that each router independently obtains and advertises its from-network cost. For certain networks that this feature applies to, the underlying protocol (e.g. radio control protocol for a satellite network) may be able to obtain individual from-network costs in a centralized fashion and communicate that out of band to the DR. To take advantage of that, a DR could also advertise the from-network costs for each router in its own intra-area-prefix-lsa, so that when an affecting-all event happens to cause everyone's from-network cost to change, only the DR needs to update its intra-area-prefix-lsa (to reduce the flooding of multiple intra-area-prefix-lsa). To achieve that, when the DR examines each link-lsa associated with the link as described in 4.4.3.9 of RFC 5340, in addition to advertising a single "primary" prefix (out of duplicated ones described in the link-lsa's), different prefix entries are also advertised, with the reference info set to (0x2002, DR's Interface ID, adjacent router's RouterID). The prefix in those entries will all be the same, and the metric is set to the from-network cost. The difference of those additional prefix entries from the "primary" one is that the Reference Advertising Router is an adjacent router but not the DR itself. During SPF calculation, when a router vertex is reached from a network vertex, the rouer's from-network cost is determined the following way: - Look up the intra-area-prefix-lsa advertised by the DR, and look for a matching prefix from the above additional special prefix entries. - If not found, look up the intra-area-prefix-lsa advertised by the router, and look for prefix entry that references the corresponding network lsa. Any prefixes in the intra-area-prefix-lsa with the Referenced Advertising Router not matching the advertiser of the intra-area-prefix-lsa will be ignored for all other purposes. They are only used to obtain the from-network cost. Comments? Thanks. Jeffrey ------------------------------ Message: 2 Date: Fri, 9 May 2014 00:53:26 +0000 From: Xuxiaohu <[email protected]> To: Anton Smirnov <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "George, Wes" <[email protected]>, joel jaeggli <[email protected]>, OSPF List <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [OSPF] ??: ??: [Isis-wg] [sunset4] IPv6 router IDs Message-ID: <1fee3f8f5ccde64c9a8e8f4ad27c19ee08270...@nkgeml512-mbs.china.huawei.com> Content-Type: text/plain; charset="utf-8" Hi Anton, When ISIS capability TLVs are flooded across areas, routers in one area may need to establish correlations between IP addresses and capabilities of routers in another area. For example, assume IS-IS router A in one area has established a L3VPN session with IS-IS router B in another area. When router A needs to send L3VPN traffic to router B via a MPLS-SR tunnel, router A wants to know whether router B (identified by an IP address) has the ELC (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00) before inserting an EL into the MPLS-SR packet. In such case, it needs to contain at least one routable IP address in the capability TLV which has been flooded across area boundaries. In the IPv4 network, the 4-octect router ID field could contain such routable IPv4 address. However, in the IPv6 network, there is no counterpart field to contain a routable IPv6 address. Best regards, Xiaohu > -----????----- > ???: Anton Smirnov [mailto:[email protected]] > ????: 2014?5?8? 22:49 > ???: Xuxiaohu > ??: [email protected]; George, Wes; [email protected]; joel > jaeggli; OSPF List; [email protected]; [email protected] > ??: Re: [OSPF] ??: ??: [Isis-wg] [sunset4] IPv6 router IDs > > Hello Xiaohu, > this whole thread started from George Wes stating that even in > pure > IPv4 world Router ID in many protocols is NOT an IPv4 address. For > convenience it frequently is but on the binary scale "ID guaranteed to > be routable IPv4 address"/"ID is just a number" - the Router ID is NOT an > IPv4 address. > > So, before you convince people that IPv6 Rtr ID is needed you must > start from discussing when and why Router ID is being used as IPv4 > address in pure > IPv4 world. I believe this in other words is what Acee asking you. > > Anton > > > On 05/07/2014 03:10 AM, Xuxiaohu wrote: > > Hi Acee, > > > > The motivation for these two drafts > (http://tools.ietf.org/html/draft-xu-isis-ipv6-router-id-00 and > http://tools.ietf.org/html/draft-xu-ospf-ipv6-router-id-00) is very > simple: the > IPv6 ISIS|OSPF capability TLV/RI-LSA which are used for advertising > router capabilities can be flooded across areas, however, only a > 4-octect router ID is carried in them. As a result, it?s hard for > routers in one area to establish correlations between IPv6 addresses and > capabilities of routers in another area. > For example, assume IS-IS router A in one area has established a L3VPN > session with IS-IS router B in another area over their own IPv6 > addresses. When router A needs to send L3VPN traffic to router B via a > MPLS-SR tunnel, router A wants to know whether router B has the ELC > (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00) before > inserting an EL into the MPLS-SR packet . However, the Capability TLV > originated by router B doesn?t carried an IPv6 address of its own. As a > result, it ! > s hard fo > r router A to know the ELC of router B. > > > > Best regards, > > Xiaohu > > > >> -----????----- > >> ???: Acee Lindem [mailto:[email protected]] > >> ????: 2014?5?6? 21:14 > >> ???: Xuxiaohu > >> ??: joel jaeggli; Acee Lindem; George, Wes; [email protected]; OSPF > >> List; [email protected]; [email protected]; > >> [email protected] > >> ??: Re: [OSPF] ??: [Isis-wg] [sunset4] IPv6 router IDs > >> > >> > >> On May 5, 2014, at 9:48 PM, Xuxiaohu <[email protected]> wrote: > >> > >>> > >>> > >>>> -----????----- > >>>> ???: Isis-wg [mailto:[email protected]] ?? joel jaeggli > >>>> ????: 2014?5?5? 23:55 > >>>> ???: Acee Lindem; Xuxiaohu; George, Wes > >>>> ??: [email protected]; [email protected]; [email protected]; > >>>> [email protected]; [email protected] > >>>> ??: Re: [Isis-wg] [sunset4] IPv6 router IDs > >>>> > >>>> On 5/5/14, 9:28 AM, Acee Lindem wrote: > >>>>> Xiaohu ? what are precisely the situations that you think you > >>>>> need this > >>>>> IPv6 address? > >>>>> Acee > >>>> > >>>> if you're using router-id's as equivalency as an ipv4 unicast addresses. > >>>> you're doing so at your peril because there is zero assurance > >>>> that those actually map. the first time you have a router id of > >>>> 11100000000000000000000000000101 well bummer. > >>> > >>> The IPv6 router ID sub-TLV of the ISIS router capability TLV must > >>> carry a > >> "routable" IPv6 address. If the name of the sub-TLV seems > >> confusing, it can be changed to IPv6 address sub-TLV. > >> > >> Independent of what you call it, you didn?t answer my question. > >> Other than TE, what the use cases where it is needed? > >> > >> Acee > >> > >> > >>> > >>> Best regards, > >>> Xiaohu > >>> > >>>> I don't find the embedding of semantic meaning in router-ids to > >>>> be more compelling then it was in ip addresses. > >>>> > >>>>> From: Xuxiaohu <[email protected] > >> <mailto:[email protected]>> > >>>>> Date: Sunday, May 4, 2014 1:29 AM > >>>>> To: "George, Wes" <[email protected] > >>>>> <mailto:[email protected]>> > >>>>> Cc: OSPF - OSPF WG List <[email protected] <mailto:[email protected]>>, > >>>>> "[email protected] <mailto:[email protected]>" <[email protected] > >>>>> <mailto:[email protected]>>, "[email protected] > >>>>> <mailto:[email protected]>" <[email protected] > >>>>> <mailto:[email protected]>>, "[email protected] > >>>>> <mailto:[email protected]>" <[email protected] > >>>>> <mailto:[email protected]>>, "[email protected] > >>>> <mailto:[email protected]>" > >>>>> <[email protected] > <mailto:[email protected]>> > >>>>> Subject: Re: [Isis-wg] [sunset4] IPv6 router IDs > >>>>> > >>>>> Hi Wes, > >>>>> > >>>>> > >>>>> > >>>>> Thanks for pointing out these two drafts. > >>>>> > >>>>> > >>>>> > >>>>> The motivation for these two drafts > >>>>> (http://tools.ietf.org/html/draft-xu-isis-ipv6-router-id-00 and > >>>>> http://tools.ietf.org/html/draft-xu-ospf-ipv6-router-id-00) is very > >>>>> simple: the IPv6 ISIS|OSPF capability TLV/RI-LSA which are used for > >>>>> advertising router capabilities can be flooded across areas, > >>>>> however, only a 4-octect router ID is carried in them. As a result, > >>>>> it?s hard for routers in one area to establish correlations between > >>>>> IPv6 addresses and capabilities of routers in another area. For > >>>>> example, assume IS-IS router A in one area has established a L3VPN > >>>>> session with IS-IS router B in another area over their own IPv6 > >>>>> addresses. When router A needs to send L3VPN traffic to > >>>>> router B > via > >>>>> a MPLS-SR tunnel, router A wants to know whether router B > >>>>> has > the > >>>>> ELC (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00) before > >>>>> <http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00)%20before> > >>>>> inserting an EL into the MPLS-SR packet . However, the Capability > >>>>> TLV originated by router B doesn?t carried an IPv6 address of its > >>>>> own. As a result, it?s hard for router A to know the ELC of router > >>>>> B. > >>>>> > >>>>> > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Xiaohu > >>>>> > >>>>> > >>>>> > >>>>> *???:*George, Wes [mailto:[email protected]] > >>>>> *????:*2014?5?2?1:51 > >>>>> *???:*Xuxiaohu > >>>>> *??:*[email protected] <mailto:[email protected]>; > >>>>> [email protected] <mailto:[email protected]>; > >>>>> [email protected] > <mailto:[email protected]> > >>>>> *??:*Re: [sunset4] IPv6 router IDs > >>>>> > >>>>> > >>>>> > >>>>> I got a bounce-back on all 3 draft aliases, trying again with the > >>>>> authors?s email addresses directly. > >>>>> > >>>>> > >>>>> > >>>>> *From: *<George>, "George, Wes" <[email protected] > >>>>> <mailto:[email protected]>> > >>>>> *Date: *Thursday, May 1, 2014 at 1:42 PM > >>>>> *To: *"[email protected] > >>>>> <mailto:[email protected]>" > >>>>> <[email protected] > >>>>> <mailto:[email protected]>>, > >>>>> "[email protected] > >>>>> <mailto:[email protected]>" > >>>>> <[email protected] > >>>>> <mailto:[email protected]>> > >>>>> *Cc: *"[email protected] > >>>>> <mailto:[email protected]>" > >>>>> <[email protected] > >>>>> <mailto:[email protected]>>, > >>>>> "[email protected] <mailto:[email protected]>" <[email protected] > >>>>> <mailto:[email protected]>> > >>>>> *Subject: *[sunset4] IPv6 router IDs > >>>>> > >>>>> > >>>>> > >>>>> 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 > >>>>> %5 > >>>>> Bidr%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. > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> sunset4 mailing list > >>>>> [email protected] > >>>>> https://www.ietf.org/mailman/listinfo/sunset4 > >>>>> > >>>> > >>> > >>> _______________________________________________ > >>> OSPF mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/ospf > > > > _______________________________________________ > > OSPF mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ospf > > ------------------------------ Message: 3 Date: Fri, 09 May 2014 10:57:54 +0200 From: Karsten Thomann <[email protected]> To: Xuxiaohu <[email protected]>, Anton Smirnov <[email protected]> Cc: "[email protected]" <[email protected]>, "George, Wes" <[email protected]>, "[email protected]" <[email protected]>, joel jaeggli <[email protected]>, OSPF List <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [OSPF] ??: ??: [Isis-wg] [sunset4] IPv6 router IDs Message-ID: <[email protected]> Content-Type: text/plain; charset=UTF-8; format=flowed Hi Xiaohu, I think I've understand your problem now, but please don't call it a Router ID, the router ID must not be an IP address. To avoid any confusion about it please call it a router ip or router address within the TLV. Please correct me if I'm wrong, but if I understand your drafts right you're not requesting a real IPv6 Router ID instead of the (arbitrary) 32bit ID, but a simple TLV to carry the routable IPv6 address of the router which advertises the capability. If I understand it right, we should maybe fix the text of the other rfc to refect that it is an routable IP address, instead of a (possible) arbitrary but unique Router ID. Kind regards Karsten Am 09.05.2014 02:53, schrieb Xuxiaohu: > Hi Anton, > > When ISIS capability TLVs are flooded across areas, routers in one area may > need to establish correlations between IP addresses and capabilities of > routers in another area. For example, assume IS-IS router A in one area has > established a L3VPN session with IS-IS router B in another area. When router > A needs to send L3VPN traffic to router B via a MPLS-SR tunnel, router A > wants to know whether router B (identified by an IP address) has the ELC > (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00) before inserting an EL > into the MPLS-SR packet. In such case, it needs to contain at least one > routable IP address in the capability TLV which has been flooded across area > boundaries. In the IPv4 network, the 4-octect router ID field could contain > such routable IPv4 address. However, in the IPv6 network, there is no > counterpart field to contain a routable IPv6 address. > > Best regards, > Xiaohu > >> -----????----- >> ???: Anton Smirnov [mailto:[email protected]] >> ????: 2014?5?8? 22:49 >> ???: Xuxiaohu >> ??: [email protected]; George, Wes; [email protected]; joel >> jaeggli; OSPF List; [email protected]; [email protected] >> ??: Re: [OSPF] ??: ??: [Isis-wg] [sunset4] IPv6 router IDs >> >> Hello Xiaohu, >> this whole thread started from George Wes stating that even in >> pure >> IPv4 world Router ID in many protocols is NOT an IPv4 address. For >> convenience it frequently is but on the binary scale "ID guaranteed >> to be routable IPv4 address"/"ID is just a number" - the Router ID is NOT an >> IPv4 address. >> >> So, before you convince people that IPv6 Rtr ID is needed you >> must start from discussing when and why Router ID is being used as >> IPv4 address in pure >> IPv4 world. I believe this in other words is what Acee asking you. >> >> Anton >> >> >> On 05/07/2014 03:10 AM, Xuxiaohu wrote: >>> Hi Acee, >>> >>> The motivation for these two drafts >> (http://tools.ietf.org/html/draft-xu-isis-ipv6-router-id-00 and >> http://tools.ietf.org/html/draft-xu-ospf-ipv6-router-id-00) is very >> simple: the >> IPv6 ISIS|OSPF capability TLV/RI-LSA which are used for advertising >> router capabilities can be flooded across areas, however, only a >> 4-octect router ID is carried in them. As a result, it?s hard for >> routers in one area to establish correlations between IPv6 addresses and >> capabilities of routers in another area. >> For example, assume IS-IS router A in one area has established a >> L3VPN session with IS-IS router B in another area over their own IPv6 >> addresses. When router A needs to send L3VPN traffic to router B via >> a MPLS-SR tunnel, router A wants to know whether router B has the ELC >> (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00) before >> inserting an EL into the MPLS-SR packet . However, the Capability TLV >> originated by router B doesn?t carried an IPv6 address of its own. As a >> result, it ! >> s hard fo >> r router A to know the ELC of router B. >>> Best regards, >>> Xiaohu >>> >>>> -----????----- >>>> ???: Acee Lindem [mailto:[email protected]] >>>> ????: 2014?5?6? 21:14 >>>> ???: Xuxiaohu >>>> ??: joel jaeggli; Acee Lindem; George, Wes; [email protected]; OSPF >>>> List; [email protected]; [email protected]; >>>> [email protected] >>>> ??: Re: [OSPF] ??: [Isis-wg] [sunset4] IPv6 router IDs >>>> >>>> >>>> On May 5, 2014, at 9:48 PM, Xuxiaohu <[email protected]> wrote: >>>> >>>>> >>>>>> -----????----- >>>>>> ???: Isis-wg [mailto:[email protected]] ?? joel jaeggli >>>>>> ????: 2014?5?5? 23:55 >>>>>> ???: Acee Lindem; Xuxiaohu; George, Wes >>>>>> ??: [email protected]; [email protected]; [email protected]; >>>>>> [email protected]; [email protected] >>>>>> ??: Re: [Isis-wg] [sunset4] IPv6 router IDs >>>>>> >>>>>> On 5/5/14, 9:28 AM, Acee Lindem wrote: >>>>>>> Xiaohu ? what are precisely the situations that you think you >>>>>>> need this >>>>>>> IPv6 address? >>>>>>> Acee >>>>>> if you're using router-id's as equivalency as an ipv4 unicast addresses. >>>>>> you're doing so at your peril because there is zero assurance >>>>>> that those actually map. the first time you have a router id of >>>>>> 11100000000000000000000000000101 well bummer. >>>>> The IPv6 router ID sub-TLV of the ISIS router capability TLV must >>>>> carry a >>>> "routable" IPv6 address. If the name of the sub-TLV seems >>>> confusing, it can be changed to IPv6 address sub-TLV. >>>> >>>> Independent of what you call it, you didn?t answer my question. >>>> Other than TE, what the use cases where it is needed? >>>> >>>> Acee >>>> >>>> >>>>> Best regards, >>>>> Xiaohu >>>>> >>>>>> I don't find the embedding of semantic meaning in router-ids to >>>>>> be more compelling then it was in ip addresses. >>>>>> >>>>>>> From: Xuxiaohu <[email protected] >>>> <mailto:[email protected]>> >>>>>>> Date: Sunday, May 4, 2014 1:29 AM >>>>>>> To: "George, Wes" <[email protected] >>>>>>> <mailto:[email protected]>> >>>>>>> Cc: OSPF - OSPF WG List <[email protected] <mailto:[email protected]>>, >>>>>>> "[email protected] <mailto:[email protected]>" <[email protected] >>>>>>> <mailto:[email protected]>>, "[email protected] >>>>>>> <mailto:[email protected]>" <[email protected] >>>>>>> <mailto:[email protected]>>, "[email protected] >>>>>>> <mailto:[email protected]>" <[email protected] >>>>>>> <mailto:[email protected]>>, "[email protected] >>>>>> <mailto:[email protected]>" >>>>>>> <[email protected] >> <mailto:[email protected]>> >>>>>>> Subject: Re: [Isis-wg] [sunset4] IPv6 router IDs >>>>>>> >>>>>>> Hi Wes, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks for pointing out these two drafts. >>>>>>> >>>>>>> >>>>>>> >>>>>>> The motivation for these two drafts >>>>>>> (http://tools.ietf.org/html/draft-xu-isis-ipv6-router-id-00 and >>>>>>> http://tools.ietf.org/html/draft-xu-ospf-ipv6-router-id-00) is very >>>>>>> simple: the IPv6 ISIS|OSPF capability TLV/RI-LSA which are used for >>>>>>> advertising router capabilities can be flooded across areas, >>>>>>> however, only a 4-octect router ID is carried in them. As a result, >>>>>>> it?s hard for routers in one area to establish correlations between >>>>>>> IPv6 addresses and capabilities of routers in another area. For >>>>>>> example, assume IS-IS router A in one area has established a L3VPN >>>>>>> session with IS-IS router B in another area over their own IPv6 >>>>>>> addresses. When router A needs to send L3VPN traffic to >>>>>>> router B >> via >>>>>>> a MPLS-SR tunnel, router A wants to know whether router B >>>>>>> has >> the >>>>>>> ELC (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00) before >>>>>>> <http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00)%20before> >>>>>>> inserting an EL into the MPLS-SR packet . However, the Capability >>>>>>> TLV originated by router B doesn?t carried an IPv6 address of its >>>>>>> own. As a result, it?s hard for router A to know the ELC of router >>>>>>> B. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Xiaohu >>>>>>> >>>>>>> >>>>>>> >>>>>>> *???:*George, Wes [mailto:[email protected]] >>>>>>> *????:*2014?5?2?1:51 >>>>>>> *???:*Xuxiaohu >>>>>>> *??:*[email protected] <mailto:[email protected]>; >>>>>>> [email protected] <mailto:[email protected]>; >>>>>>> [email protected] >> <mailto:[email protected]> >>>>>>> *??:*Re: [sunset4] IPv6 router IDs >>>>>>> >>>>>>> >>>>>>> >>>>>>> I got a bounce-back on all 3 draft aliases, trying again with the >>>>>>> authors?s email addresses directly. >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From: *<George>, "George, Wes" <[email protected] >>>>>>> <mailto:[email protected]>> >>>>>>> *Date: *Thursday, May 1, 2014 at 1:42 PM >>>>>>> *To: *"[email protected] >>>>>>> <mailto:[email protected]>" >>>>>>> <[email protected] >>>>>>> <mailto:[email protected]>>, >>>>>>> "[email protected] >>>>>>> <mailto:[email protected]>" >>>>>>> <[email protected] >>>>>>> <mailto:[email protected]>> >>>>>>> *Cc: *"[email protected] >>>>>>> <mailto:[email protected]>" >>>>>>> <[email protected] >>>>>>> <mailto:[email protected]>>, >>>>>>> "[email protected] <mailto:[email protected]>" <[email protected] >>>>>>> <mailto:[email protected]>> >>>>>>> *Subject: *[sunset4] IPv6 router IDs >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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 >>>>>>> %5 >>>>>>> Bidr%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. >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sunset4 mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/sunset4 >>>>>>> >>>>> _______________________________________________ >>>>> OSPF mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/ospf >>> _______________________________________________ >>> OSPF mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/ospf >>> > _______________________________________________ > OSPF mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ospf ------------------------------ Subject: Digest Footer _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf ------------------------------ End of OSPF Digest, Vol 99, Issue 12 ************************************ _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
