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

Xuxiaohu <xuxiaohu@huawei.com> Mon, 05 May 2014 02:31 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 2FEF31A0209; Sun, 4 May 2014 19:31:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.251
X-Spam-Level:
X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, 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 EZtLOFhLs0UR; Sun, 4 May 2014 19:31:42 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E4B0B1A0204; Sun, 4 May 2014 19:31:40 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDU93245; Mon, 05 May 2014 02:31:36 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 5 May 2014 03:30:06 +0100
Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 5 May 2014 03:31:35 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 5 May 2014 10:31:32 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "George, Wes" <wesley.george@twcable.com>
Thread-Topic: [sunset4] IPv6 router IDs
Thread-Index: Ac9lZd4zbhHa3+wMTomT3AazRGvGkgCB6UTQAAwJqUAAGERfYA==
Date: Mon, 05 May 2014 02:31:31 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826FA7A@NKGEML512-MBS.china.huawei.com>
References: <CF880123.1A50B%wesley.george@twcable.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826F90C@NKGEML512-MBS.china.huawei.com> <F3ADE4747C9E124B89F0ED2180CC814F23D81B50@xmb-aln-x02.cisco.com>
In-Reply-To: <F3ADE4747C9E124B89F0ED2180CC814F23D81B50@xmb-aln-x02.cisco.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: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0826FA7ANKGEML512MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/ePqw25yR7cLOcD6aqvyLmIpiTvY
X-Mailman-Approved-At: Mon, 05 May 2014 08:28:11 -0700
Cc: "sunset4@ietf.org" <sunset4@ietf.org>, "ospf@ietf.org" <ospf@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>, "fanpeng@chinamobile.com" <fanpeng@chinamobile.com>, "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>
Subject: Re: [Isis-wg] [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: Mon, 05 May 2014 02:31:45 -0000

Hi Les,

As you have pointed out, sub-TLV 11 (i.e., the IPv4 TE Router ID sub-TLV) and sub-TLV 12 (i.e., the IPv6 TE Router ID sub-TLV) are TE-specific. Otherwise, there would be no need for defining sub-TLV11 since there has already been an IPv4 router ID field in the IS-IS Router CAPABILITY TLV. Of course, if the WG consensus is that the IPv6 TE Router ID sub-TLV can be reused to address the TE-irrelevant problem as described in the following draft (http://tools.ietf.org/html/draft-xu-isis-ipv6-router-id-00), it’s no problem for me to propose reusing the above sub-TLV, rather than defining a new sub-TLV in the draft.

Best regards,
Xiaohu

发件人: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
发送时间: 2014年5月4日 21:42
收件人: Xuxiaohu; George, Wes
抄送: ospf@ietf.org; isis-wg@ietf.org; fanpeng@chinamobile.com; sunset4@ietf.org; lizhenqiang@chinamobile.com
主题: RE: [sunset4] IPv6 router IDs

Xiaohu –

RFC 5316 already has defined this – see sub-TLVs 11 and 12.

If the concern is that these are defined as TE specific it would be better to make an explicit statement to allow these to be used for purposes other than TE as has been done in RFC 5305 and RFC 6119 than to define a duplicate sub-TLV.

   Les


From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Xuxiaohu
Sent: Sunday, May 04, 2014 1:29 AM
To: George, Wes
Cc: ospf@ietf.org<mailto:ospf@ietf.org>; isis-wg@ietf.org<mailto:isis-wg@ietf.org>; fanpeng@chinamobile.com<mailto:fanpeng@chinamobile.com>; sunset4@ietf.org<mailto:sunset4@ietf.org>; lizhenqiang@chinamobile.com<mailto:lizhenqiang@chinamobile.com>
Subject: Re: [OSPF] [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%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.