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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Wed, 25 October 2017 18:45 UTC

Return-Path: <ginsberg@cisco.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 004551389AC for <isis-wg@ietfa.amsl.com>; Wed, 25 Oct 2017 11:45:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 jg3pldvcMUp6 for <isis-wg@ietfa.amsl.com>; Wed, 25 Oct 2017 11:45:13 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F93313899A for <isis-wg@ietf.org>; Wed, 25 Oct 2017 11:45:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11188; q=dns/txt; s=iport; t=1508957113; x=1510166713; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pkOtT2ceZqm5iFjS2pVVUun8nE+MoUF0Ypw2i6AvUPk=; b=U1OlnfG8TZo3tWYKM8WLCEnXQogGfSDvrte7wIfdCBVjfqNG3S9xms8e NUBsIrCmEpB9WMTnEKwofk5pA+9PBqXvg1yg39Yp/d32V4ybpx807gybH +4/h12hyWgYBixpxAI/ivW7f8ZwB1m2M7xr/1pKC+10qCaZAx5fgsak3V k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAQB62vBZ/4sNJK1RChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNfZG4nB4NzmSqBepY6ghEKGAuFGAIahFNAFwECAQEBAQEBAWs?= =?us-ascii?q?ohR0BAQEEAQEhEToGBQwEAgEIEQQBAQMCIwMCAgIlCxQBCAgCBA4FCBOKBRCpU?= =?us-ascii?q?IIninYBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPgh+CB4FQgWgBgyqEWgVMgm6?= =?us-ascii?q?CYQWhIVICh2ONCYIehXuEAYcVlVQCERkBgTgBIAE2gVt6FUmCZIJcHIFndolHg?= =?us-ascii?q?TKBEQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.43,432,1503360000"; d="scan'208";a="21498268"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Oct 2017 18:45:12 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v9PIjCqA004910 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 Oct 2017 18:45:12 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 25 Oct 2017 13:45:11 -0500
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1320.000; Wed, 25 Oct 2017 13:45:11 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Julien Meuric <julien.meuric@orange.com>
CC: "isis-wg@ietf.org" <isis-wg@ietf.org>
Thread-Topic: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols
Thread-Index: AQHTPxYHrHG571lUpkWJFBhDImQkMqLtMUCAgAFoPwCAAy2NAP//ufoAgAOSRwD//+fm4A==
Date: Wed, 25 Oct 2017 18:45:11 +0000
Message-ID: <fe72c37b0b934f6d9adf07ff4ea2d7a3@XCH-ALN-001.cisco.com>
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> <60aa5abe-eb20-8639-e3fe-0093c5456d50@orange.com>
In-Reply-To: <60aa5abe-eb20-8639-e3fe-0093c5456d50@orange.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.27.12]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/WXQP5p1jm5rd6QM0oT2kc7NLWQE>
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 18:45:16 -0000

Julien -

I point out the newly added Section 6 in https://datatracker.ietf.org/doc/draft-ietf-isis-te-app/ .
If you have not read this new section please do so. It may help explain why I think draft-hegde-isis-advertising-te-protocols is unneeded.

As regards advertising RFC 3473 support and/or other RSVP related capabilities, my opinion is unchanged. This first needs to be discussed in the appropriate WG (teas, ccamp, mpls - I leave that to yourself and others to choose) so that consensus on this requirement is first established. Then, if needed, an appropriate way to advertise this support (both in IS-IS and OSPF) would be defined. But IMO this does not belong in either of the two drafts mentioned above.

I understand that you may still disagree.

   Les

> -----Original Message-----
> From: Julien Meuric [mailto:julien.meuric@orange.com]
> Sent: Wednesday, October 25, 2017 7:38 AM
> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> Cc: isis-wg@ietf.org
> Subject: Re: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-
> protocols
> 
> 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-codepo
> >>> in
> >>> 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-p
> >>>>> ro
> >>>>> 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
> >>>