Les, Pls see inline [SH2]
Juniper Business Use Only -----Original Message----- From: Les Ginsberg (ginsberg) <[email protected]> Sent: Friday, July 15, 2022 10:21 PM To: Shraddha Hegde <[email protected]>; Shraddha Hegde <[email protected]>; [email protected] Subject: RE: New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt [External Email. Be cautious of content] Shraddha - Top posting since there now seems to be only one open issue. <snip> > [LES:] When Legacy routers are present, advertising different values > for link attributes in ASLA advertisements is an implementation bug. > That is clear from the previous statement in the same paragraph: > > "... routers that do not support the extensions defined in this > document will send and receive only legacy link attribute advertisements." > > <SH> This statement says routers that are legacy will send and receive > legacy advertisement which is obvious. It does not say other routers > which are ASLA capable MUST NOT send ASLA with application bit set > having different values In the presence of legacy routers in the domain. > > Implementations which deviate from this haven't done adequate testing > of their product before shipping it. > <SH> The scope of the discussion here is to get the specification > clear and unambiguous. <end snip> Taking individual sentences out of context from Section 6.3.3 prolongs this discussion and leads to erroneous conclusions. The section says: <snip> 6.3.3. Interoperability with Legacy Routers For the applications defined in this document, routers that do not support the extensions defined in this document will send and receive only legacy link attribute advertisements. So long as there is any legacy router in the network that has any of the applications enabled, all routers MUST continue to advertise link attributes using legacy advertisements. <end snip> There is only one way to indicate - using ASLA - that legacy advertisements are to be used - which is to use the L-flag as defined in Section 4.2 - which states (in part): [SH2] The statement you make above is not clear from the draft. Its very much valid to advertise attributes in TLV 22 and advertise ASLA with some application bit set as long as that application has been upgraded to support ASLA in entire network. Suggest below change " all routers MUST continue to advertise link attributes using legacy advertisements . If ASLA is advertised with legacy application bit set then L-bit MUST be set for that application" <snip> When the L-flag is set in the Application Identifier Bit Mask, all of the applications specified in the bit mask MUST use the legacy advertisements for the corresponding link found in TLVs Advertising Neighbor Information. Link attribute sub-sub-TLVs for the corresponding link attributes MUST NOT be advertised for the set of applications specified in the Standard or User-Defined Application Identifier Bit Masks, and all such sub-sub-TLVs MUST be ignored on receipt. <end snip> Taking all of the above text into account, this means that for a given application: 1)In the presence of legacy routers legacy advertisements MUST be used 2)ASLA link attribute sub-sub-TLVs for that application MUST NOT be advertised 3)If ASLA link attribute sub-sub-TLVs are advertised they MUST be ignored So in the presence of legacy routers there is no possibility that a conforming implementation will use link attribute values that differ from the legacy values even if they were to be advertised (which in itself is forbidden). This seems to me to cover the issue you raise very clearly. Ay additional statement would be redundant. Les > -----Original Message----- > From: Shraddha Hegde <[email protected]> > Sent: Friday, July 15, 2022 9:20 AM > To: Les Ginsberg (ginsberg) <[email protected]>; Shraddha Hegde > <[email protected]>; [email protected] > Subject: RE: New Version Notification for > draft-ginsberg-lsr-rfc8919bis-01.txt > > Les, > > Pls see inline... > > > Juniper Business Use Only > > -----Original Message----- > From: Les Ginsberg (ginsberg) <[email protected]> > Sent: Friday, July 15, 2022 9:11 PM > To: Shraddha Hegde <[email protected]>; Shraddha > Hegde <[email protected]>; [email protected] > Subject: RE: New Version Notification for > draft-ginsberg-lsr-rfc8919bis-01.txt > > [External Email. Be cautious of content] > > > Shraddha - > > Please see inline. > > > -----Original Message----- > > From: Shraddha Hegde <[email protected]> > > Sent: Friday, July 15, 2022 5:43 AM > > To: Les Ginsberg (ginsberg) <[email protected]>; Shraddha Hegde > > <[email protected]>; [email protected] > > Subject: RE: New Version Notification for > > draft-ginsberg-lsr-rfc8919bis-01.txt > > > > Les, > > > > Thanks for the reply. Pls see inline.. > > > > > > > > > > > > Juniper Business Use Only > > > > -----Original Message----- > > From: Lsr <[email protected]> On Behalf Of Les Ginsberg > > (ginsberg) > > Sent: Thursday, July 14, 2022 2:32 AM > > To: Shraddha Hegde <[email protected]>; > > [email protected] > > Subject: Re: [Lsr] New Version Notification for > > draft-ginsberg-lsr-rfc8919bis- 01.txt > > > > [External Email. Be cautious of content] > > > > > > Shraddha - > > > > Thanx for your review and comments. > > Responses inline. > > > > > -----Original Message----- > > > From: Shraddha Hegde <[email protected]> > > > Sent: Tuesday, July 12, 2022 10:52 PM > > > To: Les Ginsberg (ginsberg) <[email protected]>; [email protected] > > > Subject: RE: New Version Notification for > > > draft-ginsberg-lsr-rfc8919bis-01.txt > > > > > > 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. > > > > [LES:] Both documents have the same explicit definition in the > Introduction: > > > > "For the purposes of this document, an application is a technology > > that makes use of link attribute advertisements, examples of which > > are listed in..." > > > > The term "application" may have other meanings in other contexts, > > but those meanings are not relevant here. > > We have clearly defined what "application" means when used in this > > document. > > <SH>The definition here is not sufficiently described and very vague. > > You didn't respond to my comment below that there is no clarity > > whether > > SRv6 would ever qualify for a separate application. > > [LES:] Not sure what your point is here. > Neither SR-MPLS nor SRv6 is defined as an application by this document. > But perhaps my answer below will address your concern. > > > > > > 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. > > > > > [LES:] I disagree. > > Such text would require clairvoyance. I do not pretend to know what > > new technologies may be defined in the future which could benefit > > from ASLA support. > > > > Note that for a new application to be included in the set of ASLA > > supported standard applications, a draft must be written defining > > the new application and this has to achieve WG consensus. > > So there is a thorough vetting procedure in place already. > > > > <SH> This document defined the application bit SR-TE. It didn't > > clarify whether SR-TE means mpls dataplane as well as SRv6 dataplane. > > At a minimum it needs to be clarified in the document. > > [LES:] SR-TE application is dataplane independent . We will add the > following statement in Section 4.1 of RFC 8919 (and Section 5 for RFC 8920): > > OLD: > S-bit: > Set to specify Segment Routing Policy. > > NEW > S-bit: > Set to specify Segment Routing Policy. > NOTE: This is dataplane independent. > > <SH> Ok. > > > > > > > > > 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. > > > > > [LES:] Section 6 of RFC8919bis - and more specifically Section 6.3.3 > > - addresses this point in detail. > > I do not see that new text is needed. > > > > Comparable text can be found in RFC8920bis Section 12.3.3 > > > > <SH> > > "So long as there is any > > legacy router in the network that has any of the applications > > enabled, all routers MUST continue to advertise link attributes using > > legacy advertisements." > > > > Sec 6.3.3 in 8919bis has above statement. > > It just says MUST advertise with legacy but this does not mean it > > prohibits a router > > >From advertising ASLA along with legacy with application bit set. > > >As long as > > the values in ASLA > > Match with legacy advertisements its ok but when they don't match > > it's problematic. > > I clearly see this as a hole that can cause inter-op issues. > > [LES:] When Legacy routers are present, advertising different values > for link attributes in ASLA advertisements is an implementation bug. > That is clear from the previous statement in the same paragraph: > > "... routers that do not support the extensions defined in this > document will send and receive only legacy link attribute advertisements." > > <SH> This statement says routers that are legacy will send and receive > legacy advertisement which is obvious. It does not say other routers > which are ASLA capable MUST NOT send ASLA with application bit set > having different values In the presence of legacy routers in the domain. > > Implementations which deviate from this haven't done adequate testing > of their product before shipping it. > <SH> The scope of the discussion here is to get the specification > clear and unambiguous. > > Les > > > Les > > > > > > Les > > > > > > > > Rgds > > > Shraddha > > > > > > > > > Juniper Business Use Only > > > > > > -----Original Message----- > > > From: Lsr <[email protected]> On Behalf Of Les Ginsberg > > > (ginsberg) > > > Sent: Tuesday, June 21, 2022 8:59 AM > > > To: [email protected] > > > 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: [email protected] <[email protected]> > > > Sent: Monday, June 20, 2022 8:22 PM > > > To: John Drake <[email protected]>; Les Ginsberg (ginsberg) > > > <[email protected]>; Peter Psenak (ppsenak) <[email protected]>; > > > Stefano Previdi <[email protected]>; Wim Henderickx > > > <[email protected]> > > > 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_7OWQ6XlbSNK2EwgaJqAIeyd > > > 1bbeYOilNpT-2QlLXl7KIf7D24NLUlB5e_NMk$ > > > Status: > > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft > > > - > > > ginsberg-lsr-rfc8919bis/__;!!NEt6yMaO- > > > > > > gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd > > > 1bbeYOilNpT-2QlLXl7KIf7D24NLUlMHc2Gn4$ > > > Html: > > > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft- > > > ginsberg-lsr-rfc8919bis-01.html__;!!NEt6yMaO- > > > > > > gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd > > > 1bbeYOilNpT-2QlLXl7KIf7D24NLUlABYFZnP$ > > > Htmlized: > > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/ > > > dr > > > af > > > t- > > > ginsberg-lsr-rfc8919bis__;!!NEt6yMaO- > > > > > > gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd > > > 1bbeYOilNpT-2QlLXl7KIf7D24NLUlJxHVgye$ > > > Diff: > > > https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draf > > > t- > > > ginsberg-lsr-rfc8919bis-01__;!!NEt6yMaO- > > > > > > gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd > > > 1bbeYOilNpT-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 > > > [email protected] > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;! > > > !NEt6yMaO- > > > > > > gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd > > > 1bbeYOilNpT-2QlLXl7KIf7D24NLUlGfn5wMH$ > > > > _______________________________________________ > > Lsr mailing list > > [email protected] > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;! > > !NEt6yMaO- > > gk!HXAmPIF8bAD6M_W8QIviUQrqPaIvPfT_Q7IDNtOCUAp2VLdGA7saG- > > ysEvIFh5T-szQMzGzO8hSrWFfDWDUTJGowUwA2p1IQ$ _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
