Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[Dongjie (Jimmy)]

Hi PSF,

Thanks for your pointer to another document which defines the encodings of 
per-Algo TE link attributes.

But my comments are related to the text in section 3 and 5 of this document, 
which describes new use cases and operation of Flex-Algo with per Flex-Algo 
resource reservation or per Flex-Algo QoS policy on the same link. These 
require extensions to the function of Flex-Algo, which IMO needs to be 
discussed and compared with other alternative mechanisms. And as you indicated, 
there are related encoding extensions proposed in other document, thus it may 
not be just a local behavior. 

So could you reply to the comments in my previous mail?

Best regards,
Jie

> -Original Message-
> From: peng.sha...@zte.com.cn [mailto:peng.sha...@zte.com.cn]
> Sent: Friday, May 28, 2021 12:00 PM
> To: Dongjie (Jimmy) 
> Cc: cho...@chopps.org; lsr@ietf.org
> Subject: Re:[Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency
> SID Advertisement"
> 
> Hi Jie,
> 
> Thanks for your comments.
> 
> In this document, there are not any extensions to describe resource 
> reservation
> per algo. Are you aiming at another draft
> (https://datatracker.ietf.org/doc/draft-cp-lsr-fa-aware-te/) ?  Please find 
> out
> what you are talking about first.
> Adj-SID per algo can distinguish traffic behavior in local. You are welcome to
> add more usecases based on section 3.
> 
> Regards,
> PSF
> 
> 
> --原始邮件--
> 发件人：Dongjie(Jimmy)
> 收件人：Christian Hopps;lsr@ietf.org;
> 日 期 ：2021年05月28日 11:40
> 主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency
> SID Advertisement"
> Hi,
> I don't support the adoption of this document.
> It seems this document aims to introduce per Flex-Algo Adj-SID to SR-MPLS, its
> typical use case is to provide protection path with Flex-Algo constraints for
> Adj-SID of a particular Flex-Algo, which is described in the case 3 of 
> section 3.
> However, section 3 and section 5 shows that it also aims to introduce further
> changes to the usage and operation of Flex-Algo, which is to provide resource
> reservation based on Flex-Algo. IMO these changes to Flex-Algo deserves
> further discussion and is not only related to the per Flex-Algo Adj-SID 
> extension.
> Here are some comments about this change to Flex-Algo:
> 1. Flex-Algo defines the constraints for path computation in a distributed
> manner, it is not for resource reservation.
> 2. Reserving resources for each Flex-Algo on a link does not make sense. The
> correlation between Flex-Algo and the network links is based on administrative
> groups (color), and the color of the link may or may not be included in the
> Flex-Algo definition. To follow the color based link correlation, a more 
> practical
> approach would be to use Flex-Algo with L2 bundle as defined in
> draft-zhu-lsr-isis-sr-vtn-flexalgo, which uses color to correlate the L3 link 
> and
> the L2 member link to a Flex-Algo, this avoids the extension for per-FlexAlgo
> resource reservation.
> 3. The Flex-Algo link TE attributes are advertised using ASLA, the TE 
> attributes
> are shared by all Flex-Algos which include the link according to the FAD, and
> based on previous discussion, it seems there is no intention to introduce per
> Flex-Algo ID link attributes.
> Best regards,
> Jie
> > -Original Message-
> > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> > Sent: Thursday, May 27, 2021 4:57 AM
> > To: lsr@ietf.org
> > Cc: cho...@chopps.org
> > Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related
> > IGP-Adjacency SID Advertisement"
> >
> >
> > Hi Folks,
> >
> > This begins a 2 week WG Adoption Call for the following draft:
> >
> > https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adja
> > cency-sid
> > /
> >
> > Please indicate your support or objections by June 9th, 2021
> >
> > Authors, please respond to the list indicating whether you are aware
> > of any IPR that applies to this draft.
> >
> > Thanks,
> > Acee and Chris.
> >
> > ___
> > 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
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[peng.shaofu]

Hi Jie,

Thanks for your comments.

In this document, there are not any extensions to describe resource reservation 
per algo. Are you aiming at another draft 
(https://datatracker.ietf.org/doc/draft-cp-lsr-fa-aware-te/) ?  Please find out 
what you are talking about first.
Adj-SID per algo can distinguish traffic behavior in local. You are welcome to 
add more usecases based on section 3.

Regards,
PSF


--原始邮件--
发件人：Dongjie(Jimmy)
收件人：Christian Hopps;lsr@ietf.org;
日 期 ：2021年05月28日 11:40
主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"
Hi,
I don't support the adoption of this document.
It seems this document aims to introduce per Flex-Algo Adj-SID to SR-MPLS, its 
typical use case is to provide protection path with Flex-Algo constraints for 
Adj-SID of a particular Flex-Algo, which is described in the case 3 of section 
3.
However, section 3 and section 5 shows that it also aims to introduce further 
changes to the usage and operation of Flex-Algo, which is to provide resource 
reservation based on Flex-Algo. IMO these changes to Flex-Algo deserves further 
discussion and is not only related to the per Flex-Algo Adj-SID extension.
Here are some comments about this change to Flex-Algo:
1. Flex-Algo defines the constraints for path computation in a distributed 
manner, it is not for resource reservation.
2. Reserving resources for each Flex-Algo on a link does not make sense. The 
correlation between Flex-Algo and the network links is based on administrative 
groups (color), and the color of the link may or may not be included in the 
Flex-Algo definition. To follow the color based link correlation, a more 
practical approach would be to use Flex-Algo with L2 bundle as defined in 
draft-zhu-lsr-isis-sr-vtn-flexalgo, which uses color to correlate the L3 link 
and the L2 member link to a Flex-Algo, this avoids the extension for 
per-FlexAlgo resource reservation.
3. The Flex-Algo link TE attributes are advertised using ASLA, the TE 
attributes are shared by all Flex-Algos which include the link according to the 
FAD, and based on previous discussion, it seems there is no intention to 
introduce per Flex-Algo ID link attributes.
Best regards,
Jie
> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> Sent: Thursday, May 27, 2021 4:57 AM
> To: lsr@ietf.org
> Cc: cho...@chopps.org
> Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID
> Advertisement"
>
>
> Hi Folks,
>
> This begins a 2 week WG Adoption Call for the following draft:
>
> https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-sid
> /
>
> Please indicate your support or objections by June 9th, 2021
>
> Authors, please respond to the list indicating whether you are aware of any 
> IPR
> that applies to this draft.
>
> Thanks,
> Acee and Chris.
>
> ___
> 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___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[Dongjie (Jimmy)]

Hi,

I don't support the adoption of this document. 

It seems this document aims to introduce per Flex-Algo Adj-SID to SR-MPLS, its 
typical use case is to provide protection path with Flex-Algo constraints for 
Adj-SID of a particular Flex-Algo, which is described in the case 3 of section 
3. 

However, section 3 and section 5 shows that it also aims to introduce further 
changes to the usage and operation of Flex-Algo, which is to provide resource 
reservation based on Flex-Algo. IMO these changes to Flex-Algo deserves further 
discussion and is not only related to the per Flex-Algo Adj-SID extension.

Here are some comments about this change to Flex-Algo:

1. Flex-Algo defines the constraints for path computation in a distributed 
manner, it is not for resource reservation. 

2. Reserving resources for each Flex-Algo on a link does not make sense. The 
correlation between Flex-Algo and the network links is based on administrative 
groups (color), and the color of the link may or may not be included in the 
Flex-Algo definition. To follow the color based link correlation, a more 
practical approach would be to use Flex-Algo with L2 bundle as defined in 
draft-zhu-lsr-isis-sr-vtn-flexalgo, which uses color to correlate the L3 link 
and the L2 member link to a Flex-Algo, this avoids the extension for 
per-FlexAlgo resource reservation. 

3. The Flex-Algo link TE attributes are advertised using ASLA, the TE 
attributes are shared by all Flex-Algos which include the link according to the 
FAD, and based on previous discussion, it seems there is no intention to 
introduce per Flex-Algo ID link attributes.

Best regards,
Jie

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> Sent: Thursday, May 27, 2021 4:57 AM
> To: lsr@ietf.org
> Cc: cho...@chopps.org
> Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID
> Advertisement"
> 
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
> https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-sid
> /
> 
> Please indicate your support or objections by June 9th, 2021
> 
> Authors, please respond to the list indicating whether you are aware of any 
> IPR
> that applies to this draft.
> 
> Thanks,
> Acee and Chris.
> 
> ___
> 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] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[peng.shaofu]

Hi Acee and Chris,

Support the adoption as co-author. 
And I'm not aware of any undisclosed IPR related to this draft.

Regards,
PSF


--原始邮件--
发件人：ChristianHopps
收件人：lsr@ietf.org;
抄送人：cho...@chopps.org;
日 期 ：2021年05月27日 05:00
主 题 ：[Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"

Hi Folks,
This begins a 2 week WG Adoption Call for the following draft:
https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-sid/
Please indicate your support or objections by June 9th, 2021
Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.
Thanks,
Acee and Chris.
___
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] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Acee Lindem (acee)]

Thanks – I now have all the declarations.
Acee

From: Rajesh M 
Date: Thursday, May 27, 2021 at 12:39 PM
To: Acee Lindem , "lsr@ietf.org" 
Cc: "draft-hegde-lsr-flex-algo-bw-...@ietf.org" 

Subject: RE: LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

I am not aware of any IPR that applies to this draft.

Thanks,
Rajesh




Juniper Business Use Only
From: Acee Lindem (acee) 
Sent: Thursday, May 13, 2021 2:39 AM
To: lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Esteemed Members of the LSR WG,

This begins a 2 week WG adoption call for the following draft:

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

Please indicate your support or objection by May 27th, 2021.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris and Acee


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

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Rajesh M]

I am not aware of any IPR that applies to this draft.

Thanks,
Rajesh




Juniper Business Use Only
From: Acee Lindem (acee) 
Sent: Thursday, May 13, 2021 2:39 AM
To: lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Esteemed Members of the LSR WG,

This begins a 2 week WG adoption call for the following draft:

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

Please indicate your support or objection by May 27th, 2021.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris and Acee


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

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[William Britto A J]

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

Thanks,
William

From: Lsr  on behalf of Acee Lindem (acee) 

Date: Thursday, 13 May 2021 at 2:51 AM
To: lsr@ietf.org 
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org 

Subject: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
[External Email. Be cautious of content]

Esteemed Members of the LSR WG,

This begins a 2 week WG adoption call for the following draft:

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

Please indicate your support or objection by May 27th, 2021.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris and Acee




Juniper Business Use Only
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] IPR Disclosure ZTE Corporation's Statement about IPR related to draft-peng-lsr-algorithm-related-adjacency-sid

[IETF Secretariat]

Dear Shaofu Peng, Ran Chen, Ketan Talaulikar, Peter Psenak:


An IPR disclosure that pertains to your Internet-Draft entitled "Algorithm
Related IGP-Adjacency SID Advertisement"
(draft-peng-lsr-algorithm-related-adjacency-sid) was submitted to the IETF
Secretariat on 2021-05-26 and has been posted on the "IETF Page of
Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/4888/). The title of the IPR disclosure is
"ZTE Corporation's Statement about IPR related to
draft-peng-lsr-algorithm-related-adjacency-sid"


Thank you

IETF Secretariat


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

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Peter Psenak]

Hi Ketan,

On 27/05/2021 15:37, Ketan Talaulikar (ketant) wrote:



For ISIS, Maximum Link Bandwidth sub-TLV is allowed in ASLA just that 
different values for different applications is not allowed. Maximum Link 
bandwidth is also allowed with all bits set to zero in SABM/UDABM  or 
each individual application bit set for all applications making use of ASLA.


*/[KT2] Yes, you are correct. The RFC8919 does not mandate or require 
Max Link Bandwidth to be signaled within ASLA (at least that was my 
reading). If so, perhaps it is better to not require that in this 
document – just keep in the base. Would that not work? And if it were 
advertised in the ASLA (as RFC8919 allows it), then perhaps a reference 
to the RFC8919 will be important on how it is to be done – basically 
exactly what you described above./*




given that RFC8919 allows the Max Link Bandwidth to be signaled within 
ASLA, we need to be able to support it, in case someone uses that. What 
we would probably need to do is to look at the ASLA advertisement of Max 
Link Bandwidth first and if none is available fallback to legacy 
advertisement.


thanks,
Peter

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

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Ketan Talaulikar (ketant)]

Hi Shraddha,

This is a new attribute that we are introducing and we are saying that it has 
application specific semantics. We now have the ASLA mechanics defined in both 
OSPF and ISIS. So why should it not use just the ASLA encoding?

Allowing its advertisement in the existing top-level TLVs in addition to ASLA 
introduces ambiguity for which applications can use it - we get into 
complications that are entirely avoidable.

Thanks,
Ketan

From: Shraddha Hegde 
Sent: 27 May 2021 18:36
To: Ketan Talaulikar (ketant) ; Tony Li 
Cc: Acee Lindem (acee) ; lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Snipped..


  1.  Since the draft is covering FlexAlgo, I would have expected that Generic 
Metric is carried only in the ASLA and this document specifies usage only for 
the FA application. Later this can be also used/extended for other applications 
but still within ASLA. Keeping an option of advertising both outside and within 
the ASLA is problematic - we will need precedence rules and such. I prefer we 
avoid this complication.


We preferred avoiding ASLA.
[KT] The text today does not avoid ASLA and in fact requires the use of ASLA 
(quite correctly) for FlexAlgo application. Peter has confirmed the same. I am 
simply asking to avoid the complications of using Generic Metric in both ASLA 
and outside it. Whatever new "application" we invent to use this generic metric 
type, can use ASLA so that the Generic Metric can be very cleanly shared 
between applications. The encoding allows for using the same value - sharing 
single advertisement across applications or doing a different one 
per-application.
 Generic metric is allowed in ASLA, it is also allowed in all 
traditional TLVs/LSAs where link attributes are advertised.
This is required so that all the applications, existing and new can make use of 
generic metric.



Juniper Business Use Only
From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Wednesday, May 26, 2021 12:09 PM
To: Tony Li mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Hi Tony,

Please check inline below.

From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: 25 May 2021 00:15
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02


Hi Ketan,

In general, I support the adoption of this document. There is, however, one 
specific point which is not clear to me (8) below that I would appreciate some 
clarity on before adoption.


As the chairs have noted, adoption is binary and not contingent upon rough 
consensus on the content, just on rough consensus on the interest.
[KT] I believe the WG has (or must have) the ability to determine portions of 
the proposal to adopt and/or to split documents. I have seen this in recent 
past in other WGs. In any case, it is not a point that I wish to argue or 
debate on - especially in the context of this document. My point (8) was 
clarified and hence I fall in the binary YES in this instance.


  1.  Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF 
allows 4 byte size and so why not the same for ISIS? Elsewhere in the document, 
I do see MAX METRIC being referred to as 4,261,412,864.


Because I'm a lazy sod.

It's far easier to detect metric overflow on three byte values than four byte 
values. True, four byte is not impossible, but it's just quick and easy with 
three byte values.  Adding a fourth byte would add range to the metric space, 
but in practice, this seemed like it was not really relevant. Most areas are 
not a very high diameter and the need for detailed metric distinctions has not 
been that high.  Thus, we went with a 3 byte metric in RFC 5305 (sec 3.7) and 
that seems to work.
[KT] The Generic Metric is by definition something that will get extended in 
the future and we don't know what use-cases might arise. It doesn't seem right 
to follow in the steps of an administratively assigned metric type like the TE 
metric. Therefore, I suggest to make it variable.

[KT] Regarding metric overflow, I think it would be better to leave it to 
implementations on how to deal with it. A guidance similar to below (from 
draft-ietf-lsr-flex-algo) would h

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Ketan Talaulikar (ketant)]

Hi Shraddha,

Please check inline below with KT2

From: Lsr  On Behalf Of Shraddha Hegde
Sent: 27 May 2021 18:31
To: Tony Li ; Ketan Talaulikar (ketant) 
Cc: lsr@ietf.org; draft-hegde-lsr-flex-algo-bw-...@ietf.org; Acee Lindem (acee) 

Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02


Snipped..


5.
For the Max B/w Link attribute and its comparison with the FAD b/w constraints, 
I see the reference to ASLA. While in OSPF max-bandwidth is not allowed in ASLA 
- 
https://datatracker.ietf.org/doc/html/rfc8920#section-7,
 in case of ISIS also, it is not really appropriate for use within ASLA 
-https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1?


I'm sorry, I don't understand this comment.
[KT] In 
https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02#section-3.2.1


The Maximum Link Bandwidth as advertised by the sub-sub-

   TLV 23 of ASLA [RFC 
8920]
 MUST be compared against the Minimum

   bandwidth advertised in FAEMB sub-TLV.

And in the 
https://datatracker.ietf.org/doc/html/rfc8920#section-7


Maximum link bandwidth is an application-independent attribute of the

   link that is defined in 
[RFC3630].
  Because it is an application-

   independent attribute, it MUST NOT be advertised in the ASLA sub-TLV.

Somewhat similar for ISIS as well.


I'm sorry, I'm still not understanding your comment. Are you objecting because 
we are expecting TLV 23 in ASLA?  I believe that FlexAlgo has already requested 
this, updating the other two protocols.


 As per RFC 8920, Maximum Link Bandwidth cannot be advertised in 
ASLA. Will update the text to reflect Maximum Link Bandwidth sub-TLV in 
Extended Link TLV of Extended Link opaque LSA.
[KT2] Thanks.

For ISIS, Maximum Link Bandwidth sub-TLV is allowed in ASLA just that different 
values for different applications is not allowed. Maximum Link bandwidth is 
also allowed with all bits set to zero in SABM/UDABM  or each individual 
application bit set for all applications making use of ASLA.
[KT2] Yes, you are correct. The RFC8919 does not mandate or require Max Link 
Bandwidth to be signaled within ASLA (at least that was my reading). If so, 
perhaps it is better to not require that in this document - just keep in the 
base. Would that not work? And if it were advertised in the ASLA (as RFC8919 
allows it), then perhaps a reference to the RFC8919 will be important on how it 
is to be done - basically exactly what you described above.

Thanks,
Ketan

RFC 8919 sec 4.2.1
"  Maximum link bandwidth is an application-independent attribute of the
   link.  When advertised using the Application-Specific Link Attributes
   sub-TLV, multiple values for the same link MUST NOT be advertised.
   This can be accomplished most efficiently by having a single
   advertisement for a given link where the Application Identifier Bit
   Mask identifies all the applications that are making use of the value
   for that link."


  1.  Document should cover the FAPM aspects for the Generic Metric and 
especially the Bandwidth metric.
 As long as we have fixed length generic metric, there won't be any 
changes to FAPM. We'll add a section to clarify about FAPM



Juniper Business Use Only
From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: Wednesday, May 26, 2021 10:10 PM
To: Ketan Jivan Talaulikar mailto:ket...@cisco.com>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]


Hi Ketan,


  1.  Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF 
allows 4 byte size and so why not the same for ISIS? Else

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Ketan Talaulikar (ketant)]

Perhaps, I should have been more careful with the word "variable". Initially, I 
meant allowing either 24 or 32 bits size (to me making it 32 just covers both 
the bases). But then the discussions on delay brought to my mind that perhaps 
even 64-bit metric might be useful. So the variable in my mind was either 32 or 
64.

And I agree that there is no impact on FAPM if we picked the Generic Metric of 
32-bit (or even kept it 24-bit). And yes, thanks Shraddha for agreeing to cover 
the applicability and aspects of FAPM in this document. Similar also applies 
for the OSPF FAAM, btw.

Thanks,
Ketan

-Original Message-
From: Peter Psenak  
Sent: 27 May 2021 18:20
To: Shraddha Hegde ; Tony Li ; Ketan 
Talaulikar (ketant) 
Cc: lsr@ietf.org; draft-hegde-lsr-flex-algo-bw-...@ietf.org; Acee Lindem (acee) 

Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

On 27/05/2021 14:36, Shraddha Hegde wrote:
>> we only need the new TLV to carry FAPM if we make the Generic Metric's size 
>> variable. If we keep it fixed size, we >should be fine with the existing 
>> FAPM.
> 
> Yes agree.
> The idea of making generic metric variable length is worth considering.
> I don't see a strong enough usecase right now to make it variable 
> length but will wait

nor do I.

thanks,
Peter



> for inputs from WG.
> 
> Rgds
> Shraddha
> 
> 
> Juniper Business Use Only
> 
> -Original Message-
> From: Peter Psenak 
> Sent: Wednesday, May 26, 2021 10:27 PM
> To: Tony Li ; Ketan Jivan Talaulikar 
> 
> Cc: lsr@ietf.org; draft-hegde-lsr-flex-algo-bw-...@ietf.org; Acee 
> Lindem (acee) 
> Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: 
> Bandwidth, Delay, Metrics and Constraints" - 
> draft-hegde-lsr-flex-algo-bw-con-02
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Tony, Ketan,
> 
> On 26/05/2021 18:40, Tony Li wrote:
> 
>>> */[KT] Generic Metric is used for the links. When we get to the 
>>> computation of inter-area or external routes, we will need to get 
>>> into FAPM. The draft at a minimum should discuss the applicability 
>>> of the Generic Metric and its use as FAPM. Now, if we do make the 
>>> Generic Metric size variable (as suggested above), then we will 
>>> likely need a new TLV for a variable size FAPM equivalent?/*
>>
>>
>> We would need a new TLV regardless of the metric size as the FAPM TLV 
>> only carries the default metric. We are not proposing that TLV at 
>> this time. That’s future work.
> 
> we only need the new TLV to carry FAPM if we make the Generic Metric's size 
> variable. If we keep it fixed size, we should be fine with the existing FAPM.
> 
> 
> thanks,
> Peter
>>
>> Tony
>>
> 
> 

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

Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[Ketan Talaulikar (ketant)]

Hello All,

I am not aware of any IPR associated with this document.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: 27 May 2021 02:27
To: lsr@ietf.org
Cc: cho...@chopps.org
Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"


Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-sid/

Please indicate your support or objections by June 9th, 2021

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Acee and Chris.

___
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] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[bruno.decraene]

Acee, Chris,

I’m not aware of non-disclosed IPR.

Thanks,
--Bruno

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Wednesday, May 12, 2021 11:09 PM
To: lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Esteemed Members of the LSR WG,

This begins a 2 week WG adoption call for the following draft:

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

Please indicate your support or objection by May 27th, 2021.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris and Acee



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

[Lsr] IPR Declarations for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Acee Lindem (acee)]

I have received IPR declarations from Shraddha, Peter, and Tony. I still need 
them from Bruno, William, and Rajesh.

Thanks,
Acee

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Wednesday, May 12, 2021 at 6:15 PM
To: "lsr@ietf.org" 
Cc: "draft-hegde-lsr-flex-algo-bw-...@ietf.org" 

Subject: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Esteemed Members of the LSR WG,

This begins a 2 week WG adoption call for the following draft:

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

Please indicate your support or objection by May 27th, 2021.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris and Acee


___
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] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Acee Lindem (acee)]

Authors,

There is a lot of interest in the document and sufficient support for WG 
adoption. Please republish as draft-ietf-lsr-flex-algo-bw-con-00.txt.

Of course, the current discussion of some of the finer points can continue.

Thanks,
Chris and Acee


From: Acee Lindem 
Date: Wednesday, May 12, 2021 at 5:09 PM
To: "lsr@ietf.org" 
Cc: "draft-hegde-lsr-flex-algo-bw-...@ietf.org" 

Subject: LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Esteemed Members of the LSR WG,

This begins a 2 week WG adoption call for the following draft:

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

Please indicate your support or objection by May 27th, 2021.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris and Acee


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

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Shraddha Hegde]

Snipped..


  1.  Since the draft is covering FlexAlgo, I would have expected that Generic 
Metric is carried only in the ASLA and this document specifies usage only for 
the FA application. Later this can be also used/extended for other applications 
but still within ASLA. Keeping an option of advertising both outside and within 
the ASLA is problematic - we will need precedence rules and such. I prefer we 
avoid this complication.


We preferred avoiding ASLA.
[KT] The text today does not avoid ASLA and in fact requires the use of ASLA 
(quite correctly) for FlexAlgo application. Peter has confirmed the same. I am 
simply asking to avoid the complications of using Generic Metric in both ASLA 
and outside it. Whatever new "application" we invent to use this generic metric 
type, can use ASLA so that the Generic Metric can be very cleanly shared 
between applications. The encoding allows for using the same value - sharing 
single advertisement across applications or doing a different one 
per-application.
 Generic metric is allowed in ASLA, it is also allowed in all 
traditional TLVs/LSAs where link attributes are advertised.
This is required so that all the applications, existing and new can make use of 
generic metric.



Juniper Business Use Only
From: Ketan Talaulikar (ketant) 
Sent: Wednesday, May 26, 2021 12:09 PM
To: Tony Li 
Cc: Acee Lindem (acee) ; lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Hi Tony,

Please check inline below.

From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: 25 May 2021 00:15
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02


Hi Ketan,

In general, I support the adoption of this document. There is, however, one 
specific point which is not clear to me (8) below that I would appreciate some 
clarity on before adoption.


As the chairs have noted, adoption is binary and not contingent upon rough 
consensus on the content, just on rough consensus on the interest.
[KT] I believe the WG has (or must have) the ability to determine portions of 
the proposal to adopt and/or to split documents. I have seen this in recent 
past in other WGs. In any case, it is not a point that I wish to argue or 
debate on - especially in the context of this document. My point (8) was 
clarified and hence I fall in the binary YES in this instance.


  1.  Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF 
allows 4 byte size and so why not the same for ISIS? Elsewhere in the document, 
I do see MAX METRIC being referred to as 4,261,412,864.


Because I'm a lazy sod.

It's far easier to detect metric overflow on three byte values than four byte 
values. True, four byte is not impossible, but it's just quick and easy with 
three byte values.  Adding a fourth byte would add range to the metric space, 
but in practice, this seemed like it was not really relevant. Most areas are 
not a very high diameter and the need for detailed metric distinctions has not 
been that high.  Thus, we went with a 3 byte metric in RFC 5305 (sec 3.7) and 
that seems to work.
[KT] The Generic Metric is by definition something that will get extended in 
the future and we don't know what use-cases might arise. It doesn't seem right 
to follow in the steps of an administratively assigned metric type like the TE 
metric. Therefore, I suggest to make it variable.

[KT] Regarding metric overflow, I think it would be better to leave it to 
implementations on how to deal with it. A guidance similar to below (from 
draft-ietf-lsr-flex-algo) would help handle the condition in a manner that does 
not cause interop issues. Theoretically, it is something that is independent of 
the size of the metric.

   During the route computation, it is possible for the Flex-Algorithm
   specific metric to exceed the maximum value that can be stored in an
   unsigned 32-bit variable.  In such scenarios, the value MUST be
   considered to be of value 4,294,967,295 during the computation and
   advertised as such.


  1.
  2.  Would be good to cover the max-metric considerations for the Generic 
Metric. Similar to 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-15#section-15.3


Fair



  1.
  2.  Since the draft is covering FlexAlgo, I would have expected that Generic 
M

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Shraddha Hegde]

Snipped..


5.
For the Max B/w Link attribute and its comparison with the FAD b/w constraints, 
I see the reference to ASLA. While in OSPF max-bandwidth is not allowed in ASLA 
- 
https://datatracker.ietf.org/doc/html/rfc8920#section-7,
 in case of ISIS also, it is not really appropriate for use within ASLA 
-https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1?


I'm sorry, I don't understand this comment.
[KT] In 
https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02#section-3.2.1


The Maximum Link Bandwidth as advertised by the sub-sub-

   TLV 23 of ASLA [RFC 
8920]
 MUST be compared against the Minimum

   bandwidth advertised in FAEMB sub-TLV.

And in the 
https://datatracker.ietf.org/doc/html/rfc8920#section-7


Maximum link bandwidth is an application-independent attribute of the

   link that is defined in 
[RFC3630].
  Because it is an application-

   independent attribute, it MUST NOT be advertised in the ASLA sub-TLV.

Somewhat similar for ISIS as well.


I'm sorry, I'm still not understanding your comment. Are you objecting because 
we are expecting TLV 23 in ASLA?  I believe that FlexAlgo has already requested 
this, updating the other two protocols.


 As per RFC 8920, Maximum Link Bandwidth cannot be advertised in 
ASLA. Will update the text to reflect Maximum Link Bandwidth sub-TLV in 
Extended Link TLV of Extended Link opaque LSA.

For ISIS, Maximum Link Bandwidth sub-TLV is allowed in ASLA just that different 
values for different applications is not allowed. Maximum Link bandwidth is 
also allowed with all bits set to zero in SABM/UDABM  or each individual 
application bit set for all applications making use of ASLA.

RFC 8919 sec 4.2.1
"  Maximum link bandwidth is an application-independent attribute of the
   link.  When advertised using the Application-Specific Link Attributes
   sub-TLV, multiple values for the same link MUST NOT be advertised.
   This can be accomplished most efficiently by having a single
   advertisement for a given link where the Application Identifier Bit
   Mask identifies all the applications that are making use of the value
   for that link."


  1.  Document should cover the FAPM aspects for the Generic Metric and 
especially the Bandwidth metric.
 As long as we have fixed length generic metric, there won't be any 
changes to FAPM. We'll add a section to clarify about FAPM



Juniper Business Use Only
From: Tony Li  On Behalf Of Tony Li
Sent: Wednesday, May 26, 2021 10:10 PM
To: Ketan Jivan Talaulikar 
Cc: Acee Lindem (acee) ; lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]


Hi Ketan,


  1.  Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF 
allows 4 byte size and so why not the same for ISIS? Elsewhere in the document, 
I do see MAX METRIC being referred to as 4,261,412,864.


Because I'm a lazy sod.

It's far easier to detect metric overflow on three byte values than four byte 
values. True, four byte is not impossible, but it's just quick and easy with 
three byte values.  Adding a fourth byte would add range to the metric space, 
but in practice, this seemed like it was not really relevant. Most areas are 
not a very high diameter and the need for detailed metric distinctions has not 
been that high.  Thus, we went with a 3 byte metric in RFC 5305 (sec 3.7) and 
that seems to work.
[KT] The Generic Metric is by definition something that will get extended in 
the future and we don't know what use-cases might arise. It doesn't seem right 
to follow in the steps of an administratively assigned metric type like the TE 
metric. Therefore, I suggest to make it variable.


Thank you for the suggestion. I don't think anyone has suggested a variable 
length metric before.  A variable length metric is difficult to impl

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Peter Psenak]

On 27/05/2021 14:36, Shraddha Hegde wrote:

we only need the new TLV to carry FAPM if we make the Generic Metric's size 
variable. If we keep it fixed size, we >should be fine with the existing FAPM.


Yes agree.
The idea of making generic metric variable length is worth considering.
I don't see a strong enough usecase right now to make it variable length but 
will wait


nor do I.

thanks,
Peter




for inputs from WG.

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Peter Psenak 
Sent: Wednesday, May 26, 2021 10:27 PM
To: Tony Li ; Ketan Jivan Talaulikar 
Cc: lsr@ietf.org; draft-hegde-lsr-flex-algo-bw-...@ietf.org; Acee Lindem (acee) 

Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]


Hi Tony, Ketan,

On 26/05/2021 18:40, Tony Li wrote:


*/[KT] Generic Metric is used for the links. When we get to the
computation of inter-area or external routes, we will need to get
into FAPM. The draft at a minimum should discuss the applicability of
the Generic Metric and its use as FAPM. Now, if we do make the
Generic Metric size variable (as suggested above), then we will
likely need a new TLV for a variable size FAPM equivalent?/*



We would need a new TLV regardless of the metric size as the FAPM TLV
only carries the default metric. We are not proposing that TLV at this
time. That’s future work.


we only need the new TLV to carry FAPM if we make the Generic Metric's size 
variable. If we keep it fixed size, we should be fine with the existing FAPM.


thanks,
Peter


Tony






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

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Shraddha Hegde]

>we only need the new TLV to carry FAPM if we make the Generic Metric's size 
>variable. If we keep it fixed size, we >should be fine with the existing FAPM.

Yes agree. 
The idea of making generic metric variable length is worth considering.
I don't see a strong enough usecase right now to make it variable length but 
will wait
for inputs from WG.

Rgds
Shraddha 


Juniper Business Use Only

-Original Message-
From: Peter Psenak  
Sent: Wednesday, May 26, 2021 10:27 PM
To: Tony Li ; Ketan Jivan Talaulikar 
Cc: lsr@ietf.org; draft-hegde-lsr-flex-algo-bw-...@ietf.org; Acee Lindem (acee) 

Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]


Hi Tony, Ketan,

On 26/05/2021 18:40, Tony Li wrote:

>> */[KT] Generic Metric is used for the links. When we get to the 
>> computation of inter-area or external routes, we will need to get 
>> into FAPM. The draft at a minimum should discuss the applicability of 
>> the Generic Metric and its use as FAPM. Now, if we do make the 
>> Generic Metric size variable (as suggested above), then we will 
>> likely need a new TLV for a variable size FAPM equivalent?/*
>
>
> We would need a new TLV regardless of the metric size as the FAPM TLV 
> only carries the default metric. We are not proposing that TLV at this 
> time. That’s future work.

we only need the new TLV to carry FAPM if we make the Generic Metric's size 
variable. If we keep it fixed size, we should be fine with the existing FAPM.


thanks,
Peter
>
> Tony
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[Peter Psenak]

Hi Acee and Chris,

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

thanks,
Peter

On 26/05/2021 22:56, Christian Hopps wrote:


Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-sid/

Please indicate your support or objections by June 9th, 2021

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Acee and Chris.

___
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