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

[Acee Lindem <[e-mail]>]

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