Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt
Les,
I am fine with the revised text and addresses my concern.
Rgds
Shraddha
Juniper Business Use Only
From: Les Ginsberg (ginsberg)
Sent: Tuesday, July 19, 2022 2:15 AM
To: Shraddha Hegde ; Les Ginsberg (ginsberg)
; lsr@ietf.org
Subject: RE: New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt
[External Email. Be cautious of content]
Shraddha -
Please see {LES2:] inline.
> -Original Message-
> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of
> Shraddha Hegde
> Sent: Monday, July 18, 2022 2:16 AM
> To: Les Ginsberg (ginsberg)
> mailto:ginsberg=40cisco@dmarc.ietf.org>>;
> lsr@ietf.org<mailto:lsr@ietf.org>
> 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)
> mailto:ginsberg=40cisco@dmarc.ietf.org>>
> Sent: Friday, July 15, 2022 10:21 PM
> To: Shraddha Hegde mailto:shrad...@juniper.net>>;
> Shraddha Hegde
> mailto:shrad...@juniper.net>>;
> lsr@ietf.org<mailto:lsr@ietf.org>
> 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.
>
>
> > [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."
> >
> > 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.
> > The scope of the discussion here is to get the specification
> > clear and unambiguous.
>
>
> Taking individual sentences out of context from Section 6.3.3 prolongs this
> discussion and leads to err
Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt
Shraddha -
Please see {LES2:] inline.
> -Original Message-
> From: Lsr On Behalf Of Shraddha Hegde
> Sent: Monday, July 18, 2022 2:16 AM
> To: Les Ginsberg (ginsberg) ;
> lsr@ietf.org
> 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)
> mailto:ginsberg=40cisco@dmarc.ietf.org>>
> Sent: Friday, July 15, 2022 10:21 PM
> To: Shraddha Hegde mailto:shrad...@juniper.net>>;
> Shraddha Hegde
> mailto:shrad...@juniper.net>>;
> lsr@ietf.org<mailto:lsr@ietf.org>
> 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.
>
>
> > [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."
> >
> > 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.
> > The scope of the discussion here is to get the specification
> > clear and unambiguous.
>
>
> Taking individual sentences out of context from Section 6.3.3 prolongs this
> discussion and leads to erroneous conclusions.
> The section says:
>
>
> 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 attri
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) Sent: Friday, July 15, 2022 10:21 PM To: Shraddha Hegde ; Shraddha Hegde ; lsr@ietf.org 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. > [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." > > 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. > The scope of the discussion here is to get the specification > clear and unambiguous. Taking individual sentences out of context from Section 6.3.3 prolongs this discussion and leads to erroneous conclusions. The section says: 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. 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" 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. 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 > Sent: Friday, July 15, 2022 9:20 AM > To: Les Ginsberg (ginsberg) ; Shraddha Hegde > ; lsr@ietf.org > 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) > Sent: Friday, July 15, 2022 9:11 PM > To: Shraddha Hegde ; Shraddha > Hegde ; lsr@ietf.org > 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 > > Sent: Friday, July 15, 2022 5:43 AM > > To: Les Ginsberg (ginsberg) ; Shraddha Hegde > > ; lsr@ietf.org > > 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 On Behalf Of Les Ginsberg > > (gins
Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt
Shraddha - Top posting since there now seems to be only one open issue. > [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." > > 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. > The scope of the discussion here is to get the specification clear and > unambiguous. Taking individual sentences out of context from Section 6.3.3 prolongs this discussion and leads to erroneous conclusions. The section says: 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. 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): 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. 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 > Sent: Friday, July 15, 2022 9:20 AM > To: Les Ginsberg (ginsberg) ; Shraddha Hegde > ; lsr@ietf.org > 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) > Sent: Friday, July 15, 2022 9:11 PM > To: Shraddha Hegde ; Shraddha > Hegde ; lsr@ietf.org > 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 > > Sent: Friday, July 15, 2022 5:43 AM > > To: Les Ginsberg (ginsberg) ; Shraddha Hegde > > ; lsr@ietf.org > > 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 On Behalf Of Les Ginsberg (ginsberg) > > Sent: Thursday, July 14, 2022 2:32 AM > > To: Shraddha Hegde ; > > lsr@ietf.org > > 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 > > > Sent: Tuesday, July 12, 2022 10:52 PM > > > To: Les Ginsberg (ginsberg) ; lsr@ietf.org > > > Subject: RE: New Version Notification for > > > draft-ginsberg-lsr-rfc8919bis-01.txt > > > > > > Authors, > > > > > > Thanks for the bis version of RFC 8919 and th
Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt
Les, Pls see inline... Juniper Business Use Only -Original Message- From: Les Ginsberg (ginsberg) Sent: Friday, July 15, 2022 9:11 PM To: Shraddha Hegde ; Shraddha Hegde ; lsr@ietf.org 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 > Sent: Friday, July 15, 2022 5:43 AM > To: Les Ginsberg (ginsberg) ; Shraddha Hegde > ; lsr@ietf.org > 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 On Behalf Of Les Ginsberg (ginsberg) > Sent: Thursday, July 14, 2022 2:32 AM > To: Shraddha Hegde ; > lsr@ietf.org > 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 > > Sent: Tuesday, July 12, 2022 10:52 PM > > To: Les Ginsberg (ginsberg) ; lsr@ietf.org > > 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. > 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. > > 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 clarifie
Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt
Shraddha - Please see inline. > -Original Message- > From: Shraddha Hegde > Sent: Friday, July 15, 2022 5:43 AM > To: Les Ginsberg (ginsberg) ; Shraddha Hegde > ; lsr@ietf.org > 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 On Behalf Of Les Ginsberg (ginsberg) > Sent: Thursday, July 14, 2022 2:32 AM > To: Shraddha Hegde ; lsr@ietf.org > 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 > > Sent: Tuesday, July 12, 2022 10:52 PM > > To: Les Ginsberg (ginsberg) ; lsr@ietf.org > > 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. > 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. > > 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. > > > > > 2. "
Re: [Lsr] 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 On Behalf Of Les Ginsberg (ginsberg) Sent: Thursday, July 14, 2022 2:32 AM To: Shraddha Hegde ; lsr@ietf.org 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 > Sent: Tuesday, July 12, 2022 10:52 PM > To: Les Ginsberg (ginsberg) ; lsr@ietf.org > 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. 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. > 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. 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. > > 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 "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. I
Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt
Hi Les, > it is quite permissible to restrict the meaning of a given term Yes you are correct. It sure is. But I just do not get why we are coming with counter intuitive terms in key specifications. Kind regards, R. On Wed, Jul 13, 2022 at 11:07 PM Les Ginsberg (ginsberg) wrote: > 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 > *Sent:* Wednesday, July 13, 2022 12:25 AM > *To:* Shraddha Hegde > *Cc:* Les Ginsberg (ginsberg) ; 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 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 On Behalf Of Les Ginsberg (ginsberg) >
Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt
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 Sent: Wednesday, July 13, 2022 12:25 AM To: Shraddha Hegde Cc: Les Ginsberg (ginsberg) ; 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 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 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> mailto:internet-dra...@ietf.org>> Sent: Monday, June 20, 2022 8:22 PM To: John Drake mailto:jdr...@juniper.net>>; Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; Stefano Previdi mailto:stef...@previdi.net>>; Wim Henderickx mailto:wim.henderi...@nokia.com>> Subject: New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt A new version of I-D, draft-gins
Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt
Shraddha - Thanx for your review and comments. Responses inline. > -Original Message- > From: Shraddha Hegde > Sent: Tuesday, July 12, 2022 10:52 PM > To: Les Ginsberg (ginsberg) ; lsr@ietf.org > 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. > 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. > > 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 Les > > Rgds > Shraddha > > > Juniper Business Use Only > > -Original Message- > From: Lsr 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 > Sent: Monday, June 20, 2022 8:22 PM > To: John Drake ; Les Ginsberg (ginsberg) > ; Peter Psenak (ppsenak) ; > Stefano Previdi ; Wim Henderickx > > 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/archi
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 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 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 > Sent: Monday, June 20, 2022 8:22 PM > To: John Drake ; Les Ginsberg (ginsberg) < > ginsb...@cisco.com>; Peter Psenak (ppsenak) ; Stefano > Previdi ; Wim Henderickx > 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.o
Re: [Lsr] 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. 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 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 Sent: Monday, June 20, 2022 8:22 PM To: John Drake ; Les Ginsberg (ginsberg) ; Peter Psenak (ppsenak) ; Stefano Previdi ; Wim Henderickx 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
