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) <gunter.van_de_ve...@nokia.com>
Sent: Wednesday, June 16, 2021 9:07 AM
To: Shraddha Hegde <shrad...@juniper.net>; Les Ginsberg (ginsberg)
<ginsb...@cisco.com>; lsr@ietf.org
Cc: DECRAENE Bruno IMT/OLN <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 <shrad...@juniper.net<mailto:shrad...@juniper.net>>
Sent: Wednesday, June 16, 2021 4:46 PM
To: Les Ginsberg (ginsberg)
<ginsberg=40cisco....@dmarc.ietf.org<mailto:ginsberg=40cisco....@dmarc.ietf.org>>;
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: DECRAENE Bruno IMT/OLN
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>; Van De Velde,
Gunter (Nokia - BE/Antwerp)
<gunter.van_de_ve...@nokia.com<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 <lsr-boun...@ietf.org<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
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>; Van De Velde,
Gunter (Nokia - BE/Antwerp)
<gunter.van_de_ve...@nokia.com<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 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-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 5. 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."
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
