Re: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols
Julien Meuric <julien.meuric@orange.com> Wed, 25 October 2017 14:37 UTC
Return-Path: <julien.meuric@orange.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DE91386A2 for <isis-wg@ietfa.amsl.com>; Wed, 25 Oct 2017 07:37:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.085
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wtXLKU56AOm for <isis-wg@ietfa.amsl.com>; Wed, 25 Oct 2017 07:37:51 -0700 (PDT)
Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 00024138347 for <isis-wg@ietf.org>; Wed, 25 Oct 2017 07:37:50 -0700 (PDT)
Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A03C6A4423D; Wed, 25 Oct 2017 16:37:49 +0200 (CEST)
Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 8D9AAA4423C; Wed, 25 Oct 2017 16:37:49 +0200 (CEST)
Received: from [10.193.71.63] (10.193.71.63) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.361.1; Wed, 25 Oct 2017 16:37:49 +0200
From: Julien Meuric <julien.meuric@orange.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
CC: "isis-wg@ietf.org" <isis-wg@ietf.org>
References: <87infr1xw0.fsf@chopps.org> <849fc9ab-afe8-b708-de9d-8b628b57c74c@orange.com> <c2211554298f416591415d9d25b5e355@XCH-ALN-001.cisco.com> <dc1ee623-bc4c-5e0c-cae8-793254334f14@orange.com> <f6b6d0d7f09146e08e4c954690bb544f@XCH-ALN-001.cisco.com>
Organization: Orange
Message-ID: <60aa5abe-eb20-8639-e3fe-0093c5456d50@orange.com>
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: <f6b6d0d7f09146e08e4c954690bb544f@XCH-ALN-001.cisco.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/qlbw2ZZ8zouLxJXT9WNhi8u0sd8>
Subject: Re: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: 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 draft-hegde-isis-advertising-te-protocols. Cheers, Julien Oct. 23, 2017 - ginsberg@cisco.com: > 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 [mailto:julien.meuric@orange.com] >> 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 - ginsberg@cisco.com: >>> 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: >>> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoin >>> 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 [mailto:isis-wg-bounces@ietf.org] 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 >>>>> >>>>> >>>>> https://datatracker.ietf.org/doc/draft-hegde-isis-advertising-te-pro >>>>> 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@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/isis-wg >>>> >>>> _______________________________________________ >>>> Isis-wg mailing list >>>> Isis-wg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/isis-wg >>>
- [Isis-wg] WG Adoption poll for draft-hegde-isis-a… Christian Hopps
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… bruno.decraene
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… Chris Bowers
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… bruno.decraene
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… Chris Bowers
- [Isis-wg] 答复: WG Adoption poll for draft-hegde-is… Lizhenbin
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… Shraddha Hegde
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… Imtiyaz
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… stephane.litkowski
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… stephane.litkowski
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… Paul Mattes
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… Peter Psenak
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… Shraddha Hegde
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… Peter Psenak
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… Shraddha Hegde
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… Peter Psenak
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… stephane.litkowski
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… stephane.litkowski
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… Pushpasis Sarkar
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… Dhruv Dhody
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… prz
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… Julien Meuric
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… Julien Meuric
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… Julien Meuric
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Adoption poll for draft-hegde-is… John E Drake