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

Uma Chunduri <> Thu, 29 May 2014 22:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C68261A08D6 for <>; Thu, 29 May 2014 15:03:38 -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 iJhrVYDm12ZW for <>; Thu, 29 May 2014 15:03:37 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D333B1A0429 for <>; Thu, 29 May 2014 15:03:36 -0700 (PDT)
X-AuditID: c618062d-f79be6d000006b89-95-53875e85060e
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 07.4B.27529.58E57835; Thu, 29 May 2014 18:21:26 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Thu, 29 May 2014 18:03:25 -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: AQHPeuzeP0s3Tu1IKESSmn17x79kPJtW53NwgABawACAANcKwA==
Date: Thu, 29 May 2014 22:03:25 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A60469152008633F2B447Beusaamb105erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyuXSPn25bXHuwwff3fBYb/mxktzh66D2r xdbzqxgdmD2m/N7I6tFy5C2rx5IlP5kCmKO4bFJSczLLUov07RK4MrYunsBY8Nq84uWDHawN jHf0uhg5OSQETCR6H8xhgrDFJC7cW8/WxcjFISRwlFFi06yV7BDOckaJ+bfWgVWxCehJfJz6 kx3EFhGoltjWPosRxBYWCJGYt3QmG0Q8VOLl6RtQtpPE/rVPwOpZBFQlbjx+CzaHV8BX4t7U NSwQC2YwSsw+Mo8VJMEJlJjWsw1sKCPQSd9PrQFrYBYQl7j1ZD7UqQISS/acZ4awRSVePv7H CmErSuzrn84OUZ8v8Xb6DXaIZYISJ2c+YZnAKDILyahZSMpmISmDiOtILNj9iQ3C1pZYtvA1 M4x95sBjJmTxBYzsqxg5SotTy3LTjQw2MQKj6pgEm+4Oxj0vLQ8xCnAwKvHwKrC2BwuxJpYV V+YeYpTmYFES59W+WRUsJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVHg7bpZC3wyw7YyzXh4 gK3ab5Xoea0zob3lG3gis076vO4zfbcqpHa2fGj5b6s3oYaL+ewDUl7dezDldPrGN+fufn5f uW52yJffXmsUVKbEut6ZtjPv15JSsfimzsn7Sl9y3WaX+iU3o93rXmqRp+pRi31Vr+vueja3 Pfm0+1FZSM//ZsZFxleVWIozEg21mIuKEwH+nprkiwIAAA==
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: Thu, 29 May 2014 22:03:38 -0000


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.