Re: [Isis-wg] [sunset4] IPv6 router IDs

[joel jaeggli <[e-mail]>]

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.

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%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.
> 
> 
> 
> _______________________________________________
> sunset4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sunset4
>