Shraddha -
Please see {LES2:] inline.
> -----Original Message-----
> From: Lsr <[email protected]> On Behalf Of Shraddha Hegde
> Sent: Monday, July 18, 2022 2:16 AM
> To: Les Ginsberg (ginsberg) <[email protected]>;
> [email protected]
> Subject: Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-
> 01.txt
>
> Les,
>
> Pls see inline [SH2]
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: Les Ginsberg (ginsberg)
> <[email protected]<mailto:[email protected]>>
> Sent: Friday, July 15, 2022 10:21 PM
> To: Shraddha Hegde <[email protected]<mailto:[email protected]>>;
> Shraddha Hegde
> <[email protected]<mailto:[email protected]>>;
> [email protected]<mailto:[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.
[LES2:] I am struggling a bit with your concern because it suggests that you
think someone reading the RFC might think it is OK to send two different
advertisements for a given application/link/attribute. Such advertisements
could be both legacy, both ASLA, or a mixture. Frankly, this interpretation
never occurred to me - in large part because it seems obvious this would be
ambiguous and cause operational problems - but also because such a thing is not
discussed at all in existing specifications (such as RFC 5305) and this has
never been a concern.
Nevertheless, clarity is a good thing. Here is a proposed rewording of the
first part of Section 6.3.3:
Current Text:
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. In addition, the link
attribute values associated with the set of applications supported by legacy
routers (RSVP-TE, SR Policy, and/or LFA) are always shared since legacy routers
have no way of advertising or processing application-specific values. Once all
legacy routers have been upgraded, migration from legacy advertisements to ASLA
advertisements can be achieved via the following steps:
Proposed Revised Text:
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. In addition, the link attribute values associated
with the set of applications supported by legacy routers (RSVP-TE, SR Policy,
and/or LFA) are always shared since legacy routers have no way of advertising
or processing application-specific values. So long as there is any legacy
router in the network that has any of the applications defined in this document
enabled, all routers MUST continue to advertise link attributes for these
applications using only legacy advertisements. ASLA advertisements for these
applications MUST NOT be sent. Once all legacy routers have been upgraded,
migration from legacy advertisements to ASLA advertisements can be achieved via
the following steps:
> >
> > 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.
[LES2:] You are correct - and this is covered in the description of the
transition steps in Section 6.3.3.
Beyond the changes I suggested above, I don't think any additional changes are
required.
Les
> 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]<mailto:[email protected]>>
> > Sent: Friday, July 15, 2022 9:20 AM
> > To: Les Ginsberg (ginsberg)
> > <[email protected]<mailto:[email protected]>>; Shraddha Hegde
> > <[email protected]<mailto:[email protected]>>;
> > [email protected]<mailto:[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]<mailto:[email protected]>>
> > Sent: Friday, July 15, 2022 9:11 PM
> > To: Shraddha Hegde
> > <[email protected]<mailto:[email protected]>>;
> > Shraddha
> > Hegde <[email protected]<mailto:[email protected]>>;
> > [email protected]<mailto:[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]<mailto:[email protected]>>
> > > Sent: Friday, July 15, 2022 5:43 AM
> > > To: Les Ginsberg (ginsberg)
> > > <[email protected]<mailto:[email protected]>>; Shraddha Hegde
> > > <[email protected]<mailto:[email protected]>>;
> > > [email protected]<mailto:[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]<mailto:[email protected]>> On Behalf
> > > Of Les Ginsberg
> > > (ginsberg)
> > > Sent: Thursday, July 14, 2022 2:32 AM
> > > To: Shraddha Hegde
> > > <[email protected]<mailto:[email protected]>>;
> > > [email protected]<mailto:[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]<mailto:[email protected]>>
> > > > Sent: Tuesday, July 12, 2022 10:52 PM
> > > > To: Les Ginsberg (ginsberg)
> > > > <[email protected]<mailto:[email protected]>>;
> > > > [email protected]<mailto:[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]<mailto:[email protected]>> On Behalf
> > > > Of Les Ginsberg
> > > > (ginsberg)
> > > > Sent: Tuesday, June 21, 2022 8:59 AM
> > > > To: [email protected]<mailto:[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]<mailto:[email protected]>
> > > > <[email protected]<mailto:[email protected]>>
> > > > Sent: Monday, June 20, 2022 8:22 PM
> > > > To: John Drake <[email protected]<mailto:[email protected]>>; Les
> > > > Ginsberg (ginsberg)
> > > > <[email protected]<mailto:[email protected]>>; Peter Psenak (ppsenak)
> <[email protected]<mailto:[email protected]>>;
> > > > Stefano Previdi <[email protected]<mailto:[email protected]>>; Wim
> > > > Henderickx
> > > > <[email protected]<mailto:[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-<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<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-<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/<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<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]<mailto:[email protected]>
> > > >
> > >
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__>;!
> > > > !NEt6yMaO-
> > > >
> > >
> >
> gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd
> > > > 1bbeYOilNpT-2QlLXl7KIf7D24NLUlGfn5wMH$
> > >
> > > _______________________________________________
> > > Lsr mailing list
> > > [email protected]<mailto:[email protected]>
> > >
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__>;!
> > > !NEt6yMaO-
> > > gk!HXAmPIF8bAD6M_W8QIviUQrqPaIvPfT_Q7IDNtOCUAp2VLdGA7saG-
> > > ysEvIFh5T-szQMzGzO8hSrWFfDWDUTJGowUwA2p1IQ$
>
> _______________________________________________
> Lsr mailing list
> [email protected]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
