Re: [Isis-wg] New Version Notification for draft-xu-isis-routable-ip-address-00.txt

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Thu, 29 May 2014 22:57 UTC

Return-Path: <ginsberg@cisco.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 0DDB41A06D1 for <isis-wg@ietfa.amsl.com>; Thu, 29 May 2014 15:57:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level:
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 lNL6lH-nwG8P for <isis-wg@ietfa.amsl.com>; Thu, 29 May 2014 15:57:50 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDBB21A0469 for <isis-wg@ietf.org>; Thu, 29 May 2014 15:57:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22853; q=dns/txt; s=iport; t=1401404266; x=1402613866; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=CKPZBzYN/aUiLPsMNSweko7e05L1Gj+2VAsv3tOdV5o=; b=aujZqGfaPVB/y9wI1PeZDvafolYhe8xig/JycVnijiT3WEzWrERQDkbb NvfI/Ujy6wdVcMAA140YEFJKYWpe9izLYl4V/cE/yiSVudg/eZUJdb6Vx DzqiWNRXcod8qu0Ba/l3nixMlhxg20R2L6pB0xMvhyx4i1DSvL2rX8qPw Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjEFAJe6h1OtJA2H/2dsb2JhbABZgkJFUljCNwGBDRZ0giUBAQEEDCFKDgQCAQgRBAEBCxYHBzIUCQgCBAESCIg6110XjiE3AQaDJYEVBK0egziCLw
X-IronPort-AV: E=Sophos;i="4.98,936,1392163200"; d="scan'208,217";a="329019382"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-8.cisco.com with ESMTP; 29 May 2014 22:57:44 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s4TMvhU7020652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 May 2014 22:57:43 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.121]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Thu, 29 May 2014 17:57:43 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Uma Chunduri <uma.chunduri@ericsson.com>, Xuxiaohu <xuxiaohu@huawei.com>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Thread-Topic: New Version Notification for draft-xu-isis-routable-ip-address-00.txt
Thread-Index: AQHPeuzeihTQ2LklO0e8Pc7vJrzxl5tW53NwgAATNVCAAXbwgP//uXrg
Date: Thu, 29 May 2014 22:57:43 +0000
Message-ID: <F3ADE4747C9E124B89F0ED2180CC814F23DEF53E@xmb-aln-x02.cisco.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827C902@NKGEML512-MBS.china.huawei.com> <F3ADE4747C9E124B89F0ED2180CC814F23DEB33D@xmb-aln-x02.cisco.com> <1B502206DFA0C544B7A60469152008633F2B447B@eusaamb105.ericsson.se>
In-Reply-To: <1B502206DFA0C544B7A60469152008633F2B447B@eusaamb105.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [128.107.163.140]
Content-Type: multipart/alternative; boundary="_000_F3ADE4747C9E124B89F0ED2180CC814F23DEF53Exmbalnx02ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/rvONr_NgTeRVQU5XJwUwucGTgcs
Subject: Re: [Isis-wg] New Version Notification for draft-xu-isis-routable-ip-address-00.txt
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: Thu, 29 May 2014 22:57:53 -0000

Uma -

The TE Router IDs are defined to be [from RFC5305]:

"a single
      stable address that can always be referenced in a path that will
      be reachable from multiple hops away, regardless of the state of
      the node's interfaces."

i.e. so long as the node is reachable the address advertised by the router ID TLV/sub-TLV is reachable. This satisfies the requirement stated in your draft:

"IS-IS routers
   within one area to find correlations between routable IP addresses
   and capabilities of IS-IS routers within another area."

You don't need multiple addresses.

If you want to discuss the need for multiple addresses and how to correlate a specific address to a specific capability (which I really wish you wouldn't... :)) you are attempting to address a different requirementand you need to write a different draft.

I stand by my opinion that there is no need for the current draft.

   Les


From: Uma Chunduri [mailto:uma.chunduri@ericsson.com]
Sent: Thursday, May 29, 2014 3:03 PM
To: Les Ginsberg (ginsberg); Xuxiaohu; isis-wg@ietf.org
Subject: RE: New Version Notification for draft-xu-isis-routable-ip-address-00.txt

Les,

In-line [Uma]:

--
Uma C.


-----Original Message-----
From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, May 28, 2014 9:58 PM
To: Xuxiaohu; isis-wg@ietf.org<mailto:isis-wg@ietf.org>
Subject: Re: [Isis-wg] New Version Notification for draft-xu-isis-routable-ip-address-00.txt

Xiaohu/Uma -

Regardless of the name, I see no reason for this draft. :-)
RFC 5305 and RFC 6119 define the IPv4 and IPv6 Router ID TLVs. Those RFCs specifically state that the router id MAY be used for purposes other than Traffic Engineering.
RFC 5316 clearly states that the TE Router IDs sub-TLVs in the Router Capability TLV were defined to advertise the TE Router IDs as per RFC 5305/RFC 6119 in cases where domain flooding scope is required - which the original TLVs cannot do. It therefore logically follows that the addresses advertised in the sub-TLVs of the Router Capability TLV have the same uses as the area scoped counterparts. So the premise on which your draft is written:
" TE Router ID sub-TLVs as defined in [RFC5316] ... are specifically designed for
   Traffic-Engineering (TE) purpose."
seems FALSE to me.

[Uma]: As the name itself suggests these are TE router IDs (The Traffic Engineering router ID TLV is TLV type 134 & The IPv6 TE Router ID TLV is TLV type 140) and
             yes these are extended for domain scope in RFC 5316 as "TE Router ID sub-tlvs".
RFC 5305: TLV 134
" If a router does not implement traffic engineering, it MAY add or
   omit the Traffic Engineering router ID TLV.  If a router implements
   traffic engineering, it MUST include this TLV in its LSP.  This TLV
   SHOULD not be included more than once in an LSP."

So I don't think what is stated is FALSE.  These are indeed designed for TE. However I agree, any decent implementation generally emit this TLV if a loopback is provisioned.


Please, let's not needlessly add confusion to the protocol by having multiple sub-TLVs which advertise the same information.

[Uma]: This is a good point. If a loopback is already advertised as "TE router ID TLV" then there is no point in advertising the same through these "Routable IP address" define.
             This can be explicitly stated.
             The point of the draft, as I see is to indicate one or more  routable IP addresses hosted by a node without having to tie up to the current TE Router IDs.