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

From: Christian Hopps <[email-masked]>
Date: Fri, 06 Oct 2017 22:42:55 -0400

Hi Folks,

The authors have requested the IS-IS WG adopt

    https://datatracker.ietf.org/doc/draft-hegde-isis-advertising-te-protocols/

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.

---

From: <[email-masked]>
Date: Mon, 9 Oct 2017 14:25:10 +0000

Hi Chris, authors, all,

I support WG adoption of this document.

This document provides explicit signaling for the support of RSVP-TE over a link and hence avoids implicit assumptions which may not be interoperable.

Please find below some comments:

1) Traffic-engineering protocol sub-TLV

I feel that a Flags field attached to links may be useful for multiple applications and usages. I would not limit the usage to TE, hence I would propose to use a more generic name. At least to avoid comment such as "you cannot use this field to advertise xx as xx is not TE"

2) Segment Routing flag

Thanks for adding section 3.2 which is definitely needed.
Although I can live with it, I'm still not convinced that we need such a SR flag.

"The Segment Routing flag is set to zero to indicate that Segment Routing is not enabled on a link."
What does "SR enabled on a link" means?
- If the goal is to signal Network Operator policy, probably the use of link color (aka administrative groups) is the right tool.  (while for RSVP-TE, this is a technical capability that a router may advertise by itself without network operator configuration)
- If the goal is to signal that MPLS is not enabled on the link (layer) then may be it should renamed as MPLS flag, and could possibly be used more broadly.
- Are there other cases? (a priori SR seems a node property rather than a link property)

- Do you make a distinction between MPLS SR and SRv6? (SRv6 capability may be line card hence link dependent)

3) uses of TE info for non-RSVP-TE usages.

" However, these traffic engineering link attributes
   have also been used by other applications, such as IP/LDP fast-
   reroute using loop-free alternates as described in [RFC7916].  In the
   future, it is likely that traffic engineering applications based on
   Segment Routing [I-D.ietf-spring-segment-routing] will also use these
   link attributes."

Could this document make it crystal clear, using normative language, that existing and future TE link attributes may be used by non RSVP-TE applications?
Otherwise, this document lose its motivation (as the presence of TE sub-TLV may be used to signal the presence of RSVP-TE)

Thanks,
Regards,
--Bruno

 > -----Original Message-----
 > From: Isis-wg [mailto:[email-masked]] On Behalf Of Christian Hopps
 > Sent: Saturday, October 07, 2017 4:43 AM
 > To: [email-masked]
 > Cc: [email-masked]; [email-masked]; [email-masked]
 > Subject: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols
 > 
 > Hi Folks,
 > 

_________________________________________________________________________________________________________________________

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.

---

From: Chris Bowers <[email-masked]>
Date: Mon, 9 Oct 2017 20:55:23 +0000

Bruno,

Thanks for expressing support for WG adoption, and for the comments.

The comments are addressed in-line with [CB].  

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, October 9, 2017 9:25 AM
To: Christian Hopps <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols

Hi Chris, authors, all,

=======
[CB] That makes sense. A better name might be "Protocol Enablement sub-TLV", but I am interested in other naming suggestions as well.  
=======

2) Segment Routing flag

==========
[CB]  These are good points. At this point, the authors have identified the one use case described in section 3.2.  It would be useful to understand if there are other use cases from the rest of the working group.  I am certainly open to refinements or modifications of the SR flag as the working group sees fit.    With respect to MPLS SR and SRv6, the current intention of the text is MPLS SR when referring to the SR flag.  However, we will make this clearer in the next revision of the text.   
==========

===========
[CB]  Below is proposed text to make this point crystal clear.

   "When traffic engineering extensions were first defined, the primary
   consumers of link attributes were RSVP-based applications that use
   the link information to compute paths which were subsequently
   signaled using RSVP-TE.  Over time, these link attributes have been
   used by non RSVP-TE applications, such as IP/LDP fast-reroute using
   loop-free alternates as described in [RFC7916].  More recently,
   applications based on Segment Routing
   [I-D.ietf-spring-segment-routing] have started to make use of these
   link attributes.

   In order to remove any ambiguity about the status of non RSVP-TE uses
   of TE link attributes, the current document makes the following
   normative statement.  Existing and future traffic engineering link
   attributes MAY be used by non RSVP-TE applications."
============

Thanks,
Regards,
--Bruno

 > From: Isis-wg [mailto:[email-masked]] On Behalf Of Christian Hopps  > Sent: Saturday, October 07, 2017 4:43 AM  > To: [email-masked]  > Cc: [email-masked]; [email-masked]; [email-masked]
 > The authors have requested the IS-IS WG adopt  > 
 >     https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dhegde-2Disis-2Dadvertising-2Dte-2Dprotocols_&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=mIF18ha_B3lsg_QPPZ0uZE5Mp5Q7LXQIPJHrP9QhvL4&m=S0MISL1PhJdVSGSOkWSRY-tyTlkaOS4u6Zs82okra40&s=baaIDeBkWxThZOMBrijUmD9F1EocY9lBoGkN9xlS5RY&e=
 >
 > 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.

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.

---

From: <[email-masked]>
Date: Tue, 10 Oct 2017 07:03:17 +0000

Thanks Chris,

Looks good to me.

Regards,
--Bruno

> From: Chris Bowers [mailto:[email-masked]]
> Sent: Monday, October 09, 2017 10:55 PM
> 
 > Bruno,
 > 
 > This document provides explicit signaling for the support of RSVP-TE over a link and hence
 > avoids implicit assumptions which may not be interoperable.
 > 
 > 
 > I feel that a Flags field attached to links may be useful for multiple applications and usages. I
 > would not limit the usage to TE, hence I would propose to use a more generic name. At least to
 > avoid comment such as "you cannot use this field to advertise xx as xx is not TE"
 > 
 > =======
 > [CB] That makes sense. A better name might be "Protocol Enablement sub-TLV", but I am
 > interested in other naming suggestions as well.
 > =======
 > 
 > 2) Segment Routing flag
 > 
 > - If the goal is to signal Network Operator policy, probably the use of link color (aka administrative
 > groups) is the right tool.  (while for RSVP-TE, this is a technical capability that a router may
 > advertise by itself without network operator configuration)
 > - If the goal is to signal that MPLS is not enabled on the link (layer) then may be it should
 > renamed as MPLS flag, and could possibly be used more broadly.
 > [CB]  These are good points. At this point, the authors have identified the one use case described
 > in section 3.2.  It would be useful to understand if there are other use cases from the rest of the
 > working group.  I am certainly open to refinements or modifications of the SR flag as the working
 > group sees fit.    With respect to MPLS SR and SRv6, the current intention of the text is MPLS SR
 > when referring to the SR flag.  However, we will make this clearer in the next revision of the text.
 > ==========
 > 
 > Could this document make it crystal clear, using normative language, that existing and future TE
 > link attributes may be used by non RSVP-TE applications?
 >  > From: Isis-wg [mailto:[email-masked]] On Behalf Of Christian Hopps  > Sent:
 > Saturday, October 07, 2017 4:43 AM  > To: [email-masked]  > Cc: [email-masked]; isis-
 > [email-masked]; [email-masked]
 >  >     https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-
 > 2Dhegde-2Disis-2Dadvertising-2Dte-
 > 2Dprotocols_&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
 > ndb3voDTXcWzoCI&r=mIF18ha_B3lsg_QPPZ0uZE5Mp5Q7LXQIPJHrP9QhvL4&m=S0MISL1Ph
 > JdVSGSOkWSRY-
 > tyTlkaOS4u6Zs82okra40&s=baaIDeBkWxThZOMBrijUmD9F1EocY9lBoGkN9xlS5RY&e=
 >  >
 > _____________________________________________________________________________
 > ____________________________________________
 > 
 > 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.

---

From: Chris Bowers <[email-masked]>
Date: Tue, 10 Oct 2017 19:18:32 +0000

I support WG adoption of this draft.

I am not aware of any IPR related to this draft.

Chris

-----Original Message-----
From: Christian Hopps [mailto:[email-masked]] 
Sent: Friday, October 6, 2017 9:43 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: WG Adoption poll for draft-hegde-isis-advertising-te-protocols

Hi Folks,

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.

---

From: Lizhenbin <[email-masked]>
Date: Wed, 11 Oct 2017 01:37:54 +0000

Support.

Best Regards,
Robin

-----Original Message-----
From: Christian Hopps [mailto:[email-masked]] 
Sent: Friday, October 6, 2017 9:43 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: WG Adoption poll for draft-hegde-isis-advertising-te-protocols

Hi Folks,

Thanks,
Chris & Hannes.

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Shraddha Hegde <[email-masked]>
Date: Wed, 11 Oct 2017 08:12:00 +0000

I support the WG adoption and not aware of any IPR related to the draft.

Rgds
Shraddha

-----Original Message-----
From: Chris Bowers [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2017 12:49 AM
To: Christian Hopps <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: WG Adoption poll for draft-hegde-isis-advertising-te-protocols

Chris

-----Original Message-----
From: Christian Hopps [mailto:[email-masked]] 
Sent: Friday, October 6, 2017 9:43 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: WG Adoption poll for draft-hegde-isis-advertising-te-protocols

Hi Folks,

    https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dhegde-2Disis-2Dadvertising-2Dte-2Dprotocols_&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=lk6VPMMAtBGJc5SZ7tLcHawggovru26Wjx0hg1iqbis&s=RTtR4x_bPy_-lp2nJkhp1LtjGV5O0FNDU4h-E32BVB4&e=

Thanks,
Chris & Hannes.

---

From: Imtiyaz <[email-masked]>
Date: Wed, 11 Oct 2017 13:56:05 +0530

I too support the WG adoption and am not aware of any IPR related to the
draft.

Thanks and regards

Imtiyaz

*"Good judgment comes from experience, and a lot of that comes from bad
judgment."*

On Wed, Oct 11, 2017 at 1:42 PM, Shraddha Hegde <[email-masked]>
wrote:

>     https://urldefense.proofpoint.com/v2/url?u=https-3A__
> datatracker.ietf.org_doc_draft-2Dhegde-2Disis-2Dadvertising-2Dte-
> 2Dprotocols_&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=
> NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=
> lk6VPMMAtBGJc5SZ7tLcHawggovru26Wjx0hg1iqbis&s=RTtR4x_bPy_-
> lp2nJkhp1LtjGV5O0FNDU4h-E32BVB4&e=
>

---

From: <[email-masked]>
Date: Thu, 12 Oct 2017 10:33:14 +0000

Hi Authors,

One question, why do you think it is really needed to introduce the SR flag ? Couldn't it be deduced from the presence of an Adj-SID and the SR router cap ?
The SR flag unset while the router supports SR looks strange to me. Why do you want to prevent "SR forwarding" on a link if the node supports SR ?

" With this information, a centralized
   application can decide to use a different path for that traffic by
   using a different label stack."
In such a case, the usage of a Node-SID may be complex, as the Node-SID may cross a link with the SR flag unset. This will force the controller to use Adj-SIDs only. 
If the controller uses only Adj-SIDs, then an implementation can allow the user to prevent the advertisement of Adj-SIDs on a particular link.

Could you clarify the use case here ?

Thanks,

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of Christian Hopps
Sent: Saturday, October 07, 2017 04:43
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols

Hi Folks,

Thanks,
Chris & Hannes.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 12 Oct 2017 14:43:36 +0000

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

> Sent: Friday, October 06, 2017 7:43 PM
> To: [email-masked]

---

From: <[email-masked]>
Date: Thu, 12 Oct 2017 15:32:36 +0000

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:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, October 12, 2017 16:44
To: Christian Hopps; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols

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]

  RSVP-TE

"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."

Summary
-------------

   Les

> Cc: [email-masked]; [email-masked]; 
> draft-hegde-isis-advertising-te- [email-masked]
> Subject: [Isis-wg] WG Adoption poll for 
> draft-hegde-isis-advertising-te- protocols
> 
> Hi Folks,
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 12 Oct 2017 15:37:54 +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

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Thursday, October 12, 2017 8:33 AM
> To: Les Ginsberg (ginsberg) <[email-masked]>; Christian Hopps
> <[email-masked]>; [email-masked]
> In your solution, I do not think coupling the application enablement with the
> advertisement of attributes to be a good idea.
> 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).
> - 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,
> 
> 
> 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]
> 
> 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
> 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:
> 
> 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.
> 
> 
> 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.
> 
> 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.
> 
> [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
> 
> 
> __________________________________________________________
> __________________________________________________________
> _____
> 
> 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
> 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.

---

From: Paul Mattes <[email-masked]>
Date: Thu, 12 Oct 2017 20:47:24 +0000

I support the WG adoption.

        pdm

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of Christian Hopps
Sent: Friday, October 6, 2017 9:43 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols

Hi Folks,

    https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hegde-isis-advertising-te-protocols%2F&data=02%7C01%7Cpamattes%40microsoft.com%7C2ef8d8ec0ea94ba3ca0908d50d2d249f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636429409902981480&sdata=zdVJY7RqakNbsK2L5PDI3tyNfTCjvty1UlBFguuHksU%3D&reserved=0

Thanks,
Chris & Hannes.

---

From: Peter Psenak <[email-masked]>
Date: Fri, 13 Oct 2017 09:20:51 +0200

Given the revised text in 
https://www.ietf.org/id/draft-ietf-isis-te-app-01.txt section 6, 
draft-hegde-isis-advertising-te-protocols does not bring any new 
functionality and is not needed.

thanks,
Peter

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 13 Oct 2017 13:49:01 +0000

Stephane,

In certain cases MPLS forwarding may not be supported on some legacy linecards.
Since these links should be used for IP forwarding IGPs will advertise these links.
It is better to have explicit indication of this rather than use absence of adjacency-sid on the link.

With the new SR flag, while the SPF and the SR-Path does not change, there is an indication
To the controller and head-end nodes that the links cannot do SR-MPLS forwarding.
The controller or head-end implementations may have mechanisms to prevent pulling
Traffic on SR paths. When Head-end node detects a prefix-sid path going through such incapable links
It may skip installing SR paths for such prefix-SID and implementations may decide to use other 
mechanisms (such as RSVP or IP) at the head-end which would prevent
Traffic loss.

This is also a useful tool during transition to SR when  certain links should avoid carrying SR traffic due to operational
reasons.

Rgds
Shraddha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 12, 2017 4:03 PM
To: [email-masked]; [email-masked]
Subject: RE: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols

Hi Authors,

Thanks,

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of Christian Hopps
Sent: Saturday, October 07, 2017 04:43
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols

Hi Folks,

    https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dhegde-2Disis-2Dadvertising-2Dte-2Dprotocols_&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=C2KWg-TNJXOgV_qiX8ZDhjjJW6rn3GhpPaBzHTDjqZ0&s=lHsxN1TAflKdy5QZ1sKRfmprtswYQGOljhQpvPNoJkE&e=

Thanks,
Chris & Hannes.

---

From: Peter Psenak <[email-masked]>
Date: Fri, 13 Oct 2017 16:33:23 +0200

Hi Shraddha,

please see inline:

> In certain cases MPLS forwarding may not be supported on some legacy linecards.

The problem you are describing is not SR specific, it would apply to LDP 
as well. So the indication should not be about SR, but about MPLS 
forwarding support on interface.

With MPLS being deployed for more then 20 years, I wonder why there was 
no need to solve this issue earlier and why we need to address it now 
with SR.

> This is also a useful tool during transition to SR when  certain links should avoid carrying SR traffic due to operational

there are standardized mechanisms like affinities that can be used to 
address above mentioned operational issue.

thanks,
Peter

> .

---

From: Shraddha Hegde <[email-masked]>
Date: Sat, 14 Oct 2017 17:13:55 +0000

Peter,

Pls see inline..

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Friday, October 13, 2017 8:03 PM
To: Shraddha Hegde <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols

Hi Shraddha,

please see inline:

> In certain cases MPLS forwarding may not be supported on some legacy linecards.

The problem you are describing is not SR specific, it would apply to LDP as well. So the indication should not be about SR, but about MPLS forwarding support on interface.

With MPLS being deployed for more then 20 years, I wonder why there was no need to solve this issue earlier and why we need to address it now with SR.

> With the new SR flag, while the SPF and the SR-Path does not change, 
> there is an indication To the controller and head-end nodes that the links cannot do SR-MPLS forwarding.
> The controller or head-end implementations may have mechanisms to 
> prevent pulling Traffic on SR paths. When Head-end node detects a 
> prefix-sid path going through such incapable links It may skip 
> installing SR paths for such prefix-SID and implementations may decide 
> to use other mechanisms (such as RSVP or IP) at the head-end which would prevent Traffic loss.
>
> This is also a useful tool during transition to SR when  certain links 
> should avoid carrying SR traffic due to operational reasons.

  >  there are standardized mechanisms like affinities that can be used to address above mentioned operational issue.

These mechanisms are specific to SR-TE when the paths are built based on constraints.
Link color based solution cannot be used when the SR traffic is flowing over SPF paths using Node-SIDs.

thanks,
Peter

> Subject: RE: [Isis-wg] WG Adoption poll for 
> draft-hegde-isis-advertising-te-protocols
>
> Hi Authors,
>
> [email-masked]
> draft-hegde-isis-advertising-te-protocols
>
> Hi Folks,
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.
> org_doc_draft-2Dhegde-2Disis-2Dadvertising-2Dte-2Dprotocols_&d=DwIFAg&
> c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdV
> KcmMXJ31bpbBaNqzCNrng&m=C2KWg-TNJXOgV_qiX8ZDhjjJW6rn3GhpPaBzHTDjqZ0&s=
> lHsxN1TAflKdy5QZ1sKRfmprtswYQGOljhQpvPNoJkE&e=
>
> ______________________________________________________________________
> ___________________________________________________
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_isis-2Dwg&d=DwICAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDT
> XcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=HA7t5B3gAhN2q_
> Lj_Ykis3SRVwgLO3HnsBNztTBm604&s=SWKyb05_7fQL4r4j4a4WcU78M4nYaaLz16pBKh
> wzBGo&e=
> .
>

---

From: Peter Psenak <[email-masked]>
Date: Sun, 15 Oct 2017 11:53:32 +0200

Hi Shradha,

please see inline:

> Link color based solution cannot be used when the SR traffic is flowing over SPF paths using Node-SIDs.

as we discussed this privately before (and agreed I believe), if we need 
to address this case, it will be about MPLS enablement not about SR. Do 
you agree?

I'm willing to accept the need to advertise the MPLS enablement on the 
link, if people believe the use case is valid. I have some doubts there 
though, due to the long history of this problem.

thanks,
Peter

---

From: <[email-masked]>
Date: Tue, 17 Oct 2017 07:06:12 +0000

Hi Les,

I works. However, from an operational perspective, it looks better to have an explicit information rather than an implicit one with the rules changing depending on the application. I do not think that introducing a new TLV is a big deal.

Best Regards,

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Thursday, October 12, 2017 17:38
To: LITKOWSKI Stephane OBS/OINIS; Christian Hopps; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols

Stephane -

  Les

> In your solution, I do not think coupling the application enablement 
> with the advertisement of attributes to be a good idea.
> 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).
> - 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 :)
> 
> From: Isis-wg [mailto:[email-masked]] On Behalf Of Les 
> Ginsberg
> (ginsberg)
> Subject: Re: [Isis-wg] WG Adoption poll for 
> In August of 2017 the IS-IS WG adopted draft-ietf-isis-te-app 
> (formerly draft-
> ginsberg-isis-te-app) as a WG document.
> 
> 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.
> 
> hegde-isis-advertising-te-protocols-03.txt [HEGDE]  and see what if 
> anything has yet to be addressed by the current WG document 
> 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.
> 
> 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
> 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.
> 
> advertisement can or should be used by an application other than 
> RSVP-TE e.g., the usage described in [HEGDE] Section 1:
> 
> 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.
> 
> 
> 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-
> 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].
> 
> 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.
> 
> extensions defined in [GINSBERG]. There is therefore no reason to 
> adopt [HEGDE] as a WG document.
> 
>    Les
> 
> 
> > https://datatracker.ietf.org/doc/draft-hegde-isis-advertising-te-pro
> > to
> > cols/
> >
> 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.

---

From: <[email-masked]>
Date: Tue, 17 Oct 2017 07:10:03 +0000

Hi Chairs,

I support the idea of having an explicit "protocol" enablement that includes RSVP. IMO this must be decoupled from the attributes advertisement. So draft-hegde-isis-advertising-te-protocols comes with a good proposal here.
I do not support to include SRTE in the same framework as SRTE activation is not a per link property.

Best Regards,

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of Christian Hopps
Sent: Saturday, October 07, 2017 04:43
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols

Hi Folks,

Thanks,
Chris & Hannes.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 18 Oct 2017 20:03:37 +0530

Support WG adoption.

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 19 Oct 2017 16:11:35 +0530

+1

Support Adoption!

Thanks!
Dhruv

On Tue, Oct 17, 2017 at 12:40 PM, <[email-masked]> wrote:

> Hi Chairs,
>
> I support the idea of having an explicit "protocol" enablement that
> includes RSVP. IMO this must be decoupled from the attributes
> advertisement. So draft-hegde-isis-advertising-te-protocols comes with a
> good proposal here.
> ____________________________________________________________
> _____________________________________________________________
>
> 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,
> information that may be protected by law;

---

From: prz <[email-masked]>
Date: Thu, 19 Oct 2017 06:45:16 -0700

+1 support

 thanks

 --- tony

 On Tue, 17 Oct 2017 07:10:03 +0000, <[email-masked]> 
 wrote:
> advertisement. So draft-hegde-isis-advertising-te-protocols comes 
> with
> a good proposal here.

---

From: Julien Meuric <[email-masked]>
Date: Fri, 20 Oct 2017 16:14:55 +0200

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 21 Oct 2017 16:57:14 +0000

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-codepoints.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

> From: Isis-wg [mailto:[email-masked]] On Behalf Of Julien Meuric
> Sent: Friday, October 20, 2017 7:15 AM
> To: [email-masked]
> "protocol" might be too specific here) really adds a missing piece after RFC
> 5073.
> 
> 3473-capable. Indeed, there are parameters like SRLGs that were defined as
> part of GMPLS extensions: an implementation (wildly) guessing RFC

---

From: Julien Meuric <[email-masked]>
Date: Mon, 23 Oct 2017 14:16:06 +0200

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 23 Oct 2017 13:13:17 +0000

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

> From: Julien Meuric [mailto:[email-masked]]
> Sent: Monday, October 23, 2017 5:16 AM
> To: Les Ginsberg (ginsberg) <[email-masked]>
> Cc: [email-masked]
> 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 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!
> > 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
> >> 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.
> >>
> >> 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
> >> 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
> >>
> >>

---

From: Julien Meuric <[email-masked]>
Date: Wed, 25 Oct 2017 16:37:48 +0200

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 25 Oct 2017 18:45:11 +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

> Sent: Wednesday, October 25, 2017 7:38 AM
> - my unconditional support to the adoption of draft-hegde-isis-advertising-
> te-protocols (irrespective of the decision about my following proposal),
> 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.
> 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.]
> 
> 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
> 
> 
> > 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.
> >> 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.
> >> protocol sub- TLV" is not obvious, please do not consider that as a
> >> 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
> >> 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.
> >>>
> >>> 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
> >>>
> >>>
> >>>> 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
> >>>> explicitly advertise a PSC switching capability on a given link.
> >>>> Let us make these explicit!
> >>>>
> >>>> My 2 cents,
> >>>>
> >>>> Julien
> >>>>
> >>>>

---

From: John E Drake <[email-masked]>
Date: Wed, 25 Oct 2017 19:06:50 +0000

Julien,

Perhaps what is needed is an MPLS/GMPLS capabilities advertisement which lists explicitly what are the advertising node's capabilities.  I seem to remember some work years ago regarding the migration from MPLS to GMPLS and their attendant coexistence, and that might be useful as a starting point.

I am copying Adrian and Lou w/ the expectation that their memories are better than mine.  

Yours Irrespectively,

John

> Sent: Wednesday, October 25, 2017 2:45 PM
> To: Julien Meuric <[email-masked]>
> Cc: [email-masked]
> I point out the newly added Section 6 in
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Disis-2Dte-
> 2Dapp_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-
> s_xXXup3HzvBSMRj5VE&m=vRDDozQWVQuCQeQnNkzN6VSK3Plqawlv4L7W0R
> FNJ-Y&s=iiYJ0nRe9SlDwIoqwDZMGaiHCU4VYT_QsXyoGhaKOJc&e= .
> 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.
> 
> > draft-hegde-isis-advertising- te-protocols (irrespective of the
> > decision about my following proposal),
> > 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.]
> >
> > 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
> >
> >
> > > My position on WG adoption of
> > (opposed) and the reasons why have been stated in an earlier post to
> > the list.
> > >
> > 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.
> > >
> > 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
> > (and draft-ietf-isis-te-app).
> > >
> > >    Les
> > >
> > >
> > >> 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).
> > >> draft-hegde-isis- advertising-te-protocols is already allocated!
> > >> Shraddha/Chris, could you please drop suggested codepoints from the
> > >> I-
> > D?
> > >>
> > >> Thanks,
> > >>
> > >> Julien
> > >>
> > >>
> > >>
> > >> 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
> > >>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_
> > >>> assignments_isis-2Dtlv-2Dcodepoints_isis-2Dtlv-
> 2Dcodepo&d=DwICAg&c
> > >>> =HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LG
> > >>> hEWH-
> s_xXXup3HzvBSMRj5VE&m=vRDDozQWVQuCQeQnNkzN6VSK3Plqawlv4L7W0R
> F
> > >>> NJ-Y&s=j3pCfLzDhjBl4INO9pPA-Ml_3plUlQfcL_Nln7apnbk&e=
> > >>> in
> > >>>> I support the adoption of
> > >>>> 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.
> > >>>>
> > >>>> 3209-only and 3473-capable. Indeed, there are parameters like
> > >>>> SRLGs that were defined as part of GMPLS extensions: an
> > >>>> implementation
> > >>>> (wildly) guessing RFC
> > >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker
> > >>>>> .ietf.org_doc_draft-2Dhegde-2Disis-2Dadvertising-2Dte-2Dp&d=DwIC
> > >>>>> Ag&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=CRB2tJiQePk0c
> > >>>>> T-h5LGhEWH-
> s_xXXup3HzvBSMRj5VE&m=vRDDozQWVQuCQeQnNkzN6VSK3Plqawl
> > >>>>> v4L7W0RFNJ-Y&s=urLF6Ya-h-JyUcprEz-
> 6Wi8Xa0TYy4wjOrn_Ek21tl8&e=
> > >>>>> ro
> > >>>>> to
> > >>>>> cols/
> > >>>>>
> > >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.or
> > >>>>> g_mailman_listinfo_isis-
> 2Dwg&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBX
> > >>>>> eMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-
> s_xXXup3HzvBSMRj5V
> > >>>>> E&m=vRDDozQWVQuCQeQnNkzN6VSK3Plqawlv4L7W0RFNJ-
> Y&s=0uBaEWzChU8vMa
> > >>>>> X_gnFWcaHmV_ScWM7cZMZtSoIkgEI&e=
> > >>>>
> > >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org
> > >>>> _mailman_listinfo_isis-
> 2Dwg&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeM
> > >>>> K-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-
> s_xXXup3HzvBSMRj5VE&m
> > >>>> =vRDDozQWVQuCQeQnNkzN6VSK3Plqawlv4L7W0RFNJ-
> Y&s=0uBaEWzChU8vMaX_gn
> > >>>> FWcaHmV_ScWM7cZMZtSoIkgEI&e=
> > >>>
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_isis-
> 2Dwg&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-
> s_xXXup3HzvBSMRj5VE&m=vRDDozQWVQuCQeQnNkzN6VSK3Plqawlv4L7W0R
> FNJ-Y&s=0uBaEWzChU8vMaX_gnFWcaHmV_ScWM7cZMZtSoIkgEI&e=