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> 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> On Behalf Of Les Ginsberg (ginsberg) > Sent: Tuesday, June 21, 2022 8:59 AM > To: 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 <internet-dra...@ietf.org> > Sent: Monday, June 20, 2022 8:22 PM > To: John Drake <jdr...@juniper.net>; Les Ginsberg (ginsberg) < > ginsb...@cisco.com>; Peter Psenak (ppsenak) <ppse...@cisco.com>; Stefano > Previdi <stef...@previdi.net>; Wim Henderickx <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$ > Status: > 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$ > Htmlized: > 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$ > > 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 > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlGfn5wMH$ > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
