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

"Les Ginsberg (ginsberg)" <> Thu, 12 October 2017 15:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D27CB13451D; Thu, 12 Oct 2017 08:37:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.52
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2BMW5iC-LXfJ; Thu, 12 Oct 2017 08:37:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 61CF013451E; Thu, 12 Oct 2017 08:37:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; 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-AV: E=Sophos;i="5.43,366,1503360000"; d="scan'208";a="15600916"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Oct 2017 15:37:55 +0000
Received: from ( []) by (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 ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 12 Oct 2017 10:37:54 -0500
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Thu, 12 Oct 2017 10:37:54 -0500
From: "Les Ginsberg (ginsberg)" <>
To: "" <>, "Christian Hopps" <>, "" <>
CC: "" <>, "" <>, "" <>
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: <>
References: <> <> <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-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Thu, 12 Oct 2017 15:38:00 -0000

Stephane -

Please read the revised Section 6 of the new version of (just published a short time ago) and let me know if you still have concerns.


> -----Original Message-----
> From:
> []
> Sent: Thursday, October 12, 2017 8:33 AM
> To: Les Ginsberg (ginsberg) <>om>; Christian Hopps
> <>rg>;
> Cc:;; draft-hegde-isis-advertising-te-
> 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 [] On Behalf Of Les Ginsberg
> (ginsberg)
> Sent: Thursday, October 12, 2017 16:44
> To: Christian Hopps;
> Cc:;; draft-hegde-isis-advertising-te-
> 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:
> hegde-isis-advertising-te-protocols-03.txt [HEGDE]  and see what if anything
> has yet to be addressed by the current WG document
> 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:
>   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
> 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 [] On Behalf Of Christian
> > Hopps
> > Sent: Friday, October 06, 2017 7:43 PM
> > To:
> > Cc:;;
> > draft-hegde-isis-advertising-te-
> > Subject: [Isis-wg] WG Adoption poll for
> > draft-hegde-isis-advertising-te- protocols
> >
> > Hi Folks,
> >
> > The authors have requested the IS-IS WG adopt
> >
> >
> >
> > 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
> __________________________________________________________
> __________________________________________________________
> _____
> 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.