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
