Hi Acee, IMHO, segment routing could work together with the RFC3464 VPN. In such case, the segment routing just replace the role of LDP or RSVP-TE of establishing a transport LSP between PE routers.
Best regards, Xiaohu > -----邮件原件----- > 发件人: Acee Lindem [mailto:[email protected]] > 发送时间: 2014年5月9日 20:11 > 收件人: Xuxiaohu > 抄送: Karsten Thomann; Anton Smirnov; [email protected]; > [email protected]; Wes George; Joel jaeggli; OSPF List; > [email protected]; [email protected] > 主题: Re: [Isis-wg] [OSPF] 答复: 答复: [sunset4] IPv6 router IDs > > Xiaohu, > > The reason the use case is confusing is that the term L3VPN is commonly used > to > refer to RFC 4364 VPNs. In your use case, you are hypothesizing something for > Segment Routed L3VPNs that I’m not sure is needed with MPLS. Can you add > some real use cases to your drafts with justification that it is needed? > > Acee > On May 9, 2014, at 5:31 AM, Xuxiaohu <[email protected]> wrote: > > > Hi Karsten, > > > > Your understanding is completely correct. > > > > Best regards, > > Xiaohu > > > >> -----邮件原件----- > >> 发件人: Isis-wg [mailto:[email protected]] 代表 Karsten Thomann > >> 发送时间: 2014年5月9日 16:58 > >> 收件人: Xuxiaohu; Anton Smirnov > >> 抄送: [email protected]; George, Wes; [email protected]; joel > >> jaeggli; OSPF List; [email protected]; [email protected] > >> 主题: Re: [Isis-wg] [OSPF] 答复: 答复: [sunset4] IPv6 router IDs > >> > >> 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 > >> > >> _______________________________________________ > >> Isis-wg mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/isis-wg > > _______________________________________________ > > Isis-wg mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/isis-wg _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
