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

[Shraddha Hegde]

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) 
Sent: Wednesday, June 16, 2021 10:31 PM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
Shraddha Hegde ; lsr@ietf.org
Cc: DECRAENE Bruno IMT/OLN 
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
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
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
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 

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

[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
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 

Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt

[Joel M. Halpern]

This document (and the code point) are intended to be in line with 5309. 
 I believe they are.  If we got it wrong, please help us fix it.


A reference would be reasonable to add.  (The IANA entry for the code 
point does reference 5309.)


Thank you,
Joel



On 6/16/2021 4:41 PM, Acee Lindem (acee) wrote:

Hi Joel,

At first I wondered where this document should reside and then decided that LSR 
is probably as good as any other place.

Can you guys check whether it is mostly in line with 
https://datatracker.ietf.org/doc/rfc5309/ and comment as to whether it should 
be referenced?

Thanks,
Acee


On 6/16/21, 11:10 AM, "Lsr on behalf of Joel M. Halpern"  wrote:

 Recently, Ericsson requested and received an IF Type assignment from
 IANA (with expert review) for point-to-point over Ethernet links.

 It was noted during the discussion around the assignment that a document
 (eventually, we hope, an RFC) describing how to use that and why we
 asked for it would be helpful.

 The below announcement is that draft.  We would like to work with the
 community to improve and clarify teh draft.

 Thank you,
 Joel


  Forwarded Message 
 Subject: I-D Action: draft-liu-lsr-p2poverlan-00.txt
 Date: Wed, 16 Jun 2021 07:00:04 -0700
 From: internet-dra...@ietf.org
 Reply-To: internet-dra...@ietf.org
 To: i-d-annou...@ietf.org


 A New Internet-Draft is available from the on-line Internet-Drafts
 directories.


  Title   : Interface Stack Table Definition for Point to
 Point (P2P) Interface over LAN
  Authors : Daiying Liu
Joel Halpern
Congjie Zhang
Filename: draft-liu-lsr-p2poverlan-00.txt
Pages   : 7
Date: 2021-06-16

 Abstract:
 The point-to-point circuit type is one of the mainly used circuit
 types in link state routing protocol.  It is important to identify
 the correct circuit type when forming adjacencies, flooding link
 state database packets, and monitor the link state.  This document
 defines point-to-point interface type and relevant stack tables to
 provide benefit for operation, maintenance and statistics.


 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-liu-lsr-p2poverlan/

 There is also an htmlized version available at:
 https://datatracker.ietf.org/doc/html/draft-liu-lsr-p2poverlan-00


 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/


 ___
 I-D-Announce mailing list
 i-d-annou...@ietf.org
 https://www.ietf.org/mailman/listinfo/i-d-announce
 Internet-Draft directories: http://www.ietf.org/shadow.html
 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

 ___
 Lsr mailing list
 Lsr@ietf.org
 https://www.ietf.org/mailman/listinfo/lsr



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt

[Acee Lindem (acee)]

Hi Joel,

At first I wondered where this document should reside and then decided that LSR 
is probably as good as any other place. 

Can you guys check whether it is mostly in line with 
https://datatracker.ietf.org/doc/rfc5309/ and comment as to whether it should 
be referenced? 

Thanks,
Acee


On 6/16/21, 11:10 AM, "Lsr on behalf of Joel M. Halpern"  wrote:

Recently, Ericsson requested and received an IF Type assignment from 
IANA (with expert review) for point-to-point over Ethernet links.

It was noted during the discussion around the assignment that a document 
(eventually, we hope, an RFC) describing how to use that and why we 
asked for it would be helpful.

The below announcement is that draft.  We would like to work with the 
community to improve and clarify teh draft.

Thank you,
Joel


 Forwarded Message 
Subject: I-D Action: draft-liu-lsr-p2poverlan-00.txt
Date: Wed, 16 Jun 2021 07:00:04 -0700
From: internet-dra...@ietf.org
Reply-To: internet-dra...@ietf.org
To: i-d-annou...@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


 Title   : Interface Stack Table Definition for Point to 
Point (P2P) Interface over LAN
 Authors : Daiying Liu
   Joel Halpern
   Congjie Zhang
Filename: draft-liu-lsr-p2poverlan-00.txt
Pages   : 7
Date: 2021-06-16

Abstract:
The point-to-point circuit type is one of the mainly used circuit
types in link state routing protocol.  It is important to identify
the correct circuit type when forming adjacencies, flooding link
state database packets, and monitor the link state.  This document
defines point-to-point interface type and relevant stack tables to
provide benefit for operation, maintenance and statistics.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-liu-lsr-p2poverlan/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-liu-lsr-p2poverlan-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Second Working Last Call for draft-ietf-lsr-flex-algo

[Clarence Filsfils (cfilsfil)]

I am not aware of any undisclosed IPR related to this document.

Cheers,
Clarence

From: Acee Lindem (acee) 
Sent: Wednesday, June 16, 2021 16:01
To: lsr@ietf.org
Cc: Christian Hopps ; lsr-...@ietf.org; 
draft-ietf-lsr-flex-algo@ietf.org
Subject: Second Working Last Call for draft-ietf-lsr-flex-algo

After the first successful WG last call, the authors discovered that some 
re-work was needed for OSPF AS External route calculation – specifically with 
respect to the Flex Algorithm ASBR metrics and calculation. This was fixed and 
there were clarifications in the IANA section (see versions -14 and -15). The 
draft has been stable since April and we are now ready to WG last call the 
updated version.


Without further ado, this begins a 2 week WG Last Call, ending on July 1st, 
2021, for draft-ietf-lsr-flex-algo

  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

All authors, please indicate by sending an email to the list, whether you aware 
of any other IPR beyond what is already posted:

  [From 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-flex-algo]

  https://datatracker.ietf.org/ipr/3910/
  https://datatracker.ietf.org/ipr/3248/

Thanks,
Chris & Acee.


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[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
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
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/



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 

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

[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
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 

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

[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
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/



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 

[Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt

[Joel M. Halpern]

Recently, Ericsson requested and received an IF Type assignment from 
IANA (with expert review) for point-to-point over Ethernet links.


It was noted during the discussion around the assignment that a document 
(eventually, we hope, an RFC) describing how to use that and why we 
asked for it would be helpful.


The below announcement is that draft.  We would like to work with the 
community to improve and clarify teh draft.


Thank you,
Joel


 Forwarded Message 
Subject: I-D Action: draft-liu-lsr-p2poverlan-00.txt
Date: Wed, 16 Jun 2021 07:00:04 -0700
From: internet-dra...@ietf.org
Reply-To: internet-dra...@ietf.org
To: i-d-annou...@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.



Title   : Interface Stack Table Definition for Point to 
Point (P2P) Interface over LAN

Authors : Daiying Liu
  Joel Halpern
  Congjie Zhang
Filename: draft-liu-lsr-p2poverlan-00.txt
Pages   : 7
Date: 2021-06-16

Abstract:
   The point-to-point circuit type is one of the mainly used circuit
   types in link state routing protocol.  It is important to identify
   the correct circuit type when forming adjacencies, flooding link
   state database packets, and monitor the link state.  This document
   defines point-to-point interface type and relevant stack tables to
   provide benefit for operation, maintenance and statistics.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-liu-lsr-p2poverlan/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-liu-lsr-p2poverlan-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[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/



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 

Re: [Lsr] Second Working Last Call for draft-ietf-lsr-flex-algo

[Ketan Talaulikar (ketant)]

Hi Acee/All,

I am not aware of any undisclosed IPR related to this draft.

Thanks,
Ketan

From: Acee Lindem (acee) 
Sent: 16 June 2021 19:31
To: lsr@ietf.org
Cc: Christian Hopps ; lsr-...@ietf.org; 
draft-ietf-lsr-flex-algo@ietf.org
Subject: Second Working Last Call for draft-ietf-lsr-flex-algo

After the first successful WG last call, the authors discovered that some 
re-work was needed for OSPF AS External route calculation – specifically with 
respect to the Flex Algorithm ASBR metrics and calculation. This was fixed and 
there were clarifications in the IANA section (see versions -14 and -15). The 
draft has been stable since April and we are now ready to WG last call the 
updated version.


Without further ado, this begins a 2 week WG Last Call, ending on July 1st, 
2021, for draft-ietf-lsr-flex-algo

  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

All authors, please indicate by sending an email to the list, whether you aware 
of any other IPR beyond what is already posted:

  [From 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-flex-algo]

  https://datatracker.ietf.org/ipr/3910/
  https://datatracker.ietf.org/ipr/3248/

Thanks,
Chris & Acee.


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Second Working Last Call for draft-ietf-lsr-flex-algo

[Peter Psenak]

Hi Acee,

I'm not aware of any other IPR beyond what is already posted.

thanks,
Peter

On 16/06/2021 16:00, Acee Lindem (acee) wrote:
After the first successful WG last call, the authors discovered that 
some re-work was needed for OSPF AS External route calculation – 
specifically with respect to the Flex Algorithm ASBR metrics and 
calculation. This was fixed and there were clarifications in the IANA 
section (see versions -14 and -15). The draft has been stable since 
April and we are now ready to WG last call the updated version.


Without further ado, this begins a 2 week WG Last Call, ending on July 
1st, 2021, for draft-ietf-lsr-flex-algo


   https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

All authors, please indicate by sending an email to the list, whether 
you aware of any other IPR beyond what is already posted:


   [From 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-flex-algo]


   https://datatracker.ietf.org/ipr/3910/

   https://datatracker.ietf.org/ipr/3248/

Thanks,

Chris & Acee.



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Second Working Last Call for draft-ietf-lsr-flex-algo

[Acee Lindem (acee)]

After the first successful WG last call, the authors discovered that some 
re-work was needed for OSPF AS External route calculation – specifically with 
respect to the Flex Algorithm ASBR metrics and calculation. This was fixed and 
there were clarifications in the IANA section (see versions -14 and -15). The 
draft has been stable since April and we are now ready to WG last call the 
updated version.


Without further ado, this begins a 2 week WG Last Call, ending on July 1st, 
2021, for draft-ietf-lsr-flex-algo

  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

All authors, please indicate by sending an email to the list, whether you aware 
of any other IPR beyond what is already posted:

  [From 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-flex-algo]

  https://datatracker.ietf.org/ipr/3910/
  https://datatracker.ietf.org/ipr/3248/

Thanks,
Chris & Acee.


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr