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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Thu, 12 October 2017 15:37 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 D27CB13451D; Thu, 12 Oct 2017 08:37:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level:
X-Spam-Status: No, score=-14.52 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, URIBL_BLOCKED=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 2BMW5iC-LXfJ; Thu, 12 Oct 2017 08:37:56 -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 61CF013451E; Thu, 12 Oct 2017 08:37:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10285; q=dns/txt; s=iport; t=1507822676; x=1509032276; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ikBkliQIiRqYSXYFbwXqBlkbb7kYF2t4Wypv4oukWAk=; b=ivYjV+pidfDQU0omXZm04AwlESsG2s3KVNYdztfPoWe9by0Tq6kp940D 4gaa2r7MjMXnW6XOWU1ph5kizG4IJa3oBRTW3UQK2hRAju4YJ0zQmpkLG LAv9IGEux9lUwe03orGa6ZEg06n8jXF6Mn/1ANPgweZdkNxx7LyfqWpLc A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DLAADNi99Z/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg11kbicHjhKPL4F2li8OggQKGAuFGAKEPj8YAQIBAQEBAQEBayi?= =?us-ascii?q?FHQEBAQMBAQE4NAQHBQcEAgEIEQQBAR8JBycLFAkIAgQBDQUIE4l7CBCsdos1A?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDLYIHgVGBaQGDKoRSARIBRYVOBYoWly4?= =?us-ascii?q?Ch1yNA4IdhXSDfocKlT4CERkBgTgBHziBAwt4FUmHHXYBiSOBJIERAQEB?=
X-IronPort-AV: E=Sophos;i="5.43,366,1503360000"; d="scan'208";a="15600916"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Oct 2017 15:37:55 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v9CFbtAi013105 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Oct 2017 15:37:55 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 12 Oct 2017 10:37:54 -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; Thu, 12 Oct 2017 10:37:54 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, "Christian Hopps" <chopps@chopps.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
CC: "isis-chairs@ietf.org" <isis-chairs@ietf.org>, "isis-ads@ietf.org" <isis-ads@ietf.org>, "draft-hegde-isis-advertising-te-protocols@ietf.org" <draft-hegde-isis-advertising-te-protocols@ietf.org>
Thread-Topic: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols
Thread-Index: AQHTPxYHrHG571lUpkWJFBhDImQkMqLgUX7AgABi0AD//60bQA==
Date: Thu, 12 Oct 2017 15:37:54 +0000
Message-ID: <fabd5c59a6cd44a9a41cda95d0754628@XCH-ALN-001.cisco.com>
References: <87infr1xw0.fsf@chopps.org> <3d3219f0ffba41d2b532a58d0734a286@XCH-ALN-001.cisco.com> <24148_1507822357_59DF8B15_24148_358_1_9E32478DFA9976438E7A22F69B08FF921EA87322@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
In-Reply-To: <24148_1507822357_59DF8B15_24148_358_1_9E32478DFA9976438E7A22F69B08FF921EA87322@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
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.154.131.82]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/ymXJ3YXluQDN61lR7kIrk5tqYP8>
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: Thu, 12 Oct 2017 15:38:00 -0000

Stephane -

Please read the revised Section 6 of the new version of https://www.ietf.org/id/draft-ietf-isis-te-app-01.txt (just published a short time ago) and let me know if you still have concerns.
Thanx.

  Les


> -----Original Message-----
> From: stephane.litkowski@orange.com
> [mailto:stephane.litkowski@orange.com]
> Sent: Thursday, October 12, 2017 8:33 AM
> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>om>; Christian Hopps
> <chopps@chopps.org>rg>; isis-wg@ietf.org
> Cc: isis-chairs@ietf.org; isis-ads@ietf.org; draft-hegde-isis-advertising-te-
> protocols@ietf.org
> Subject: RE: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-
> protocols
> 
> Hi Les,
> 
> In your solution, I do not think coupling the application enablement with the
> advertisement of attributes to be a good idea.
> Let's take an example for LFA.
> Consider a node S which has two links L1, L2.
> You can activate LFA on L1, set on attributes on L2 (as L2 will be the protected
> link) to be used by LFA and run RSVP-TE FRR to protect L2.
> So you have a situation where you advertise some attributes on the link
> while the application does not run on top of it. I do not think that the
> application enablement for LFA makes sense to propagate.
> 
> In addition, I do not think that this protocol/application enablement fits well
> with SRTE as the SR enablement (not SRTE) can be deduced from other
> informations (router CAP and SIDs).
> SRTE is an head end application, it is not a per link property (IMHO).
> 
> I think what we should try to agree on is:
> - do we need to have a new subTLV to indicate precisely that RSVP protocol is
> running on a link ? Or do we keep using the Bandwidth heuristic (this works
> until we have a new protocol/application that will require this information)
> => IMO, it could make sense. It could have been done many years ago :)
> 
> - do we agree or not that for SR (not SRTE), we deduce the enablement
> through the existing TLVs/subTLVs dedicated to SR => IMO, it makes sense.
> 
> 
> Brgds,
> 
> 
> -----Original Message-----
> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Les Ginsberg
> (ginsberg)
> Sent: Thursday, October 12, 2017 16:44
> To: Christian Hopps; isis-wg@ietf.org
> Cc: isis-chairs@ietf.org; isis-ads@ietf.org; draft-hegde-isis-advertising-te-
> protocols@ietf.org
> Subject: Re: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-
> protocols
> 
> In August of 2017 the IS-IS WG adopted draft-ietf-isis-te-app (formerly draft-
> ginsberg-isis-te-app) as a WG document.
> 
> This happened after extended debate between the proponents of draft-
> ginsberg-isis-te-app/draft-hegde-isis-advertising-te-protocols, multiple
> presentations at several IETFs, and considerable WG input both on the
> mailing list and at WG meetings.
> 
> This SHOULD have put this debate behind us so that the WG could focus on
> refining the adopted solution and getting it ready for deployment - but it
> seems we have taken a giant step backwards.
> 
> Let's look at the content of the latest version: https://www.ietf.org/id/draft-
> hegde-isis-advertising-te-protocols-03.txt [HEGDE]  and see what if anything
> has yet to be addressed by the current WG document
> https://datatracker.ietf.org/doc/draft-ietf-isis-te-app  [GINSBERG]
> 
> 1)Explicit and unambiguous indication of TE protocol
> -------------------------------------------------------------------------
> 
> Section 1 of [HEGDE] details an interoperability issue which exists in networks
> today i.e., different implementations infer RSVP-TE enablement on a link
> based on different advertised TE attributes.
> 
> Why does this problem exist? It exists because the link attribute
> advertisements (defined primarily in RFC 5305) sometimes are used by
> applications other than RSVP-TE. It can therefore be ambiguous as to
> whether advertisement of TE link attributes indicates that RSVP is enabled on
> that link or not. Different implementations have made different assumptions
> as to what indicates RSVP-TE enablement - this is detailed very clearly in
> Figure 1 of [HEGDE].
> 
> [GINSBERG] resolves this issue by associating an explicit application bit mask
> with link attribute advertisements. Currently defined applications include:
> 
>   RSVP-TE
>   Segment Routing Traffic Engineering
>   Loop Free Alternate
> 
> The solution is extensible to additional applications as needed.
> 
> As a result, the interoperability issue regarding RSVP enablement is resolved.
> If, for a given link, there exists a set of link attribute advertisements with the
> "RSVP-TE bit" set, then RSVP has been enabled on that link. If there are no
> advertisements with the RSVP-TE bit set then RSVP has NOT been enabled
> on that link.
> 
> This also resolves any ambiguity as to whether a given link attribute
> advertisement can or should be used by an application other than RSVP-TE
> e.g., the usage described in [HEGDE] Section 1:
> 
> "...IP/LDP fast-reroute using loop-free alternates as described in [RFC7916]"
> 
> is now also explicit because there is a bit defined specific to that application.
> 
> A new version of draft-ietf-isis-te-app has been published which clarifies the
> relationship between application specific link attribute advertisements and
> application enablement.
> 
> 
> 2)Segment Routing Forwarding Support on a Link
> ------------------------------------------------------------------
> 
> Section 3.2 of [HEGDE] asserts that a centralized application/ingress router
> requires knowledge of SR-MPLS forwarding support on a given link. This is
> true, but  https://www.ietf.org/id/draft-ietf-isis-segment-routing-
> extensions-13.txt Section 3.1 already states:
> 
> "I-Flag: MPLS IPv4 flag.  If set, then the router is capable of  processing SR
> MPLS encapsulated IPv4 packets on all interfaces.
> 
>  V-Flag: MPLS IPv6 flag.  If set, then the router is capable of  processing SR
> MPLS encapsulated IPv6 packets on all interfaces."
> 
> Therefore, link level SR-MPLS support can be inferred from the SR Capability
> advertisement which an SR capable router sends.
> 
> If the authors of [HEGDE] wish to argue that there is a use case for a node
> enabling MPLS(sic) on only a subset of its interfaces, then the correct
> problem to solve is not SR specific but generic to the use of MPLS i.e., such a
> use case could be equally applicable to an LDP deployment. Further, this
> issue affects non-TE traffic as well i.e., IGPs would have to compute and
> install different paths for IP traffic vs MPLS traffic. This issue is therefore out
> of scope for both [HEGDE] and [GINSBERG].
> 
> NOTE: In the many years of MPLS deployment there has been no need to
> address this issue. A real world deployment requirement is then a
> prerequisite and any solution belongs in a draft with an MPLS centric context.
> 
> 3)Backwards compatibility
> ------------------------------------
> 
> Both [HEGDE] and [GINSBERG] define new advertisements which will not be
> understood by legacy routers. Full realization of the benefits of either
> solution therefore require full deployment of the protocol extensions.
> 
> In the interim, [HEGDE] proposes to require use of administrative group
> configurations on all routers (legacy and new). This has a distinct
> disadvantage in that the presence of routers supporting the extensions
> defined in [HEGDE] configuration changes will be required on legacy routers.
> 
> [GINSBERG] however supports a legacy mode which requires no
> configuration changes on legacy routers.
> 
> 
> Summary
> -------------
> 
> [HEGDE] adds no value over what is defined in [GINSBERG] - its new
> advertisements would be redundant given what is advertised by the
> extensions defined in [GINSBERG]. There is therefore no reason to adopt
> [HEGDE] as a WG document.
> 
>    Les
> 
> 
> > -----Original Message-----
> > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Christian
> > Hopps
> > Sent: Friday, October 06, 2017 7:43 PM
> > To: isis-wg@ietf.org
> > Cc: isis-chairs@ietf.org; isis-ads@ietf.org;
> > draft-hegde-isis-advertising-te- protocols@ietf.org
> > Subject: [Isis-wg] WG Adoption poll for
> > draft-hegde-isis-advertising-te- protocols
> >
> > Hi Folks,
> >
> > The authors have requested the IS-IS WG adopt
> >
> >
> > https://datatracker.ietf.org/doc/draft-hegde-isis-advertising-te-proto
> > 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
> 
> __________________________________________________________
> __________________________________________________________
> _____
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites
> ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez
> le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.