Robert – I have replied to Shraddha’s post – pointing out that there is an explicit definition of “application” in the documents.
I have nothing more to add in response to your comments other than to reemphasize that it is quite permissible to restrict the meaning of a given term when used in the scope of a document so long as we have a clear definition – which we do. Les From: Robert Raszuk <rob...@raszuk.net> Sent: Wednesday, July 13, 2022 12:25 AM To: Shraddha Hegde <shrad...@juniper.net> Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; lsr@ietf.org Subject: Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt Hello, Yes I very much support Shraddha's msg. The term "application" should not even be (re)defined up front, but completely removed from the document. Likewise ASLA should be renamed too. I thought we had the agreement in subsequent documents to do so. Why not fix it across the board ? If we look at the dictionary: https://dictionary.cambridge.org/dictionary/english/application I do not see any definition which would even closely fit the real use case for this term here. Application is a computer program not a network forwarding/protection mechanism like RSVP-TE, SRv6, LFA etc ... If someone who is writing real applications - say ticker forwarder - and he takes such RFC she or he will be super confused and will start expecting his application to have its own bit to be identified directly in the ASLA bit mask. Thx, R. On Wed, Jul 13, 2022 at 7:52 AM Shraddha Hegde <shraddha=40juniper....@dmarc.ietf.org<mailto:40juniper....@dmarc.ietf.org>> wrote: Authors, Thanks for the bis version of RFC 8919 and the clarifying text on errata. The issues raised with respect to the errata have been addressed well in the bis version. However, I believe that the bis version is also an opportunity for us to address any other ambiguities and clarifications and not just restrict it to the raised errata. RFC 8919 is going to serve as base document for many future applications /attributes and a clear definition and documentation is necessary for interoperable implementations as well as for future evolution of the protocol. I have below comments on the document 1. The definition of what constitutes an application in the scope of this document is not clearly defined in the document. Currently RSVP,SR-TE, LFA, Flex-algo have been defined so it appears that any application that uses TE attributes can be defined as a separate application. The TE mechanisms like RSVP, SR-TE and flex-algo have been defined as separate applications and it appears features having significantly different forwarding plane is defined as new application. It is not clear if SRv6 would be qualified as a new application. LFA for different forwarding planes such as IP, MPLS, SRv6 are not separate applications but LFA is defined as a single application. I have also seen many drafts confusing application specific to be user application. I suggest to add a section and describe what is an application clearly in the draft that should provide sufficient input on what can be defined as an application from ASLA context in future. 2. " When SABM or UDABM Length is non-zero and the L-flag is NOT set, all applications specified in the bit mask MUST use the link attribute advertisements in the sub-TLV." Applications such as RSVP, SR-TE, LFA already use legacy advertisements. This document suggests that if any attribute is advertised with an application bit set in ASLA ASLA advertisements MUST be used by that application. Implementations may support ASLA for only some applications. I suggest to add below text. Until all nodes upgraded to support ASLA for a particular application, different values of link attributes MUST NOT be advertised for that application in legacy advertisement and ASLA advertisements. Rgds Shraddha Juniper Business Use Only -----Original Message----- From: Lsr <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf Of Les Ginsberg (ginsberg) Sent: Tuesday, June 21, 2022 8:59 AM To: lsr@ietf.org<mailto:lsr@ietf.org> Subject: [Lsr] FW: New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt [External Email. Be cautious of content] Folks - Please note V01 of the RFC8919bis draft has been posted. This version incorporates comments received from Bruno. Les -----Original Message----- From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> Sent: Monday, June 20, 2022 8:22 PM To: John Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>>; Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; Peter Psenak (ppsenak) <ppse...@cisco.com<mailto:ppse...@cisco.com>>; Stefano Previdi <stef...@previdi.net<mailto:stef...@previdi.net>>; Wim Henderickx <wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>> Subject: New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt A new version of I-D, draft-ginsberg-lsr-rfc8919bis-01.txt has been successfully submitted by Les Ginsberg and posted to the IETF repository. Name: draft-ginsberg-lsr-rfc8919bis Revision: 01 Title: IS-IS Application-Specific Link Attributes Document date: 2022-06-20 Group: Individual Submission Pages: 25 URL: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ginsberg-lsr-rfc8919bis-01.txt__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlB5e_NMk$<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ginsberg-lsr-rfc8919bis-01.txt__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlB5e_NMk$> Status: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlMHc2Gn4$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlMHc2Gn4$> Html: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ginsberg-lsr-rfc8919bis-01.html__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlABYFZnP$<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ginsberg-lsr-rfc8919bis-01.html__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlABYFZnP$> Htmlized: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ginsberg-lsr-rfc8919bis__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlJxHVgye$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ginsberg-lsr-rfc8919bis__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlJxHVgye$> Diff: https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ginsberg-lsr-rfc8919bis-01__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlEG5hZVF$<https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-ginsberg-lsr-rfc8919bis-01__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlEG5hZVF$> Abstract: Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements that address both of these shortcomings. This document obsoletes RFC 8919. The IETF Secretariat _______________________________________________ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlGfn5wMH$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlGfn5wMH$> _______________________________________________ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
