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

Uma Chunduri <> Fri, 30 May 2014 17:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D69A91A09CC for <>; Fri, 30 May 2014 10:23:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lv39RWXqn1Of for <>; Fri, 30 May 2014 10:23:10 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C18C61A09CE for <>; Fri, 30 May 2014 10:23:09 -0700 (PDT)
X-AuditID: c6180641-f79df6d000002de0-fd-53886bd57420
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 41.33.11744.5DB68835; Fri, 30 May 2014 13:30:29 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Fri, 30 May 2014 13:22:57 -0400
From: Uma Chunduri <>
To: "Les Ginsberg (ginsberg)" <>, Xuxiaohu <>, "" <>
Thread-Topic: New Version Notification for draft-xu-isis-routable-ip-address-00.txt
Thread-Index: AQHPeuzeP0s3Tu1IKESSmn17x79kPJtW53NwgABawACAANcKwIAAVsOAgADuqrA=
Date: Fri, 30 May 2014 17:22:56 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A60469152008633F2B5813eusaamb105erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPgu7V7I5gg1t3RS02/NnIbnH00HtW i63nVzE6MHtM+b2R1aPlyFtWjyVLfjIFMEdx2aSk5mSWpRbp2yVwZWx+/JC5oOsYY8XE7nWs DYxbNzJ2MXJySAiYSLRMuMoGYYtJXLi3Hsjm4hASOMooMefTdyYIZzmjRMO8VnaQKjYBPYmP U3+C2SIC1RLb2meBTRIWCJGYt3QmG0Q8VOLl6RtQtp/E4g2/wepZBFQllk57DBbnFfCVaF+8 AswWEpjPJHHwYDGIzQkUn94yhRXEZgS66PupNUwgNrOAuMStJ/OZIC4VkFiy5zwzhC0q8fLx P1YIW0li0tJzrBD1+RLPT16C2iUocXLmE5YJjCKzkIyahaRsFpIyiLiOxILdn9ggbG2JZQtf M8PYZw48ZkIWX8DIvoqRo7Q4tSw33chwEyMwro5JsDnuYFzwyfIQowAHoxIP74KwjmAh1sSy 4srcQ4zSHCxK4rx7rlUFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCMcml8fJD3/NMzhWuy VxxNmPxZRbb25Gcp7jerNhWY9r/JFnOVOMM6afaUd39Oy7Zdcz45VY0767ySQvfqvsiMMNky /+AmzgIff703PDIFS8WSDTw5rS71N3+KsWlxiOGcl6mkb+PaJWY14YXQbcaWGaUyfjO09G+0 +/D7TuFZwJETvcI3UImlOCPRUIu5qDgRAJYkilWMAgAA
Subject: Re: [Isis-wg] New Version Notification for draft-xu-isis-routable-ip-address-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 May 2014 17:23:18 -0000


>"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.

Yes, if TE is supported by the advertising node and RID is present then no need.

> 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.

My main point is precisely this. There are more than one situation where we need a specific address to a specific capability. It's good if we can tie the capability,
but the same can be achieved without having to tie this way (merely allowing multiple addresses would  help greatly, from where we are).

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

:)  ..While we can improve upon this draft; it's clear you have strong reservation about the current draft. Shall discuss more!

Uma C.

From: Uma Chunduri []
Sent: Thursday, May 29, 2014 3:03 PM
To: Les Ginsberg (ginsberg); Xuxiaohu;<>
Subject: RE: New Version Notification for draft-xu-isis-routable-ip-address-00.txt


In-line [Uma]:

Uma C.

-----Original Message-----
From: Isis-wg [] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, May 28, 2014 9:58 PM
To: Xuxiaohu;<>
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.