Re: WG Adoption poll for draft-hegde-isis-advertising-te-protocols

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: [email protected]
> [mailto:[email protected]]
> Sent: Thursday, October 12, 2017 8:33 AM
> To: Les Ginsberg (ginsberg) <[email protected]>; Christian Hopps
> <[email protected]>; [email protected]
> Cc: [email protected]; [email protected]; draft-hegde-isis-advertising-te-
> [email protected]
> 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:[email protected]] On Behalf Of Les Ginsberg
> (ginsberg)
> Sent: Thursday, October 12, 2017 16:44
> To: Christian Hopps; [email protected]
> Cc: [email protected]; [email protected]; draft-hegde-isis-advertising-te-
> [email protected]
> 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:[email protected]] On Behalf Of Christian
> > Hopps
> > Sent: Friday, October 06, 2017 7:43 PM
> > To: [email protected]
> > Cc: [email protected]; [email protected];
> > draft-hegde-isis-advertising-te- [email protected]
> > 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
> [email protected]
> 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.