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

Xuxiaohu <xuxiaohu@huawei.com> Wed, 07 May 2014 01:10 UTC

Return-Path: <xuxiaohu@huawei.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A900B1A049E; Tue, 6 May 2014 18:10:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.952
X-Spam-Level:
X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zy4lD1_kqdKN; Tue, 6 May 2014 18:10:24 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BCD751A03F8; Tue, 6 May 2014 18:10:23 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGL96488; Wed, 07 May 2014 01:10:17 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 7 May 2014 02:08:39 +0100
Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 7 May 2014 02:10:14 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Wed, 7 May 2014 09:10:07 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Acee Lindem <acee@lindem.com>
Thread-Topic: [OSPF] 答复: [Isis-wg] [sunset4] IPv6 router IDs
Thread-Index: AQHPaHqbrKqcAEziXE+afYJntDEJr5syyEpwgAA6qgCAAU39MA==
Date: Wed, 07 May 2014 01:10:07 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827025D@NKGEML512-MBS.china.huawei.com>
References: <CF8CEDD4.2D52B%acee.lindem@ericsson.com> <5367B449.7090304@bogus.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826FEA2@NKGEML512-MBS.china.huawei.com> <EEB7CA30-C044-4A35-AF80-F71CEDF521C9@lindem.com>
In-Reply-To: <EEB7CA30-C044-4A35-AF80-F71CEDF521C9@lindem.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.134]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/YDDQsJUFOVK9OMrRSa0iFa9LaF4
Cc: "isis-wg@ietf.org" <isis-wg@ietf.org>, "George, Wes" <wesley.george@twcable.com>, "fanpeng@chinamobile.com" <fanpeng@chinamobile.com>, joel jaeggli <joelja@bogus.com>, OSPF List <ospf@ietf.org>, "sunset4@ietf.org" <sunset4@ietf.org>, "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>
Subject: [Isis-wg] 答复: [OSPF] 答复: [sunset4] IPv6 router IDs
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 01:10:28 -0000

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 for router A to know the ELC of router B.

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: Acee Lindem [mailto:acee@lindem.com]
> 发送时间: 2014年5月6日 21:14
> 收件人: Xuxiaohu
> 抄送: joel jaeggli; Acee Lindem; George, Wes; sunset4@ietf.org; OSPF List;
> isis-wg@ietf.org; fanpeng@chinamobile.com; lizhenqiang@chinamobile.com
> 主题: Re: [OSPF] 答复: [Isis-wg] [sunset4] IPv6 router IDs
> 
> 
> On May 5, 2014, at 9:48 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
> 
> >
> >
> >> -----邮件原件-----
> >> 发件人: Isis-wg [mailto:isis-wg-bounces@ietf.org] 代表 joel jaeggli
> >> 发送时间: 2014年5月5日 23:55
> >> 收件人: Acee Lindem; Xuxiaohu; George, Wes
> >> 抄送: ospf@ietf.org; fanpeng@chinamobile.com; isis-wg@ietf.org;
> >> sunset4@ietf.org; lizhenqiang@chinamobile.com
> >> 主题: 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 <xuxiaohu@huawei.com
> <mailto:xuxiaohu@huawei.com>>
> >>> Date: Sunday, May 4, 2014 1:29 AM
> >>> To: "George, Wes" <wesley.george@twcable.com
> >>> <mailto:wesley.george@twcable.com>>
> >>> Cc: OSPF - OSPF WG List <ospf@ietf.org <mailto:ospf@ietf.org>>,
> >>> "isis-wg@ietf.org <mailto:isis-wg@ietf.org>" <isis-wg@ietf.org
> >>> <mailto:isis-wg@ietf.org>>, "fanpeng@chinamobile.com
> >>> <mailto:fanpeng@chinamobile.com>" <fanpeng@chinamobile.com
> >>> <mailto:fanpeng@chinamobile.com>>, "sunset4@ietf.org
> >>> <mailto:sunset4@ietf.org>" <sunset4@ietf.org
> >>> <mailto:sunset4@ietf.org>>, "lizhenqiang@chinamobile.com
> >> <mailto:lizhenqiang@chinamobile.com>"
> >>> <lizhenqiang@chinamobile.com <mailto:lizhenqiang@chinamobile.com>>
> >>> 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:wesley.george@twcable.com]
> >>>    *发送时间:*2014年5月2日1:51
> >>>    *收件人:*Xuxiaohu
> >>>    *抄送:*sunset4@ietf.org <mailto:sunset4@ietf.org>;
> >>>    fanpeng@chinamobile.com <mailto:fanpeng@chinamobile.com>;
> >>>    lizhenqiang@chinamobile.com <mailto:lizhenqiang@chinamobile.com>
> >>>    *主题:*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" <wesley.george@twcable.com
> >>>    <mailto:wesley.george@twcable.com>>
> >>>    *Date: *Thursday, May 1, 2014 at 1:42 PM
> >>>    *To: *"draft-xu-isis-ipv6-router-id@tools.ietf.org
> >>>    <mailto:draft-xu-isis-ipv6-router-id@tools.ietf.org>"
> >>>    <draft-xu-isis-ipv6-router-id@tools.ietf.org
> >>>    <mailto:draft-xu-isis-ipv6-router-id@tools.ietf.org>>,
> >>>    "draft-xu-ospf-ipv6-router-id@tools.ietf.org
> >>>    <mailto:draft-xu-ospf-ipv6-router-id@tools.ietf.org>"
> >>>    <draft-xu-ospf-ipv6-router-id@tools.ietf.org
> >>>    <mailto:draft-xu-ospf-ipv6-router-id@tools.ietf.org>>
> >>>    *Cc: *"draft-fan-idr-ipv6-bgp-id@tools.ietf.org
> >>>    <mailto:draft-fan-idr-ipv6-bgp-id@tools.ietf.org>"
> >>>    <draft-fan-idr-ipv6-bgp-id@tools.ietf.org
> >>>    <mailto:draft-fan-idr-ipv6-bgp-id@tools.ietf.org>>,
> >>>    "sunset4@ietf.org <mailto:sunset4@ietf.org>" <sunset4@ietf.org
> >>>    <mailto:sunset4@ietf.org>>
> >>>    *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
> >>> sunset4@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/sunset4
> >>>
> >>
> >
> > _______________________________________________
> > OSPF mailing list
> > OSPF@ietf.org
> > https://www.ietf.org/mailman/listinfo/ospf