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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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:[e-mail]] On Behalf Of Christian
> Hopps
> Sent: Friday, October 06, 2017 7:43 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; draft-hegde-isis-advertising-te-
> [e-mail]
> 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-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.