Re: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols

Julien Meuric <> Wed, 25 October 2017 14:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 71DE91386A2 for <>; Wed, 25 Oct 2017 07:37:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.085
X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5wtXLKU56AOm for <>; Wed, 25 Oct 2017 07:37:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 00024138347 for <>; Wed, 25 Oct 2017 07:37:50 -0700 (PDT)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id A03C6A4423D; Wed, 25 Oct 2017 16:37:49 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTP id 8D9AAA4423C; Wed, 25 Oct 2017 16:37:49 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id 14.3.361.1; Wed, 25 Oct 2017 16:37:49 +0200
From: Julien Meuric <>
To: "Les Ginsberg (ginsberg)" <>
CC: "" <>
References: <> <> <> <> <>
Organization: Orange
Message-ID: <>
Date: Wed, 25 Oct 2017 16:37:48 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Oct 2017 14:37:53 -0000

Hi Les,

My original post was discussing two parallel items:
- my unconditional support to the adoption of
draft-hegde-isis-advertising-te-protocols (irrespective of the decision
about my following proposal),
- a candidate use case, to be discussed "once WG document".

For clarification, let me try to summarize the open questions:

1- Do we need to advertise RFC 3473 support on a per link basis?
You seem to argue that combining RSVP link advertisement and 3473
support as a node advertisement (RFC 5073) may address the issue. Fair
enough, provided implementations do support all necessary TLVs.
[Otherwise, collocated bits are not a big deal: RFC 5073 did not block
on a "qualitative" boundary between the M bit and the G bit.]

2- Should we restrain ourselves from improving an in-progress
specification where presence/absence of advertisement imply a support
that "depends upon the application"?
You say yes, I say no (you say goodbye...). Application-specific
semantics are an error-prone way to convey a basic binary information.
[To map it onto the example above, combining advertisement with
application-specific semantics before linking it to a barely implemented
node-related TLV would clearly limit the number of implementations
actually able to identify if a 3473-compliant RSVP message can be sent
to control a given link.]

3- When the poll in progress concludes, if the rough consensus on "2"
favors explicit capability advertisement, what solution should we progress?
The more I think about it, the more I believe that requesting a flag
allocation (e.g. 0x04) from sub-TLV 19 (created by RFC 5029) deserves to
be considered as part of the solution space for



Oct. 23, 2017 -
> Julien -
> My position on WG adoption of draft-hegde-isis-advertising-te-protocols (opposed) and the reasons why have been stated in an earlier post to the list.
> draft-hegde-isis-advertising-te-protocols is discussing how to signal whether an application which makes use of link attribute advertisements  is enabled on a link. For the purposes of this discussion the application is specifically RSVP.
> Your post is discussing a quite different thing. Given that RSVP is enabled you are asking/suggesting that we might want to also signal certain specific capabilities of RSVP - which is a qualitatively different thing.
> I believe that is out of scope for draft-hegde-isis-advertising-te-protocols (and draft-ietf-isis-te-app).
>    Les
>> -----Original Message-----
>> From: Julien Meuric []
>> Sent: Monday, October 23, 2017 5:16 AM
>> Hi Les,
>> I am not sure I am following you.
>> As per the abstract in draft-hegde-isis-advertising-te-protocols, all I am
>> talking about is "a mechanism to indicate which traffic engineering protocols
>> are enabled on a link in IS-IS." At this stage, are you questioning the
>> relevance of the poll to the IS-IS WG? (In case we really had considered
>> another WG for this I-D, we would certainly have ended up in TEAS, not in
>> CCAMP nor MPLS).
>> In case mentioning the node counterpart is confusing, please ignore RFC
>> 5073.
>> In case joining Chris B's open discussion about renaming the "TE protocol sub-
>> TLV" is not obvious, please do not consider that as a prerequisite to adopt
>> the I-D.
>> You suggest RFC 5029 as a candidate solution for draft-hegde-isis-advertising-
>> te-protocols (section 3). That would save us a sub-TLV codepoint and leave
>> us 14 bits instead of 32. This looks like a reasonable way forward to me.
>> By the way, the suggested value for the sub-TLV in draft-hegde-isis-
>> advertising-te-protocols is already allocated!
>> Shraddha/Chris, could you please drop suggested codepoints from the I-D?
>> Thanks,
>> Julien
>> Oct. 21, 2017 -
>>> Julien -
>>> I think the issue you raise first needs to be discussed in CCAMP (or perhaps
>> MPLS) WG. If there is agreement that this is a problem which needs to be
>> addressed then a draft can be written. Perhaps this is RFC 5073bis - perhaps
>> something else.
>>> As far as link level signaling, in IS-IS there is already provision
>>> for that using link attributes sub-TLV defined in RFC 5029:
>>> ts.xhtml#isis-tlv-codepoints-19of22
>>> If signaling is required to address the issue you raise that would be the
>> most appropriate place to do it.
>>> I don't think your issue is in scope for either draft-hegde-isis-advertising-te-
>> protocols or draft-ietf-isis-te-app.
>>>    Les
>>>> -----Original Message-----
>>>> From: Isis-wg [] On Behalf Of Julien
>>>> Meuric
>>>> Sent: Friday, October 20, 2017 7:15 AM
>>>> Hi,
>>>> I support the adoption of draft-hegde-isis-advertising-te-protocols
>>>> as a foundation for a WG item. A per-link "Capability sub-TLV" (the
>>>> term "protocol" might be too specific here) really adds a missing
>>>> piece after RFC 5073.
>>>> Once WG document, we may discuss an additional use case suggested by
>>>> that RFC: on top of RSVP-TE support, distinguish between 3209-only
>>>> and 3473-capable. Indeed, there are parameters like SRLGs that were
>>>> defined as part of GMPLS extensions: an implementation (wildly)
>>>> guessing RFC
>>>> 3473 support from that would not be fully wrong. Similarly, an
>>>> implementation may perfectly support 3473 even if it has not
>>>> explicitly advertise a PSC switching capability on a given link. Let
>>>> us make these explicit!
>>>> My 2 cents,
>>>> Julien
>>>> Oct. 07, 2017 - Christian Hopps:
>>>>> Hi Folks,
>>>>> The authors have requested the IS-IS WG adopt
>>>>> to
>>>>> cols/
>>>>> as a working group document. Please indicate your support or
>>>>> no-support for taking on this work.
>>>>> Authors: Please indicate your knowledge of any IPR related to this
>>>>> work to the list as well.
>>>>> Thanks,
>>>>> Chris & Hannes.
>>>>> _______________________________________________
>>>>> Isis-wg mailing list
>>>> _______________________________________________
>>>> Isis-wg mailing list