Re: [Lsr] Proposed Errata for RFCs 8919/8920

2021-06-17 Thread Les Ginsberg (ginsberg) 
ertisements MUST be used - but I do not understand why that is the case.
You mention Maximum-Link-Bandwidth - for which there is a dedicated Section 
(4.2.1). The need for that section arises in order to make clear that different 
values for maximum-link-bandwidth are nonsensical and if they occur they all 
should be ignored.
But Section 4.2.1 also references Sections 4.2 and 6.2 to make clear that the 
same constraints regarding the use of zero length ABM advertisements apply to 
maximum-link-bandwidth.

So, I am not clear on what text is currently confusing, nor do I understand how 
your proposed text clarifies this confusion.

I am open to revising the proposed text - but I need more help from you to 
understand the source of confusion.

   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Shraddha Hegde
Sent: Wednesday, June 16, 2021 7:46 AM
To: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 lsr@ietf.org<mailto:lsr@ietf.org>
Cc: DECRAENE Bruno IMT/OLN 
mailto:bruno.decra...@orange.com>>; Van De Velde, 
Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: Re: [Lsr] Proposed Errata for RFCs 8919/8920

Hi,

I think that there may still be some ambiguity arising from the text below due 
to the fact that
There are attributes such as maximum-link-bandwidth which have special 
behaviour mentioned in later sections.

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."


For example, If max link bandwidth attribute comes in a
Zero length SABM & UDABM and we have a Flex-algo specific ASLA
that does not have the max-link-bandwidth advertised, can
Flex-algo use max-link-bandwidth attribute?

My interpretation from modified text for ISIS is that,  it cannot use it.
I think there is no harm in re-iterating in order to avoid people reading is 
differently.

Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used.
In other words,
When an application specific link Attribute sub-TLV is advertised with one or 
more specific
standard application or user defined application bits set, all link attributes 
that are allowed in ASLA MUST
be used from the ASLA sub-TLVs having that specific application bit set.
For the purposes of such applications, link attributes MUST NOT be used from
ASLA sub-TLV with zero SABM & UDABM length.


Rgds
Shraddha



Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Les 
Ginsberg (ginsberg)
Sent: Tuesday, June 15, 2021 8:55 PM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Cc: DECRAENE Bruno IMT/OLN 
mailto:bruno.decra...@orange.com>>; Van De Velde, 
Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: [Lsr] Proposed Errata for RFCs 8919/8920

[External Email. Be cautious of content]


Folks -



Recent discussions on the list have highlighted some unintentional ambiguity in 
how ASLA advertisements are to be used. Please see 
https://mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/__;!!NEt6yMaO-gk!RK_eZNNu1y0aJvAqIaNwHTIFAjHWFJwW1UqyOO8ACxB0kof3jmD_dRkiPkbVLJyA$>



The following proposed Errata address this ambiguity and aligns language in the 
two RFCs.



We welcome comments on the proposed Errata before officially filing them.



  Les and Peter


Errata Explanation

Both RFC 8919 and RFC 8920 define advertising link attributes with zero length 
Standard Application Bit Mask (SABM) and zero length User Defined Application 
Bit Mask (UDABM)
as a means of advertising link attributes that can be used by any application. 
However, the text uses the word "permitted", suggesting that the use of such 
advertisements is "optional".
Such an interpretation could lead to interoperability issues and is not what 
was intended.

The replacement text below makes explicit the specific conditions when such 
advertisements MUST be used and the specific conditions under which they MUST 
NOT be used.

RFC 8919 Section 4.2:

OLD

"If link attributes are advertised associated with zero-len

Re: [Lsr] Proposed Errata for RFCs 8919/8920

2021-06-17 Thread Peter Psenak 

Hi Rudy,

please see inline:

On 17/06/2021 15:38, Selderslaghs, Rudy (Nokia - BE/Antwerp) wrote:

Hi Les,

The question remains whether an ISIS Appl-Spec-SRLG TLV with SABML 0 and 
UDABML 0 means that it is valid for all applications or not.


This is currently not specified in RFC8919.

Secondly the approach to handle ISIS Appl-Spec-SRLG TLVs independently 
from ASLA sub-TLVs in the context of overruling “All-Appl” attributes, 
creates confusion in BGP-LS in my opinion.


Take the following example with TLV’s belonging to the same link:

IS-Neighbors TLV

  ASLA TLV

      SABML 0, UDABML 0 (= All Appl)

      TE-Metric 20

Appl-Spec-SRLG TLV

  SABML 1, UDABML 0, Bitmap SR-Policy

      SRLG 1

Following your answer, SR-Policy has to use TE-Metric 20 and SRLG 1.

Now suppose that the node that receives this ISIS advertisement has to 
pass this on to a server via BGP-LS, this will be the result:


Link Attributes:

     ASLA TLV

     SABML 0, UDABML 0 (= All Appl)

     TE-Metric 20

     ASLA TLV

     SABML 1, UDABML 0, Bitmap SR-Policy

     SRLG 1

The server that receives this BGP-LS advertisement, has to take into 
account that it comes from the ISIS protocol in order to treat the ASLA 
TLV with SRLG info independently (as ISIS is supposed to do). I.e. the 
ASLA TLV with SRLG info does not overrule the first ASLA TLV and the 
server has to use TE-Metric 20 and SRLG 1 for SR-Policy.


If the server would receive the same BGP-LS advertisement  for the OSPF 
protocol, it can only use SRLG 1 for SR-Policy, because the second ASLA 
TLV overrules the first one in line with the OSPF rules.


I think this is confusing and that it is more consistent to treat an 
ISIS Appl-Spec-SRLG TLV as an ASLA TLV in the context of overruling of 
“All-Appl” attributes.


The fact that ISIS transports SRLG info via a separate TLV seems no 
reason to me to treat it independent of ASLA TLV’s.


the above problem is the result of the different encoding of the same 
data in ISIS and BGP-LS.


From the ISIS perspective, there are two independent TLVs:

a) Application-Specific Link Attributes TLV
b) Application-Specific SRLG TLV

Each of these carry it's own Application Identifier Bit Mask and carry 
disjoint set of attributes. We clearly can not mix these TLVs together.


BGP-LS only has the single Application Specific Link Attributes TLV, 
that is mixing SRLGs with other link attributes.


To be able to interpret the BGP-LS data on the receiver in a protocol 
independent way, the BGP-LS originator would have to 'translate' the 
ISIS AS SRLGs consistently with the BGP-LS encoding - that would have to 
be done in draft-ietf-idr-bgp-ls-app-specific-attr. We will work on that 
and update that draft.


From the ISIS perspective the behavior is unchanged - the 
Application-Specific SRLG TLVs have to be treated independently of the 
Application-Specific Link Attributes TLVs.


thanks,
Peter



Thanks,

Rudy

*From:*Lsr  *On Behalf Of *Shraddha Hegde
*Sent:* Thursday, June 17, 2021 7:14 AM
*To:* Les Ginsberg (ginsberg) ; Van De Velde, Gunter 
(Nokia - BE/Antwerp) ; lsr@ietf.org

*Cc:* DECRAENE Bruno IMT/OLN 
*Subject:* Re: [Lsr] Proposed Errata for RFCs 8919/8920

Les,


Whether ASLA sub-TLV is present in IS-Neighbor TLV and whether it has 
zero-length ABM on non-zero-length ABM is irrelevant to the use of ASLA SRLG 
TLV – and vice versa.


Can you state this explicitly in the document?

Rgds

Shraddha

Juniper Business Use Only

*From:*Les Ginsberg (ginsberg) <mailto:ginsb...@cisco.com>>

*Sent:* Wednesday, June 16, 2021 10:31 PM
*To:* Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>; 
Shraddha Hegde mailto:shrad...@juniper.net>>; 
lsr@ietf.org <mailto:lsr@ietf.org>
*Cc:* DECRAENE Bruno IMT/OLN <mailto:bruno.decra...@orange.com>>

*Subject:* RE: Proposed Errata for RFCs 8919/8920

*[External Email. Be cautious of content]*

Gunter –

There is no relationship between the ASLA SRLG TLV and IS-Neighbor TLV.

I do not understand why you would think that there is.

Whether ASLA sub-TLV is present in IS-Neighbor TLV and whether it has 
zero-length ABM on non-zero-length ABM is irrelevant to the use of ASLA 
SRLG TLV – and vice versa.


    Les

*From:*Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>

*Sent:* Wednesday, June 16, 2021 9:07 AM
*To:* Shraddha Hegde <mailto:shrad...@juniper.net>>; Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>>; lsr@ietf.org 
<mailto:lsr@ietf.org>
*Cc:* DECRAENE Bruno IMT/OLN <mailto:bruno.decra...@orange.com>>

*Subject:* RE: Proposed Errata for RFCs 8919/8920

Another item of ambiguity is whether “wildcarding” applies also to the 
ISIS TE-Appl-Spec-SRLG TLV.


It seems that the RFC8919 does not specify it.

Note: for OSPF the wildcarding also app

Re: [Lsr] Proposed Errata for RFCs 8919/8920

2021-06-17 Thread Selderslaghs, Rudy (Nokia - BE/Antwerp) 
Hi Les,

The question remains whether an ISIS Appl-Spec-SRLG TLV with SABML 0 and UDABML 
0 means that it is valid for all applications or not.
This is currently not specified in RFC8919.

Secondly the approach to handle ISIS Appl-Spec-SRLG TLVs independently from 
ASLA sub-TLVs in the context of overruling "All-Appl" attributes, creates 
confusion in BGP-LS in my opinion.
Take the following example with TLV's belonging to the same link:

IS-Neighbors TLV
 ASLA TLV
 SABML 0, UDABML 0 (= All Appl)
 TE-Metric 20
Appl-Spec-SRLG TLV
 SABML 1, UDABML 0, Bitmap SR-Policy
 SRLG 1

Following your answer, SR-Policy has to use TE-Metric 20 and SRLG 1.
Now suppose that the node that receives this ISIS advertisement has to pass 
this on to a server via BGP-LS, this will be the result:

Link Attributes:
ASLA TLV
SABML 0, UDABML 0 (= All Appl)
TE-Metric 20
ASLA TLV
SABML 1, UDABML 0, Bitmap SR-Policy
SRLG 1

The server that receives this BGP-LS advertisement, has to take into account 
that it comes from the ISIS protocol in order to treat the ASLA TLV with SRLG 
info independently (as ISIS is supposed to do). I.e. the ASLA TLV with SRLG 
info does not overrule the first ASLA TLV and the server has to use TE-Metric 
20 and SRLG 1 for SR-Policy.

If the server would receive the same BGP-LS advertisement  for the OSPF 
protocol, it can only use SRLG 1 for SR-Policy, because the second ASLA TLV 
overrules the first one in line with the OSPF rules.

I think this is confusing and that it is more consistent to treat an ISIS 
Appl-Spec-SRLG TLV as an ASLA TLV in the context of overruling of "All-Appl" 
attributes.
The fact that ISIS transports SRLG info via a separate TLV seems no reason to 
me to treat it independent of ASLA TLV's.

Thanks,
Rudy

From: Lsr  On Behalf Of Shraddha Hegde
Sent: Thursday, June 17, 2021 7:14 AM
To: Les Ginsberg (ginsberg) ; Van De Velde, Gunter (Nokia - 
BE/Antwerp) ; lsr@ietf.org
Cc: DECRAENE Bruno IMT/OLN 
Subject: Re: [Lsr] Proposed Errata for RFCs 8919/8920

Les,

> Whether ASLA sub-TLV is present in IS-Neighbor TLV and whether it has 
> zero-length ABM on non-zero-length ABM is irrelevant to the use of ASLA SRLG 
> TLV - and vice versa.

Can you state this explicitly in the document?

Rgds
Shraddha



Juniper Business Use Only
From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Wednesday, June 16, 2021 10:31 PM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>; Shraddha 
Hegde mailto:shrad...@juniper.net>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: DECRAENE Bruno IMT/OLN 
mailto:bruno.decra...@orange.com>>
Subject: RE: Proposed Errata for RFCs 8919/8920

[External Email. Be cautious of content]

Gunter -

There is no relationship between the ASLA SRLG TLV and IS-Neighbor TLV.
I do not understand why you would think that there is.

Whether ASLA sub-TLV is present in IS-Neighbor TLV and whether it has 
zero-length ABM on non-zero-length ABM is irrelevant to the use of ASLA SRLG 
TLV - and vice versa.

   Les


From: Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Sent: Wednesday, June 16, 2021 9:07 AM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; Les 
Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: DECRAENE Bruno IMT/OLN 
mailto:bruno.decra...@orange.com>>
Subject: RE: Proposed Errata for RFCs 8919/8920

Another item of ambiguity is whether "wildcarding" applies also to the ISIS 
TE-Appl-Spec-SRLG TLV.
It seems that the RFC8919 does not specify it.
Note: for OSPF the wildcarding also applies to SRLG info because it is 
transported via the same container TLV as the other TE attributes.

Example 1
TE-IS-NBRs TLV
 Link x
  ASLA TLV
  SABML 0, UDABML 0 (= All Appl)
  TE-Metric 20
TE-Appl-Spec-SRLG TLV
Link x
SABML 1, UDABML 0, Bitmap Flex-Algo
   SRLG 1 2 3

Should TE-Metric 20 be used for Flex-Algo or not ?
In other words, is the wildcard ASLA TLV overruled by the specific 
TE-Appl-Spec_SRLG TLV or not ?

Example 2
Maybe this is an invalid example if wildcarding does not apply for the 
TE-Appl-SRLG TLV.
TE-IS-NBRs
 Link x
  ASLA TLV
  SABML 1, UDABML 0, Bitmap Flex-Algo
  TE-Metric 20
TE-Appl-Spec-SRLG
Link x
SABML 0, UDABML 0 (= All Appl)
   SRLG 1 2 3

Should SRLG 1 2 3 be used for Flex-Algo or not ?

What is your opinion ?

G/


From: Shraddha Hegde mailto:shrad...@juniper.net>>
Sent: Wednesday, June 16, 2021 4:46 PM
To: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 lsr@ietf.org<mailto:lsr@ietf.org>
Cc: DECRAENE Bruno IMT/OLN 
mailto:bruno.decra...@orange.com>>; Van De Velde, 
Gunter (Nokia - BE/A

Re: [Lsr] Proposed Errata for RFCs 8919/8920

2021-06-16 Thread Shraddha Hegde 
gt;>; Van De Velde, 
Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: [Lsr] Proposed Errata for RFCs 8919/8920

[External Email. Be cautious of content]


Folks -



Recent discussions on the list have highlighted some unintentional ambiguity in 
how ASLA advertisements are to be used. Please see 
https://mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/__;!!NEt6yMaO-gk!RK_eZNNu1y0aJvAqIaNwHTIFAjHWFJwW1UqyOO8ACxB0kof3jmD_dRkiPkbVLJyA$>



The following proposed Errata address this ambiguity and aligns language in the 
two RFCs.



We welcome comments on the proposed Errata before officially filing them.



  Les and Peter


Errata Explanation

Both RFC 8919 and RFC 8920 define advertising link attributes with zero length 
Standard Application Bit Mask (SABM) and zero length User Defined Application 
Bit Mask (UDABM)
as a means of advertising link attributes that can be used by any application. 
However, the text uses the word "permitted", suggesting that the use of such 
advertisements is "optional".
Such an interpretation could lead to interoperability issues and is not what 
was intended.

The replacement text below makes explicit the specific conditions when such 
advertisements MUST be used and the specific conditions under which they MUST 
NOT be used.

RFC 8919 Section 4.2:

OLD

"If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications,
then any standard application and/or any user-defined application is permitted 
to use that set of link attributes so long as there is not another set of 
attributes
advertised on that same link that is associated with a non-zero-length 
Application Identifier Bit Mask with a matching Application Identifier Bit set."

NEW

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."

RFC 8919 Section 6.2

OLD

"Link attribute advertisements associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications are usable
by any application, subject to the restrictions specified in Section 4.2. If 
support for a new application is introduced on any node in a network in the 
presence of such
advertisements, these advertisements are permitted to be used by the new 
application. If this is not what is intended, then existing advertisements MUST 
be readvertised
with an explicit set of applications specified before a new application is 
introduced."


NEW

"Link attribute advertisements associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications are usable
by any application, subject to the restrictions specified in Section 4.2. If 
support for a new application is introduced on any node in a network in the 
presence of such
advertisements, the new application will use these advertisements, when the 
aforementioned restrictions are met. If this is not what is intended, then 
existing
advertisements MUST be readvertised with an explicit set of applications 
specified before a new application is introduced."



RFC 8920 Section 5

OLD

"If link attributes are advertised with zero-length Application Identifier Bit 
Masks for both standard applications and user-defined applications,
then any standard application and/or any user-defined application is permitted 
to use that set of link attributes. If support for a new application
is introduced on any node in a network in the presence of such advertisements, 
these advertisements are permitted to be used by the new
application. If this is not what is intended, then existing advertisements MUST 
be readvertised with an explicit set of applications specified
before a new application is introduced.

An application-specific advertisement (Application Identifier Bit Mask with a 
matching Application Identifier Bit set) for an attribute MUST
always be preferred over the advertisement of the same attribute with the 
zero-length Application Identifier Bit Masks for both standard
applications and user-defined applications on the same link."

NEW

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications whe

Re: [Lsr] Proposed Errata for RFCs 8919/8920

2021-06-16 Thread Shraddha Hegde 
Hi Les,

I am proposing to include the text I sent along with your text.

You basically want to imply that when there is an ASLA advertised with an 
application bit set
That application MUST use all link attributes that can appear in ASLA from only 
ASLAs
having the specific application bit set and MUST NOT use from zero ABM ASLAs. I 
agree it is possible to
Derive this from your latest text but I would prefer re-iterating this fact 
more directly than
Let the readers derive this information from current text.

Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used.
In other words,
When an application specific link Attribute sub-TLV is advertised for a link 
with one or more specific
standard application or user defined application bits set, all link attributes 
that are allowed in ASLA MUST
be used from the ASLA sub-TLVs having that specific application bit set for 
that link.
For the purposes of such applications, link attributes MUST NOT be used from
ASLA sub-TLV with zero SABM & UDABM length.

Rgds
Shraddha



Juniper Business Use Only
From: Les Ginsberg (ginsberg) 
Sent: Wednesday, June 16, 2021 10:26 PM
To: Shraddha Hegde ; Les Ginsberg (ginsberg) 
; lsr@ietf.org
Cc: DECRAENE Bruno IMT/OLN ; Van De Velde, Gunter 
(Nokia - BE/Antwerp) 
Subject: RE: Proposed Errata for RFCs 8919/8920

[External Email. Be cautious of content]

Shraddha -

I believe we are in agreement on when zero length ABM ASLA sub-TLVs can be used 
and when they cannot.

The new text we proposed is:

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."

This states both when zero-length ABM advertisements MUST be used and when they 
MUST NOT be used.

You have proposed different text:

"When an application specific link Attribute sub-TLV is advertised with one or 
more specific
standard application or user defined application bits set, all link attributes 
that are allowed in ASLA MUST
be used from the ASLA sub-TLVs having that specific application bit set.
For the purposes of such applications, link attributes MUST NOT be used from
ASLA sub-TLV with zero SABM & UDABM length."

This states when zero-length ABM advertisements MUST NOT be used - but it does 
not state when they MUST be used.
Instead, it states when non-zero length ABM advertisements MUST be used.
So this does not seem to be as complete as regards zero length ABM.

You seem to feel that there is confusion as to when non-zero ABM ASLA 
advertisements MUST be used - but I do not understand why that is the case.
You mention Maximum-Link-Bandwidth - for which there is a dedicated Section 
(4.2.1). The need for that section arises in order to make clear that different 
values for maximum-link-bandwidth are nonsensical and if they occur they all 
should be ignored.
But Section 4.2.1 also references Sections 4.2 and 6.2 to make clear that the 
same constraints regarding the use of zero length ABM advertisements apply to 
maximum-link-bandwidth.

So, I am not clear on what text is currently confusing, nor do I understand how 
your proposed text clarifies this confusion.

I am open to revising the proposed text - but I need more help from you to 
understand the source of confusion.

   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Shraddha Hegde
Sent: Wednesday, June 16, 2021 7:46 AM
To: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 lsr@ietf.org<mailto:lsr@ietf.org>
Cc: DECRAENE Bruno IMT/OLN 
mailto:bruno.decra...@orange.com>>; Van De Velde, 
Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: Re: [Lsr] Proposed Errata for RFCs 8919/8920

Hi,

I think that there may still be some ambiguity arising from the text below due 
to the fact that
There are attributes such as maximum-link-bandwidth which have special 
behaviour mentioned in later sections.

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisemen

Re: [Lsr] Proposed Errata for RFCs 8919/8920

2021-06-16 Thread Les Ginsberg (ginsberg) 
Gunter -

There is no relationship between the ASLA SRLG TLV and IS-Neighbor TLV.
I do not understand why you would think that there is.

Whether ASLA sub-TLV is present in IS-Neighbor TLV and whether it has 
zero-length ABM on non-zero-length ABM is irrelevant to the use of ASLA SRLG 
TLV - and vice versa.

   Les


From: Van De Velde, Gunter (Nokia - BE/Antwerp) 
Sent: Wednesday, June 16, 2021 9:07 AM
To: Shraddha Hegde ; Les Ginsberg (ginsberg) 
; lsr@ietf.org
Cc: DECRAENE Bruno IMT/OLN 
Subject: RE: Proposed Errata for RFCs 8919/8920

Another item of ambiguity is whether "wildcarding" applies also to the ISIS 
TE-Appl-Spec-SRLG TLV.
It seems that the RFC8919 does not specify it.
Note: for OSPF the wildcarding also applies to SRLG info because it is 
transported via the same container TLV as the other TE attributes.

Example 1
TE-IS-NBRs TLV
 Link x
  ASLA TLV
  SABML 0, UDABML 0 (= All Appl)
  TE-Metric 20
TE-Appl-Spec-SRLG TLV
Link x
SABML 1, UDABML 0, Bitmap Flex-Algo
   SRLG 1 2 3

Should TE-Metric 20 be used for Flex-Algo or not ?
In other words, is the wildcard ASLA TLV overruled by the specific 
TE-Appl-Spec_SRLG TLV or not ?

Example 2
Maybe this is an invalid example if wildcarding does not apply for the 
TE-Appl-SRLG TLV.
TE-IS-NBRs
 Link x
  ASLA TLV
  SABML 1, UDABML 0, Bitmap Flex-Algo
  TE-Metric 20
TE-Appl-Spec-SRLG
Link x
SABML 0, UDABML 0 (= All Appl)
   SRLG 1 2 3

Should SRLG 1 2 3 be used for Flex-Algo or not ?

What is your opinion ?

G/


From: Shraddha Hegde mailto:shrad...@juniper.net>>
Sent: Wednesday, June 16, 2021 4:46 PM
To: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 lsr@ietf.org<mailto:lsr@ietf.org>
Cc: DECRAENE Bruno IMT/OLN 
mailto:bruno.decra...@orange.com>>; Van De Velde, 
Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: RE: Proposed Errata for RFCs 8919/8920

Hi,

I think that there may still be some ambiguity arising from the text below due 
to the fact that
There are attributes such as maximum-link-bandwidth which have special 
behaviour mentioned in later sections.

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."


For example, If max link bandwidth attribute comes in a
Zero length SABM & UDABM and we have a Flex-algo specific ASLA
that does not have the max-link-bandwidth advertised, can
Flex-algo use max-link-bandwidth attribute?

My interpretation from modified text for ISIS is that,  it cannot use it.
I think there is no harm in re-iterating in order to avoid people reading is 
differently.

Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used.
In other words,
When an application specific link Attribute sub-TLV is advertised with one or 
more specific
standard application or user defined application bits set, all link attributes 
that are allowed in ASLA MUST
be used from the ASLA sub-TLVs having that specific application bit set.
For the purposes of such applications, link attributes MUST NOT be used from
ASLA sub-TLV with zero SABM & UDABM length.


Rgds
Shraddha



Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Les 
Ginsberg (ginsberg)
Sent: Tuesday, June 15, 2021 8:55 PM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Cc: DECRAENE Bruno IMT/OLN 
mailto:bruno.decra...@orange.com>>; Van De Velde, 
Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: [Lsr] Proposed Errata for RFCs 8919/8920

[External Email. Be cautious of content]


Folks -



Recent discussions on the list have highlighted some unintentional ambiguity in 
how ASLA advertisements are to be used. Please see 
https://mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/__;!!NEt6yMaO-gk!RK_eZNNu1y0aJvAqIaNwHTIFAjHWFJwW1UqyOO8ACxB0kof3jmD_dRkiPkbVLJyA$>



The following proposed Errata address this ambiguity and aligns language in the 
two RFCs.



We welcome comments on the proposed Errata b

Re: [Lsr] Proposed Errata for RFCs 8919/8920

2021-06-16 Thread Les Ginsberg (ginsberg) 
Shraddha -

I believe we are in agreement on when zero length ABM ASLA sub-TLVs can be used 
and when they cannot.

The new text we proposed is:

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."

This states both when zero-length ABM advertisements MUST be used and when they 
MUST NOT be used.

You have proposed different text:

"When an application specific link Attribute sub-TLV is advertised with one or 
more specific
standard application or user defined application bits set, all link attributes 
that are allowed in ASLA MUST
be used from the ASLA sub-TLVs having that specific application bit set.
For the purposes of such applications, link attributes MUST NOT be used from
ASLA sub-TLV with zero SABM & UDABM length."

This states when zero-length ABM advertisements MUST NOT be used - but it does 
not state when they MUST be used.
Instead, it states when non-zero length ABM advertisements MUST be used.
So this does not seem to be as complete as regards zero length ABM.

You seem to feel that there is confusion as to when non-zero ABM ASLA 
advertisements MUST be used - but I do not understand why that is the case.
You mention Maximum-Link-Bandwidth - for which there is a dedicated Section 
(4.2.1). The need for that section arises in order to make clear that different 
values for maximum-link-bandwidth are nonsensical and if they occur they all 
should be ignored.
But Section 4.2.1 also references Sections 4.2 and 6.2 to make clear that the 
same constraints regarding the use of zero length ABM advertisements apply to 
maximum-link-bandwidth.

So, I am not clear on what text is currently confusing, nor do I understand how 
your proposed text clarifies this confusion.

I am open to revising the proposed text - but I need more help from you to 
understand the source of confusion.

   Les


From: Lsr  On Behalf Of Shraddha Hegde
Sent: Wednesday, June 16, 2021 7:46 AM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org
Cc: DECRAENE Bruno IMT/OLN ; Van De Velde, Gunter 
(Nokia - BE/Antwerp) 
Subject: Re: [Lsr] Proposed Errata for RFCs 8919/8920

Hi,

I think that there may still be some ambiguity arising from the text below due 
to the fact that
There are attributes such as maximum-link-bandwidth which have special 
behaviour mentioned in later sections.

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."


For example, If max link bandwidth attribute comes in a
Zero length SABM & UDABM and we have a Flex-algo specific ASLA
that does not have the max-link-bandwidth advertised, can
Flex-algo use max-link-bandwidth attribute?

My interpretation from modified text for ISIS is that,  it cannot use it.
I think there is no harm in re-iterating in order to avoid people reading is 
differently.

Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used.
In other words,
When an application specific link Attribute sub-TLV is advertised with one or 
more specific
standard application or user defined application bits set, all link attributes 
that are allowed in ASLA MUST
be used from the ASLA sub-TLVs having that specific application bit set.
For the purposes of such applications, link attributes MUST NOT be used from
ASLA sub-TLV with zero SABM & UDABM length.


Rgds
Shraddha



Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Les 
Ginsberg (ginsberg)
Sent: Tuesday, June 15, 2021 8:55 PM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Cc: DECRAENE Bruno IMT/OLN 
mailto:bruno.decra...@orange.com>>; Van De Velde, 
Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: [Lsr] Proposed Errata for RFCs 8919/8920

[External Email. Be cautious of content]


Folks -



Recent discussions on t

Re: [Lsr] Proposed Errata for RFCs 8919/8920

2021-06-16 Thread Van De Velde, Gunter (Nokia - BE/Antwerp) 
Another item of ambiguity is whether "wildcarding" applies also to the ISIS 
TE-Appl-Spec-SRLG TLV.
It seems that the RFC8919 does not specify it.
Note: for OSPF the wildcarding also applies to SRLG info because it is 
transported via the same container TLV as the other TE attributes.

Example 1
TE-IS-NBRs TLV
 Link x
  ASLA TLV
  SABML 0, UDABML 0 (= All Appl)
  TE-Metric 20
TE-Appl-Spec-SRLG TLV
Link x
SABML 1, UDABML 0, Bitmap Flex-Algo
   SRLG 1 2 3

Should TE-Metric 20 be used for Flex-Algo or not ?
In other words, is the wildcard ASLA TLV overruled by the specific 
TE-Appl-Spec_SRLG TLV or not ?

Example 2
Maybe this is an invalid example if wildcarding does not apply for the 
TE-Appl-SRLG TLV.
TE-IS-NBRs
 Link x
  ASLA TLV
  SABML 1, UDABML 0, Bitmap Flex-Algo
  TE-Metric 20
TE-Appl-Spec-SRLG
Link x
SABML 0, UDABML 0 (= All Appl)
   SRLG 1 2 3

Should SRLG 1 2 3 be used for Flex-Algo or not ?

What is your opinion ?

G/


From: Shraddha Hegde 
Sent: Wednesday, June 16, 2021 4:46 PM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org
Cc: DECRAENE Bruno IMT/OLN ; Van De Velde, Gunter 
(Nokia - BE/Antwerp) 
Subject: RE: Proposed Errata for RFCs 8919/8920

Hi,

I think that there may still be some ambiguity arising from the text below due 
to the fact that
There are attributes such as maximum-link-bandwidth which have special 
behaviour mentioned in later sections.

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."


For example, If max link bandwidth attribute comes in a
Zero length SABM & UDABM and we have a Flex-algo specific ASLA
that does not have the max-link-bandwidth advertised, can
Flex-algo use max-link-bandwidth attribute?

My interpretation from modified text for ISIS is that,  it cannot use it.
I think there is no harm in re-iterating in order to avoid people reading is 
differently.

Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used.
In other words,
When an application specific link Attribute sub-TLV is advertised with one or 
more specific
standard application or user defined application bits set, all link attributes 
that are allowed in ASLA MUST
be used from the ASLA sub-TLVs having that specific application bit set.
For the purposes of such applications, link attributes MUST NOT be used from
ASLA sub-TLV with zero SABM & UDABM length.


Rgds
Shraddha



Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Les 
Ginsberg (ginsberg)
Sent: Tuesday, June 15, 2021 8:55 PM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Cc: DECRAENE Bruno IMT/OLN 
mailto:bruno.decra...@orange.com>>; Van De Velde, 
Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: [Lsr] Proposed Errata for RFCs 8919/8920

[External Email. Be cautious of content]


Folks -



Recent discussions on the list have highlighted some unintentional ambiguity in 
how ASLA advertisements are to be used. Please see 
https://mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/__;!!NEt6yMaO-gk!RK_eZNNu1y0aJvAqIaNwHTIFAjHWFJwW1UqyOO8ACxB0kof3jmD_dRkiPkbVLJyA$>



The following proposed Errata address this ambiguity and aligns language in the 
two RFCs.



We welcome comments on the proposed Errata before officially filing them.



  Les and Peter


Errata Explanation

Both RFC 8919 and RFC 8920 define advertising link attributes with zero length 
Standard Application Bit Mask (SABM) and zero length User Defined Application 
Bit Mask (UDABM)
as a means of advertising link attributes that can be used by any application. 
However, the text uses the word "permitted", suggesting that the use of such 
advertisements is "optional".
Such an interpretation could lead to interoperability issues and is not what 
was intended.

The replacement text below makes explicit the specific conditions when such 
advertisements MUST be used and the specific conditions under which they MUST 
NOT be used.

RFC 8919 Section 4.2:

O

Re: [Lsr] Proposed Errata for RFCs 8919/8920

2021-06-16 Thread Shraddha Hegde 
Hi,

I think that there may still be some ambiguity arising from the text below due 
to the fact that
There are attributes such as maximum-link-bandwidth which have special 
behaviour mentioned in later sections.

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."


For example, If max link bandwidth attribute comes in a
Zero length SABM & UDABM and we have a Flex-algo specific ASLA
that does not have the max-link-bandwidth advertised, can
Flex-algo use max-link-bandwidth attribute?

My interpretation from modified text for ISIS is that,  it cannot use it.
I think there is no harm in re-iterating in order to avoid people reading is 
differently.

Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used.
In other words,
When an application specific link Attribute sub-TLV is advertised with one or 
more specific
standard application or user defined application bits set, all link attributes 
that are allowed in ASLA MUST
be used from the ASLA sub-TLVs having that specific application bit set.
For the purposes of such applications, link attributes MUST NOT be used from
ASLA sub-TLV with zero SABM & UDABM length.


Rgds
Shraddha



Juniper Business Use Only
From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, June 15, 2021 8:55 PM
To: lsr@ietf.org
Cc: DECRAENE Bruno IMT/OLN ; Van De Velde, Gunter 
(Nokia - BE/Antwerp) 
Subject: [Lsr] Proposed Errata for RFCs 8919/8920

[External Email. Be cautious of content]


Folks -



Recent discussions on the list have highlighted some unintentional ambiguity in 
how ASLA advertisements are to be used. Please see 
https://mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/__;!!NEt6yMaO-gk!RK_eZNNu1y0aJvAqIaNwHTIFAjHWFJwW1UqyOO8ACxB0kof3jmD_dRkiPkbVLJyA$>



The following proposed Errata address this ambiguity and aligns language in the 
two RFCs.



We welcome comments on the proposed Errata before officially filing them.



  Les and Peter


Errata Explanation

Both RFC 8919 and RFC 8920 define advertising link attributes with zero length 
Standard Application Bit Mask (SABM) and zero length User Defined Application 
Bit Mask (UDABM)
as a means of advertising link attributes that can be used by any application. 
However, the text uses the word "permitted", suggesting that the use of such 
advertisements is "optional".
Such an interpretation could lead to interoperability issues and is not what 
was intended.

The replacement text below makes explicit the specific conditions when such 
advertisements MUST be used and the specific conditions under which they MUST 
NOT be used.

RFC 8919 Section 4.2:

OLD

"If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications,
then any standard application and/or any user-defined application is permitted 
to use that set of link attributes so long as there is not another set of 
attributes
advertised on that same link that is associated with a non-zero-length 
Application Identifier Bit Mask with a matching Application Identifier Bit set."

NEW

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."

RFC 8919 Section 6.2

OLD

"Link attribute advertisements associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications are usable
by any application, subject to the restrictions specified in Section 4.2. If 
support for a new application is introduced on any node in a network in the 
presence of such
advertisements, these advertisements are permitted to be used by

Re: [Lsr] Proposed Errata for RFCs 8919/8920

2021-06-15 Thread Les Ginsberg (ginsberg) 
Bruno -

Thanx for the prompt review.
I will incorporate your suggested change.

   Les


From: bruno.decra...@orange.com 
Sent: Tuesday, June 15, 2021 9:33 AM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org
Cc: Van De Velde, Gunter (Nokia - BE/Antwerp) 
Subject: RE: Proposed Errata for RFCs 8919/8920

Les, Peter,

Thank you for agreeing to clarify the sentence and for the effort put in 
proposing a new text.

Proposed text looks much better to me. I particularly like the either MUST or 
MUST NOT statement.

I have one comment.
In the RFC, the term "advertisement" is used to refer both to sub-TLV [1] and 
to ASLA attribute [2]
[1] https://www.rfc-editor.org/rfc/rfc8919.html#name-legacy-advertisements
[2] https://www.rfc-editor.org/rfc/rfc8919.html#name-advertising-application-spe

As such, I would have a slight preference to be explicit about the type of 
advertisement which is meant. Especially since Gunter, an AD and myself raised 
that exact point, and that OSPF and IS-IS did not seemed aligned on this.

I would propose the following change in RFC 8919 section 4.2 & RFC 8920 section 
5
OLD: Such advertisements MUST
NEW: Such link attribute advertisements MUST

(I'm aware that the previous sentence starts with "Link attributes MAY be 
advertised", which in general should be a clear enough reference. But since we 
are clarifying, IMHO the more straightforward the clarification, the better, 
especially for the OSPF document which seemed to use the alternative 
understanding)


I definitely agree that this wording affects interoperability and must be fixed.
I'm not taking position (and don't care) whether an errata is the appropriate 
way. I'm happy to leave this to the chairs and AD. But my understanding is that 
if the errata is not classified as "Verified", then we'll need a bis document.

Thanks,
Regards,
--Bruno

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, June 15, 2021 5:25 PM
To: lsr@ietf.org
Cc: DECRAENE Bruno INNOV/NET 
mailto:bruno.decra...@orange.com>>; Van De Velde, 
Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: Proposed Errata for RFCs 8919/8920


Folks -



Recent discussions on the list have highlighted some unintentional ambiguity in 
how ASLA advertisements are to be used. Please see 
https://mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/



The following proposed Errata address this ambiguity and aligns language in the 
two RFCs.



We welcome comments on the proposed Errata before officially filing them.



  Les and Peter


Errata Explanation

Both RFC 8919 and RFC 8920 define advertising link attributes with zero length 
Standard Application Bit Mask (SABM) and zero length User Defined Application 
Bit Mask (UDABM)
as a means of advertising link attributes that can be used by any application. 
However, the text uses the word "permitted", suggesting that the use of such 
advertisements is "optional".
Such an interpretation could lead to interoperability issues and is not what 
was intended.

The replacement text below makes explicit the specific conditions when such 
advertisements MUST be used and the specific conditions under which they MUST 
NOT be used.

RFC 8919 Section 4.2:

OLD

"If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications,
then any standard application and/or any user-defined application is permitted 
to use that set of link attributes so long as there is not another set of 
attributes
advertised on that same link that is associated with a non-zero-length 
Application Identifier Bit Mask with a matching Application Identifier Bit set."

NEW

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."

RFC 8919 Section 6.2

OLD

"Link attribute advertisements associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications are usable
by any application, subject to the restrictions specified in Section 4.2. If 
support for a new application is introduced on any node in a network in the 
presence of such
advertisements, these advertisements are permitted to be used by the new 
application. If this is not what is intended, then existing advertisements MUST 
be readvertised
with an explicit set of applications specified before a new application is 
introduced."


NEW

"Link attribute advertisements associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications

Re: [Lsr] Proposed Errata for RFCs 8919/8920

2021-06-15 Thread bruno.decraene 
Les, Peter,

Thank you for agreeing to clarify the sentence and for the effort put in 
proposing a new text.

Proposed text looks much better to me. I particularly like the either MUST or 
MUST NOT statement.

I have one comment.
In the RFC, the term "advertisement" is used to refer both to sub-TLV [1] and 
to ASLA attribute [2]
[1] https://www.rfc-editor.org/rfc/rfc8919.html#name-legacy-advertisements
[2] https://www.rfc-editor.org/rfc/rfc8919.html#name-advertising-application-spe

As such, I would have a slight preference to be explicit about the type of 
advertisement which is meant. Especially since Gunter, an AD and myself raised 
that exact point, and that OSPF and IS-IS did not seemed aligned on this.

I would propose the following change in RFC 8919 section 4.2 & RFC 8920 section 
5
OLD: Such advertisements MUST
NEW: Such link attribute advertisements MUST

(I'm aware that the previous sentence starts with "Link attributes MAY be 
advertised", which in general should be a clear enough reference. But since we 
are clarifying, IMHO the more straightforward the clarification, the better, 
especially for the OSPF document which seemed to use the alternative 
understanding)


I definitely agree that this wording affects interoperability and must be fixed.
I'm not taking position (and don't care) whether an errata is the appropriate 
way. I'm happy to leave this to the chairs and AD. But my understanding is that 
if the errata is not classified as "Verified", then we'll need a bis document.

Thanks,
Regards,
--Bruno

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, June 15, 2021 5:25 PM
To: lsr@ietf.org
Cc: DECRAENE Bruno INNOV/NET ; Van De Velde, Gunter 
(Nokia - BE/Antwerp) 
Subject: Proposed Errata for RFCs 8919/8920


Folks -



Recent discussions on the list have highlighted some unintentional ambiguity in 
how ASLA advertisements are to be used. Please see 
https://mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/



The following proposed Errata address this ambiguity and aligns language in the 
two RFCs.



We welcome comments on the proposed Errata before officially filing them.



  Les and Peter


Errata Explanation

Both RFC 8919 and RFC 8920 define advertising link attributes with zero length 
Standard Application Bit Mask (SABM) and zero length User Defined Application 
Bit Mask (UDABM)
as a means of advertising link attributes that can be used by any application. 
However, the text uses the word "permitted", suggesting that the use of such 
advertisements is "optional".
Such an interpretation could lead to interoperability issues and is not what 
was intended.

The replacement text below makes explicit the specific conditions when such 
advertisements MUST be used and the specific conditions under which they MUST 
NOT be used.

RFC 8919 Section 4.2:

OLD

"If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications,
then any standard application and/or any user-defined application is permitted 
to use that set of link attributes so long as there is not another set of 
attributes
advertised on that same link that is associated with a non-zero-length 
Application Identifier Bit Mask with a matching Application Identifier Bit set."

NEW

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."

RFC 8919 Section 6.2

OLD

"Link attribute advertisements associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications are usable
by any application, subject to the restrictions specified in Section 4.2. If 
support for a new application is introduced on any node in a network in the 
presence of such
advertisements, these advertisements are permitted to be used by the new 
application. If this is not what is intended, then existing advertisements MUST 
be readvertised
with an explicit set of applications specified before a new application is 
introduced."


NEW

"Link attribute advertisements associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications are usable
by any application, subject to the restrictions specified in Section 4.2. If 
support for a new application is introduced on any node in a network in the 
presence of such
advertisements, the new application will use these advertisements, when the 
aforementioned restrictions are met. If this is not what is intended, then 
existing
advertisements MUST be readvertised with an expli

[Lsr] Proposed Errata for RFCs 8919/8920

2021-06-15 Thread Les Ginsberg (ginsberg) 
Folks -



Recent discussions on the list have highlighted some unintentional ambiguity in 
how ASLA advertisements are to be used. Please see 
https://mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/



The following proposed Errata address this ambiguity and aligns language in the 
two RFCs.



We welcome comments on the proposed Errata before officially filing them.



  Les and Peter


Errata Explanation

Both RFC 8919 and RFC 8920 define advertising link attributes with zero length 
Standard Application Bit Mask (SABM) and zero length User Defined Application 
Bit Mask (UDABM)
as a means of advertising link attributes that can be used by any application. 
However, the text uses the word "permitted", suggesting that the use of such 
advertisements is "optional".
Such an interpretation could lead to interoperability issues and is not what 
was intended.

The replacement text below makes explicit the specific conditions when such 
advertisements MUST be used and the specific conditions under which they MUST 
NOT be used.

RFC 8919 Section 4.2:

OLD

"If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications,
then any standard application and/or any user-defined application is permitted 
to use that set of link attributes so long as there is not another set of 
attributes
advertised on that same link that is associated with a non-zero-length 
Application Identifier Bit Mask with a matching Application Identifier Bit set."

NEW

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."

RFC 8919 Section 6.2

OLD

"Link attribute advertisements associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications are usable
by any application, subject to the restrictions specified in Section 4.2. If 
support for a new application is introduced on any node in a network in the 
presence of such
advertisements, these advertisements are permitted to be used by the new 
application. If this is not what is intended, then existing advertisements MUST 
be readvertised
with an explicit set of applications specified before a new application is 
introduced."


NEW

"Link attribute advertisements associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications are usable
by any application, subject to the restrictions specified in Section 4.2. If 
support for a new application is introduced on any node in a network in the 
presence of such
advertisements, the new application will use these advertisements, when the 
aforementioned restrictions are met. If this is not what is intended, then 
existing
advertisements MUST be readvertised with an explicit set of applications 
specified before a new application is introduced."



RFC 8920 Section 5

OLD

"If link attributes are advertised with zero-length Application Identifier Bit 
Masks for both standard applications and user-defined applications,
then any standard application and/or any user-defined application is permitted 
to use that set of link attributes. If support for a new application
is introduced on any node in a network in the presence of such advertisements, 
these advertisements are permitted to be used by the new
application. If this is not what is intended, then existing advertisements MUST 
be readvertised with an explicit set of applications specified
before a new application is introduced.

An application-specific advertisement (Application Identifier Bit Mask with a 
matching Application Identifier Bit set) for an attribute MUST
always be preferred over the advertisement of the same attribute with the 
zero-length Application Identifier Bit Masks for both standard
applications and user-defined applications on the same link."

NEW

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."



RFC 8920 New Section between 12.1 and 12.2. Current sections following this new 
section will need to be renumbered.


12.2 Use of Zero-Length Application Identifier Bit Masks

"Link attribute advertisements associated with zero-len