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]; [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. _______________________________________________ Isis-wg mailing list [email protected] https://www.ietf.org/mailman/listinfo/isis-wg
