Re: [OSPF] 答复: [Isis-wg] 答复: 答复: [sunset4] IPv6 router IDs

[Acee Lindem <[e-mail]>]

Hi Xiaohu, 
Please include the precise use cases as to WHY this is needed OSPF draft.
And by precise, I don't mean just listing MPLS applications, I mean
explaining why you need this routable address above and beyond what is
already advertised. At least in the case of OSPF, I'm not convinced.
Thanks,
Acee 


-----Original Message-----
From: Xuxiaohu <[e-mail]>
Date: Sunday, May 11, 2014 6:44 PM
To: Ericsson <[e-mail]>
Cc: Karsten Thomann <[e-mail]>, Anton Smirnov
<[e-mail]>, "[e-mail]" <[e-mail]>,
"[e-mail]" <[e-mail]>, Wes George
<[e-mail]>, Joel jaeggli <[e-mail]>, OSPF - OSPF
WG List <[e-mail]>, "[e-mail]" <[e-mail]>,
"[e-mail]" <[e-mail]>
Subject: 答复: [Isis-wg] [OSPF] 答复:  答复:  [sunset4]   IPv6 router IDs

>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:[e-mail]]
>> 发送时间: 2014年5月9日 20:11
>> 收件人: Xuxiaohu
>> 抄送: Karsten Thomann; Anton Smirnov; [e-mail];
>> [e-mail]; Wes George; Joel jaeggli; OSPF List;
>> [e-mail]; [e-mail]
>> 主题: 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 <[e-mail]> wrote:
>> 
>> > Hi Karsten,
>> >
>> > Your understanding is completely correct.
>> >
>> > Best regards,
>> > Xiaohu
>> >
>> >> -----邮件原件-----
>> >> 发件人: Isis-wg [mailto:[e-mail]] 代表 Karsten Thomann
>> >> 发送时间: 2014年5月9日 16:58
>> >> 收件人: Xuxiaohu; Anton Smirnov
>> >> 抄送: [e-mail]; George, Wes; [e-mail]; joel
>> >> jaeggli; OSPF List; [e-mail]; [e-mail]
>> >> 主题: 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:[e-mail]]
>> >>>> 发送时间: 2014年5月8日 22:49
>> >>>> 收件人: Xuxiaohu
>> >>>> 抄送: [e-mail]; George, Wes; [e-mail]; joel
>> >>>> jaeggli; OSPF List; [e-mail]; [e-mail]
>> >>>> 主题: 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:[e-mail]]
>> >>>>>> 发送时间: 2014年5月6日 21:14
>> >>>>>> 收件人: Xuxiaohu
>> >>>>>> 抄送: joel jaeggli; Acee Lindem; George, Wes; [e-mail];
>> >>>>>> OSPF List; [e-mail]; [e-mail];
>> >>>>>> [e-mail]
>> >>>>>> 主题: Re: [OSPF] 答复: [Isis-wg] [sunset4] IPv6 router IDs
>> >>>>>>
>> >>>>>>
>> >>>>>> On May 5, 2014, at 9:48 PM, Xuxiaohu <[e-mail]>
>> wrote:
>> >>>>>>
>> >>>>>>>
>> >>>>>>>> -----邮件原件-----
>> >>>>>>>> 发件人: Isis-wg [mailto:[e-mail]] 代表 joel jaeggli
>> >>>>>>>> 发送时间: 2014年5月5日 23:55
>> >>>>>>>> 收件人: Acee Lindem; Xuxiaohu; George, Wes
>> >>>>>>>> 抄送: [e-mail]; [e-mail]; [e-mail];
>> >>>>>>>> [e-mail]; [e-mail]
>> >>>>>>>> 主题: 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 <[e-mail]
>> >>>>>> <mailto:[e-mail]>>
>> >>>>>>>>> Date: Sunday, May 4, 2014 1:29 AM
>> >>>>>>>>> To: "George, Wes" <[e-mail]
>> >>>>>>>>> <mailto:[e-mail]>>
>> >>>>>>>>> Cc: OSPF - OSPF WG List <[e-mail]
>> >>>>>>>>> <mailto:[e-mail]>>, "[e-mail]
>> >>>>>>>>> <mailto:[e-mail]>" <[e-mail]
>> >>>>>>>>> <mailto:[e-mail]>>, "[e-mail]
>> >>>>>>>>> <mailto:[e-mail]>" <[e-mail]
>> >>>>>>>>> <mailto:[e-mail]>>, "[e-mail]
>> >>>>>>>>> <mailto:[e-mail]>" <[e-mail]
>> >>>>>>>>> <mailto:[e-mail]>>, "[e-mail]
>> >>>>>>>> <mailto:[e-mail]>"
>> >>>>>>>>> <[e-mail]
>> >>>> <mailto:[e-mail]>>
>> >>>>>>>>> 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:[e-mail]]
>> >>>>>>>>>     *发送时间:*2014年5月2日1:51
>> >>>>>>>>>     *收件人:*Xuxiaohu
>> >>>>>>>>>     *抄送:*[e-mail] <mailto:[e-mail]>;
>> >>>>>>>>>     [e-mail]
>> >> <mailto:[e-mail]>;
>> >>>>>>>>>     [e-mail]
>> >>>> <mailto:[e-mail]>
>> >>>>>>>>>     *主题:*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"
>> >> <[e-mail]
>> >>>>>>>>>     <mailto:[e-mail]>>
>> >>>>>>>>>     *Date: *Thursday, May 1, 2014 at 1:42 PM
>> >>>>>>>>>     *To: *"[e-mail]
>> >>>>>>>>>     <mailto:[e-mail]>"
>> >>>>>>>>>     <[e-mail]
>> >>>>>>>>>     <mailto:[e-mail]>>,
>> >>>>>>>>>     "[e-mail]
>> >>>>>>>>>     <mailto:[e-mail]>"
>> >>>>>>>>>     <[e-mail]
>> >>>>>>>>>     <mailto:[e-mail]>>
>> >>>>>>>>>     *Cc: *"[e-mail]
>> >>>>>>>>>     <mailto:[e-mail]>"
>> >>>>>>>>>     <[e-mail]
>> >>>>>>>>>     <mailto:[e-mail]>>,
>> >>>>>>>>>     "[e-mail] <mailto:[e-mail]>"
>> >> <[e-mail]
>> >>>>>>>>>     <mailto:[e-mail]>>
>> >>>>>>>>>     *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
>> >>>>>>>>> [e-mail]
>> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sunset4
>> >>>>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> OSPF mailing list
>> >>>>>>> [e-mail]
>> >>>>>>> https://www.ietf.org/mailman/listinfo/ospf
>> >>>>> _______________________________________________
>> >>>>> OSPF mailing list
>> >>>>> [e-mail]
>> >>>>> https://www.ietf.org/mailman/listinfo/ospf
>> >>>>>
>> >>> _______________________________________________
>> >>> OSPF mailing list
>> >>> [e-mail]
>> >>> https://www.ietf.org/mailman/listinfo/ospf
>> >>
>> >> _______________________________________________
>> >> Isis-wg mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/isis-wg
>> > _______________________________________________
>> > Isis-wg mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/isis-wg
>