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

[Xuxiaohu <[e-mail]>]

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