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

[Aijun Wang]

Hi, 

I support the adoption of the “FAD constraint sub-TLV” part(Section 3),  but 
not support the introduce of  “Bandwidth Metric Advertisement” part (Section 4) 
and other related parts.

With the introduce of additional constraint information, the problem described 
in “Introduction” part(Section 1) can be solved.

 

The usage of bandwidth metric in large network is not feasible. 

And, would you like to explain more for the following statements(in Section 
4.1.1.2)

“In the interface group mode, every node MUST identify the set of

   parallel links between a pair of nodes based on IGP link

   advertisements and MUST consider cumulative bandwidth of the parallel

   links while arriving at the metric of each link.”

based on example described in Figure 7? 

 

How the cumulative bandwidth will be used to achieve the result that traffic 
from B to D will prefer B-C-F-D, not B-E-D? 

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org  On Behalf Of Acee Lindem 
(acee)
Sent: Thursday, May 13, 2021 5:09 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

 

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

[Dongjie (Jimmy)]

Hi Shraddha,

Thanks for your further explanation.

I agree if operators design it properly, it could provide the desired result of 
excluding links whose maximum bandwidth is lower than the specified constraint.

As you said it is not related to the bandwidth management or reservation, thus 
it is more like a mechanism of relative static network planning, without 
considering the dynamics of the link bandwidth utilization.

I don't have further questions.

Best regards,
Jie

From: Shraddha Hegde [mailto:shrad...@juniper.net]
Sent: Wednesday, May 19, 2021 6:42 PM
To: Dongjie (Jimmy) ; Acee Lindem (acee) 
; lsr@ietf.org
Cc: 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


>[Jie] I can understand how this works for a single Flex-Algo, while my 
>question was if more than one Flex-Algo use
>bandwidth as constraint to exclude some links, what would be the consequence 
>to the network?

Operators design and plan whether one flex-algo is suitable for their network 
or multiple. The planning also involves
the definition of each flex-algo that is suitable for their network. This 
network planning exercise has to be done
irrespective of whether bandwidth constraints are used in the flex-algo to 
ensure traffic distribution is even.

Rgds
Shraddha





Juniper Business Use Only
From: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Sent: Wednesday, May 19, 2021 12:59 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; Acee 
Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org
Cc: 
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 Shraddha,

Thanks for your reply. Please see further inline:

From: Shraddha Hegde [mailto:shrad...@juniper.net]
Sent: Tuesday, May 18, 2021 1:18 PM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; Acee 
Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org
Cc: 
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 Jimmy,

Thanks for the review and comments.Pls see inline



Juniper Business Use Only
From: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Sent: Tuesday, May 18, 2021 7:58 AM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; Acee 
Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org
Cc: 
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]

Thanks to Peter for his response to my third comment.

Could the authors also reply to the other comments (1, 2, 4) in the below mail? 
Many thanks.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Dongjie (Jimmy)
Sent: Friday, May 14, 2021 3:52 PM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org
Cc: 
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 authors,

I've read the latest version of this document and have the following comments:


1.   Is the generic metric type applicable to applications other than 
Flex-Algo? If so, it is better to make this clear in the document, or perhaps 
it may be defined separately from the Flex-Algo specific extensions?
Yes. Any application can make use of generic metric including 
Flex-algo and SR-TE.
  Sure. I'll add some text to clarify this.

[Jie] OK, thanks.



2.   The "Exclude Minimum Bandwidth" constraint is compared with the 
maximum link bandwidth to exclude the links from the computation, it would be 
helpful if there is some analysis about how much this can help in traffic 
engineering, such as to reduce the congestion or improve the link utilization. 
One simple example is, if multiple Flex-Algos use this constraint to exclude 
the same set of links, this may increase the possibility of congestion on the 
rest of the links?
 The motivation for "Exclude Minimum Bandwidth" is to avoid low 
capacity links for the high bandwidth traffic. For example if the Flex-algo 128 
carries high bw traffic flows of bw greater than 10g, it makes sense to remove 
1g links from this flex-algo topology since these links if 

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

[peng.shaofu]

Dear Acee, Tony,






Thanks!

Tony's explanation gives the essential use of bandwidth-metric. My previous 
understanding is mainly based on the problem to be solved in another draft 
https://datatracker.ietf.org/doc/draft-lp-lsr-fa-bandwidth/. Sorry to insert an 
advertisement in this adoption.  : ) 

In draft-lp, the path will be selected strictly according to the actual 
bandwidth capacity of the link. The main issue is that the computation method  
is not optimal, just a basic expression of this idea. 

Just for the expected requirement "to select a path with the maximum link 
bandwidth from the source node to the destination node", it seems that one 
scheme try to satisfy most of scenarios, and the other try to satisfy 100%.




Regards


PSF











原始邮件



发件人：AceeLindem(acee)
收件人：Tony Li;彭少富10053815;
抄送人：shrad...@juniper.net;lsr@ietf.org;draft-hegde-lsr-flex-algo-bw-...@ietf.org;
日 期 ：2021年05月20日 18:22
主 题 ：Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02




Speaking as WG member:


 


I agree with Tony.


 


Furthermore, the extensions in the draft provide mechanisms to constraint 
bandwidth beyond your concern that bandwidth be used as a cumulative metric. I 
support WG adoption.


 


Thanks,
 Acee


 



From: Tony Li  on behalf of Tony Li 
 Date: Thursday, May 20, 2021 at 12:20 AM
 To: "peng.sha...@zte.com.cn" 
 Cc: "shrad...@juniper.net" , Acee Lindem 
, "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 Peng Shaofu,


 



 
 


On May 19, 2021, at 6:55 PM, peng.sha...@zte.com.cn wrote:



 


Let's go back to the bandwidth-metric related to bandwidth capability. My worry 
is that bandwidth-metric (whether it is automatically calculated or manually 
configured) is not cumulative in nature, which is different from IGP default 
metric/TE metric/delay metric, so that SPF based on bandwidth-metric may get an 
unexpected path (see the example of the original mail). Can more text be added 
in the draft to describe why this can work ?




 



 


The whole point of the bandwidth metric (and indeed, of all of FlexAlgo) is to 
get a different path computation result than what we might get with the 
standard IGP metric. What it will do in any given topology is highly dependent 
on the topology, as you’ve seen.  It may or may not ‘work’ by whatever 
definition you have in mind. However, what matters is what the network operator 
is trying to achieve. It doesn’t have to work for every topology or every 
purpose.



 


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

[peng.shaofu]

Hi Shraddha,






Thanks for your reply. I have no questions any more.






Regards,


PSF











原始邮件



发件人：ShraddhaHegde
收件人：彭少富10053815;
抄送人：acee=40cisco@dmarc.ietf.org;lsr@ietf.org;draft-hegde-lsr-flex-algo-bw-...@ietf.org;
日 期 ：2021年05月20日 12:17
主 题 ：RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02




Hi Pengshaofu,


 


Pls see inline..


 


 


Juniper Business Use Only



From: peng.sha...@zte.com.cn  
 Sent: Thursday, May 20, 2021 7:26 AM
 To: Shraddha Hegde 
 Cc: 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 Shraddha,

 

Thanks. Actually, I don't really want to define other metric types.

Let's go back to the bandwidth-metric related to bandwidth capability. My worry 
is that bandwidth-metric (whether it is automatically calculated or manually 
configured) is not cumulative in nature,

 Yes that is correct.

which is different from IGP default metric/TE metric/delay metric,

 

so that SPF based on bandwidth-metric may get an unexpected path (see the 
example of the original mail).

Can more text be added in the draft to describe why this can work ?

 Knowing that metric derived inversely from the link bandwidth is not 
additive in nature, should set the expectation right. I can add some text in 
this regard.

 

Regards,

PSF

 

 


原始邮件



发件人：ShraddhaHegde



收件人：彭少富10053815;



抄送人：acee=40cisco@dmarc.ietf.org;lsr@ietf.org;draft-hegde-lsr-flex-algo-bw-...@ietf.org;



日 期 ：2021年05月18日 13:01



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




Hi Pengshaofu,


 


If an operator wants to configure any other metric type draft provides a 
mechanism with generic metric.


Generic metric allows any standard or user-defined type metric to be configured.


The draft allows for any computing application such as Flex-algo, CSPF etc to 
make use of the


Metric. The intention of the draft is that for a particular computation same 
metric-type is used


throughout the network. If that is not clear, I’ll add some text in the draft.


 


Using a combination of different metrics for a single computation would need 
significant change to SPF algorithm and it is not in the scope of the draft 
"Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints".


 


Hope that clarifies.


 


Rgds


Shraddha


 


 


Juniper Business Use Only



From: peng.sha...@zte.com.cn  
 Sent: Monday, May 17, 2021 12:49 PM
 To: Shraddha Hegde 
 Cc: 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 Shraddha,

 

The two methods of automatic generation of BW-metric introduced in the draft 
are also likely to be the method of manual configuration of BW-metric by 
operators. Operators can certainly manually configure any  BW-metric he wants 
to configure.

However, the manually configured BW-metric cannot deviate from the actual 
bandwidth capacity of the link, otherwise it could be any other names such as 
BX-metric.

For manual assignment, the problem may still exist We can find an example that  
the accumulated bandwidth-metric on the path may offset the manually increased 
bandwidth-metric of links on the path.

Combination of bandwidth attribute of link and other metric that is cumulative 
may be another co-exist way to completely address this issue.

 

Regards,

PSF

 

 

 

 


原始邮件



发件人：ShraddhaHegde



收件人：彭少富10053815;



抄送人：acee=40cisco@dmarc.ietf.org;lsr@ietf.org;draft-hegde-lsr-flex-algo-bw-...@ietf.org;



日 期 ：2021年05月17日 12:15



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




Hi Pengshaofu,


 


I was suggesting to manually assign bandwidth metric which will override the 
automatic metric calculation


as described in the draft section 5. Physically adding more fiber/capacity is 
not a feasible solution.


 


Rgds


Shraddha


 


 


Juniper Business Use Only



From: peng.sha...@zte.com.cn  
 Sent: Monday, May 17, 2021 7:40 AM
 To: Shraddha Hegde 
 Cc: 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 Shraddha,

 

Thanks for your rely.

So it seems 

[Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-06.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : Area Proxy for IS-IS
Authors : Tony Li
  Sarah Chen
  Vivek Ilangovan
  Gyan S. Mishra
Filename: draft-ietf-lsr-isis-area-proxy-06.txt
Pages   : 20
Date: 2021-05-20

Abstract:
   Link state routing protocols have hierarchical abstraction already
   built into them.  However, when lower levels are used for transit,
   they must expose their internal topologies to each other, leading to
   scale issues.

   To avoid this, this document discusses extensions to the IS-IS
   routing protocol that would allow level 1 areas to provide transit,
   yet only inject an abstraction of the level 1 topology into level 2.
   Each level 1 area is represented as a single level 2 node, thereby
   enabling greater scale.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-06
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


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

Re: [Lsr] Erik Kline's Discuss on draft-ietf-lsr-isis-srv6-extensions-14: (with DISCUSS)

[Joel Halpern Direct]

None of the cases you described are used for routing.

And advertising information for which we do not know the use seems a bad 
idea.


The abstraction that lets us talk about func bits and arg bits is nice. 
 But in fact, the operational structures do not depend upon that.

I really think removing section 9 would improve the document and operations.

Yours,
Joel

On 5/20/2021 10:10 AM, Peter Psenak wrote:

Joel,

On 20/05/2021 15:59, Joel M. Halpern wrote:

I have been watching this debate, and I am left with the impression that
the information being defined in section 9 of this draft is simply not
useful for routing.   It confuses operational information with routing
information.  Given taht the information has to come from somewhere
outside the router anyway, 


the information comes from the router, that is where the SRv6 SID is 
allocated.


Similar to a prefix that is configured on the router and is advertised 
together with some additional attributes (e.g. tag). These attributes 
may or may not be used for routing.


thanks,
Peter




iand that it is not going to be consumed by
the routers who receive the advertisements, why is it here?

Yours,
Joel

On 5/20/2021 7:49 AM, Peter Psenak wrote:

Hi Erik,

thanks for your comment, please see inline:

On 19/05/2021 03:58, Erik Kline via Datatracker wrote:

Erik Kline has entered the following ballot position for
draft-ietf-lsr-isis-srv6-extensions-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/iesg/statement/discuss-criteria.html

for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/



--
DISCUSS:
--

[ section 9 ]

* I share the concerns of several of the others here about SRv6 SIDs
being
    claimed to be IPv6 addresses but kinda not really being IPv6 
addresses
    if their internal structure is exposed outside of the given SR 
router.



SRv6 SIDs are indeed IPv6 addresses. RFC8986 introduced the SRv6 SID
structure. It also goes into allocation of SIDs where it describes the
carving out of the Block for SRv6 SIDs in the domain, followed by the
allocation of SRv6 Locators to the nodes in the domain. Then the node
allocates the function part when instantiating the SID - and all of this
is signaled via control plane protocols. This is all exposed and know to
the operator who determines the addressing scheme.




    If "[i]t's usage is outside of the scope of this document", can
this be
    removed for now, and maybe take up the issue at some point in the
future
    by which time a motivating use case might have presented itself?



The use-cases have not been described in this document since they were
out of the scope of the ISIS protocol operations. Some of the use-cases
discussed have been :

- automation and verification of blocks/locators and setup of filtering
for them at SR domain boundaries

- validation of SRv6 SIDs being instantiated and advertised via IGP;
these can be learnt by apps/controllers via BGP-LS and then monitored
for conformance to the addressing rules set by the operator.

- verification and even determination of summary routes to be used for
covering the SRv6 Locators and SIDs.

There may be other use-cases that may be operator or vendor specific.
The use-cases are not within the scope of ISIS protocol extensions and
are either operational or implementation specific – hence we said it was
out of the scope of this document.

If you feel adding these to the document may help to clear your
concerns, I can certainly add them.

thanks,
Peter














___
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] Erik Kline's Discuss on draft-ietf-lsr-isis-srv6-extensions-14: (with DISCUSS)

[Peter Psenak]

Joel,


Joel,

On 20/05/2021 15:59, Joel M. Halpern wrote:

I have been watching this debate, and I am left with the impression that
the information being defined in section 9 of this draft is simply not
useful for routing.   It confuses operational information with routing
information.  Given taht the information has to come from somewhere
outside the router anyway,


the information comes from the router, that is where the SRv6 SID is
allocated.

Similar to a prefix that is configured on the router and is advertised
together with some additional attributes (e.g. tag). These attributes
may or may not be used for routing.


here's the quote from the rfc5130 that defined the ISIS admin tag TLVs:

   "The methods for which their use is employed is beyond the scope of
this document and left to the implementer and/or operator."

I just want to point out that there are already examples where IGPs 
carry attribute (e.g. for a prefix), which usage is not specified in the 
ISIS specification and is left for the implementer and/or operator - 
means it's not necessarily used for routing. SID Structure would not be 
the first one.


thanks,
Peter







thanks,
Peter




iand that it is not going to be consumed by
the routers who receive the advertisements, why is it here?

Yours,
Joel

On 5/20/2021 7:49 AM, Peter Psenak wrote:

Hi Erik,

thanks for your comment, please see inline:

On 19/05/2021 03:58, Erik Kline via Datatracker wrote:

Erik Kline has entered the following ballot position for
draft-ietf-lsr-isis-srv6-extensions-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/



--
DISCUSS:
--

[ section 9 ]

* I share the concerns of several of the others here about SRv6 SIDs
being
     claimed to be IPv6 addresses but kinda not really being IPv6 addresses
     if their internal structure is exposed outside of the given SR router.



SRv6 SIDs are indeed IPv6 addresses. RFC8986 introduced the SRv6 SID
structure. It also goes into allocation of SIDs where it describes the
carving out of the Block for SRv6 SIDs in the domain, followed by the
allocation of SRv6 Locators to the nodes in the domain. Then the node
allocates the function part when instantiating the SID - and all of this
is signaled via control plane protocols. This is all exposed and know to
the operator who determines the addressing scheme.




     If "[i]t's usage is outside of the scope of this document", can
this be
     removed for now, and maybe take up the issue at some point in the
future
     by which time a motivating use case might have presented itself?



The use-cases have not been described in this document since they were
out of the scope of the ISIS protocol operations. Some of the use-cases
discussed have been :

- automation and verification of blocks/locators and setup of filtering
for them at SR domain boundaries

- validation of SRv6 SIDs being instantiated and advertised via IGP;
these can be learnt by apps/controllers via BGP-LS and then monitored
for conformance to the addressing rules set by the operator.

- verification and even determination of summary routes to be used for
covering the SRv6 Locators and SIDs.

There may be other use-cases that may be operator or vendor specific.
The use-cases are not within the scope of ISIS protocol extensions and
are either operational or implementation specific – hence we said it was
out of the scope of this document.

If you feel adding these to the document may help to clear your
concerns, I can certainly add them.

thanks,
Peter














___
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] Erik Kline's Discuss on draft-ietf-lsr-isis-srv6-extensions-14: (with DISCUSS)

[Peter Psenak]

Joel,

On 20/05/2021 15:59, Joel M. Halpern wrote:

I have been watching this debate, and I am left with the impression that
the information being defined in section 9 of this draft is simply not
useful for routing.   It confuses operational information with routing
information.  Given taht the information has to come from somewhere
outside the router anyway, 


the information comes from the router, that is where the SRv6 SID is 
allocated.


Similar to a prefix that is configured on the router and is advertised 
together with some additional attributes (e.g. tag). These attributes 
may or may not be used for routing.


thanks,
Peter




iand that it is not going to be consumed by
the routers who receive the advertisements, why is it here?

Yours,
Joel

On 5/20/2021 7:49 AM, Peter Psenak wrote:

Hi Erik,

thanks for your comment, please see inline:

On 19/05/2021 03:58, Erik Kline via Datatracker wrote:

Erik Kline has entered the following ballot position for
draft-ietf-lsr-isis-srv6-extensions-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/



--
DISCUSS:
--

[ section 9 ]

* I share the concerns of several of the others here about SRv6 SIDs
being
    claimed to be IPv6 addresses but kinda not really being IPv6 addresses
    if their internal structure is exposed outside of the given SR router.



SRv6 SIDs are indeed IPv6 addresses. RFC8986 introduced the SRv6 SID
structure. It also goes into allocation of SIDs where it describes the
carving out of the Block for SRv6 SIDs in the domain, followed by the
allocation of SRv6 Locators to the nodes in the domain. Then the node
allocates the function part when instantiating the SID - and all of this
is signaled via control plane protocols. This is all exposed and know to
the operator who determines the addressing scheme.




    If "[i]t's usage is outside of the scope of this document", can
this be
    removed for now, and maybe take up the issue at some point in the
future
    by which time a motivating use case might have presented itself?



The use-cases have not been described in this document since they were
out of the scope of the ISIS protocol operations. Some of the use-cases
discussed have been :

- automation and verification of blocks/locators and setup of filtering
for them at SR domain boundaries

- validation of SRv6 SIDs being instantiated and advertised via IGP;
these can be learnt by apps/controllers via BGP-LS and then monitored
for conformance to the addressing rules set by the operator.

- verification and even determination of summary routes to be used for
covering the SRv6 Locators and SIDs.

There may be other use-cases that may be operator or vendor specific.
The use-cases are not within the scope of ISIS protocol extensions and
are either operational or implementation specific – hence we said it was
out of the scope of this document.

If you feel adding these to the document may help to clear your
concerns, I can certainly add them.

thanks,
Peter














___
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] WGLC for draft-ietf-lsvr-bgp-spf-13 (to end June 3, 2021)

[Van De Velde, Gunter (Nokia - BE/Antwerp)]

Hi All,





The author team together with AD have been working hard on this document and 
made significant enhancements to this document.





The LSVR WG starts a working group last call for "draft-ietf-lsvr-bgp-spf-13". 
Please send your comments to the LSVR list before Thursday June 3, 2021.



https://datatracker.ietf.org/doc/draft-ietf-lsvr-bgp-spf/





This WGLC is cross-posted to IDR and LSR WG. All feedback and discussions 
should happen on the LSVR WG mailer.





Authors, please reply indicating if you're aware of any relevant IPR.



All, Please advice if you are aware of an implementation or are aware of 
relevant IPR.





Brgds,

Gunter & Victor

LSVR WG co-chairs

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

Re: [Lsr] Erik Kline's Discuss on draft-ietf-lsr-isis-srv6-extensions-14: (with DISCUSS)

[Joel M. Halpern]

I have been watching this debate, and I am left with the impression that 
the information being defined in section 9 of this draft is simply not 
useful for routing.   It confuses operational information with routing 
information.  Given taht the information has to come from somewhere 
outside the router anyway, iand that it is not going to be consumed by 
the routers who receive the advertisements, why is it here?


Yours,
Joel

On 5/20/2021 7:49 AM, Peter Psenak wrote:

Hi Erik,

thanks for your comment, please see inline:

On 19/05/2021 03:58, Erik Kline via Datatracker wrote:

Erik Kline has entered the following ballot position for
draft-ietf-lsr-isis-srv6-extensions-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/



--
DISCUSS:
--

[ section 9 ]

* I share the concerns of several of the others here about SRv6 SIDs 
being

   claimed to be IPv6 addresses but kinda not really being IPv6 addresses
   if their internal structure is exposed outside of the given SR router.



SRv6 SIDs are indeed IPv6 addresses. RFC8986 introduced the SRv6 SID 
structure. It also goes into allocation of SIDs where it describes the 
carving out of the Block for SRv6 SIDs in the domain, followed by the 
allocation of SRv6 Locators to the nodes in the domain. Then the node 
allocates the function part when instantiating the SID - and all of this 
is signaled via control plane protocols. This is all exposed and know to 
the operator who determines the addressing scheme.





   If "[i]t's usage is outside of the scope of this document", can 
this be
   removed for now, and maybe take up the issue at some point in the 
future

   by which time a motivating use case might have presented itself?



The use-cases have not been described in this document since they were 
out of the scope of the ISIS protocol operations. Some of the use-cases 
discussed have been :


- automation and verification of blocks/locators and setup of filtering 
for them at SR domain boundaries


- validation of SRv6 SIDs being instantiated and advertised via IGP; 
these can be learnt by apps/controllers via BGP-LS and then monitored 
for conformance to the addressing rules set by the operator.


- verification and even determination of summary routes to be used for 
covering the SRv6 Locators and SIDs.


There may be other use-cases that may be operator or vendor specific. 
The use-cases are not within the scope of ISIS protocol extensions and 
are either operational or implementation specific – hence we said it was 
out of the scope of this document.


If you feel adding these to the document may help to clear your 
concerns, I can certainly add them.


thanks,
Peter














___
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] Roman Danyliw's Abstain on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

[Roman Danyliw via Datatracker]

Roman Danyliw has entered the following ballot position for
draft-ietf-lsr-isis-srv6-extensions-14: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/



--
COMMENT:
--

(updated position)

I'm balloting ABSTAIN for the reasons already eloquently stated by Ben; and
with follow-up from Warren and Murray.

I support Eric Kline's Discuss position.



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

Re: [Lsr] Murray Kucherawy's Abstain on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

[Peter Psenak]

Hi Murray,

thanks for your comments, please see inline (##PP):

On 20/05/2021 10:38, Murray Kucherawy via Datatracker wrote:

Murray Kucherawy has entered the following ballot position for
draft-ietf-lsr-isis-srv6-extensions-14: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/



--
COMMENT:
--

I'm balloting ABSTAIN for the reasons cited by Warren (and, hence, Ben).

Some other unrelated comments:

I suggest asking IANA to review your IANA Considerations section sooner rather
than later to be sure they know what you're after.  I found this section
somewhat hard to follow.


##PP
this has been done already.




I concur with John, who suggested that this document doesn't actually update
RFC 7370.  I'm aware of the conversation that happened afterwards; just going
on the record here.


##PP
sure, as I said earlier, I'm fine both ways, so I let others to find an 
agreement.




Section 9:

* "It's usage is outside of the scope of this document." -- s/It's/Its/


##PP
yes, this has been fixed already.


thanks,
Peter










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

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-lsr-isis-srv6-extensions-14: (with DISCUSS and COMMENT)

[Peter Psenak]

Hi Benjamin,

thanks for your comments, please see inline (#PP):

On 18/05/2021 22:29, Benjamin Kaduk via Datatracker wrote:

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lsr-isis-srv6-extensions-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/



--
DISCUSS:
--

The prose and tabular IANA considerations in §11.3 are inconsistent
about whether the End.X/LAN End.X SID sub-TLVs are allowed to appear in
TLV 25.  (I may have noted all instances in the prose, in my COMMENT,
but it's worth checking for others.)


##PP
good catch, I added it to all places.




--
COMMENT:
--

ABSTAIN

Once my discuss point is resolved, I intend to change my position to
Abstain.  The relationship of SRv6 SIDs to the IPv6 addressing
architecture (RFC 4291) was quite controversial during the processing of
what since became RFC 8986.  I was able to reconcile the two at the time
by virtue of noting that the substructure of the SID can be considered
to be logically local to the node advertising the SID and therefore not
an observable part of the protocol.  In that sense, the wire-visible use
and processing of SIDs remains that of normal IPv6 addresses.  However,
introducing a sub-sub-TLV to specifically carry the structure of the SID
causes that reasoning to no longer apply, and seemingly re-opens the
question of whether the SID substructure is consistent with the IPv6
addressing architecture.  In the absence of some compelling use case, I
cannot support publishing a mechanism that triggers this controversy.
Indeed, no motivating use case is presented in the document at all (the
usage is "outside of the scope of this document"), which invites
questions about why this mechanism should be defined in a
standards-track RFC at all (the relevant registry procedures are merely
"expert review").


##PP
RFC8986 introduced the SRv6 SID structure. This document is only 
introducing the ISIS extension for its signalling. Please see more on 
this and the use cases in my response to Erik





COMMENT

(I agree with John that this doesn't inherently seem like an update to
RFC 7030, but I have nothing further to add that he hasn't said already,
so let's keep that topic in his ballot thread.)

Thank you for noting (repeatedly) that multiple TLVs may be needed in
order to advertise all the SIDs for a given neighbor/endpoint/etc. --
the one-byte length field for TLVs is a bit cramped when we have 16-byte
SIDs!


##PP
not much I can do with the ISIS TLV length. ISIS allows to advertise 
multiple TLVs of the same type, so we can advertise as many SIDs as we 
need as soon as we have space in the LSP set.




Section 4

Link MSDs are advertised in a sub-TLV of TLVs 22, 23, 141, 222, and
223.

The list in RFC 8491 includes TLV 25 as well.  Is TLV 25 somehow not
relevant for this document?


##PP
fixed



Section 4.3

Does the SRH Max H.encaps MSD type have any bearing on the application
of H.Encaps.Red?  (I assume the L2 encapsulations from RFC 8986 are not
quite so relevant.)



##PP
H.Encaps.Red omits the addition of the first SID in the SRH. Hence 
H.Encaps.Red supports one more SID than what is advertised in the 
H.Encaps MSD.


I have modified text to:

"The Maximum H.Encaps MSD Type signals the maximum number of SIDs that
can be added to the Segment List of an SRH as part of any "H.Encaps"
behavior as defined in RFC8986.




Section 5

In case where the same prefix, with the same prefix-length, MTID, and
algorithm is received in both a Prefix Reachability TLV and an SRv6

Others already covered the duplication/mangled nature of this paragraph,
but please also expand MTID on first use.


##PP
done



Locators associated with Flexible Algorithms (see Section 4 of
[I-D.ietf-lsr-flex-algo]) SHOULD NOT be advertised in Prefix
Reachability TLVs (236 or 237).  Advertising the Flexible Algorithm
locator in regular Prefix Reachability TLV (236 or 237) would make
the forwarding for it to follow algo 0 path.

Perhaps this is more properly a matter for -flex-algo itself, but if
these locators are not to be advertised in TLVs 236/237 with the goal of
having forwarding for those prefixes not follow the algo(rithm) 0 path,
does that mean that the flexible algorithms can only be deployed in
networks where all routers support the 

Re: [Lsr] Erik Kline's Discuss on draft-ietf-lsr-isis-srv6-extensions-14: (with DISCUSS)

[Peter Psenak]

Hi Erik,

thanks for your comment, please see inline:

On 19/05/2021 03:58, Erik Kline via Datatracker wrote:

Erik Kline has entered the following ballot position for
draft-ietf-lsr-isis-srv6-extensions-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/



--
DISCUSS:
--

[ section 9 ]

* I share the concerns of several of the others here about SRv6 SIDs being
   claimed to be IPv6 addresses but kinda not really being IPv6 addresses
   if their internal structure is exposed outside of the given SR router.



SRv6 SIDs are indeed IPv6 addresses. RFC8986 introduced the SRv6 SID 
structure. It also goes into allocation of SIDs where it describes the 
carving out of the Block for SRv6 SIDs in the domain, followed by the 
allocation of SRv6 Locators to the nodes in the domain. Then the node 
allocates the function part when instantiating the SID - and all of this 
is signaled via control plane protocols. This is all exposed and know to 
the operator who determines the addressing scheme.





   If "[i]t's usage is outside of the scope of this document", can this be
   removed for now, and maybe take up the issue at some point in the future
   by which time a motivating use case might have presented itself?



The use-cases have not been described in this document since they were 
out of the scope of the ISIS protocol operations. Some of the use-cases 
discussed have been :


- automation and verification of blocks/locators and setup of filtering 
for them at SR domain boundaries


- validation of SRv6 SIDs being instantiated and advertised via IGP; 
these can be learnt by apps/controllers via BGP-LS and then monitored 
for conformance to the addressing rules set by the operator.


- verification and even determination of summary routes to be used for 
covering the SRv6 Locators and SIDs.


There may be other use-cases that may be operator or vendor specific. 
The use-cases are not within the scope of ISIS protocol extensions and 
are either operational or implementation specific – hence we said it was 
out of the scope of this document.


If you feel adding these to the document may help to clear your 
concerns, I can certainly add them.


thanks,
Peter














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

Re: [Lsr] Robert Wilton's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

[Rob Wilton (rwilton)]

Hi Acee,

> -Original Message-
> From: Acee Lindem (acee) 
> Sent: 20 May 2021 11:28
> To: Rob Wilton (rwilton) ; The IESG 
> Cc: draft-ietf-lsr-isis-srv6-extensi...@ietf.org; lsr-cha...@ietf.org;
> lsr@ietf.org; Christian Hopps ; aretana.i...@gmail.com
> Subject: Re: Robert Wilton's No Objection on draft-ietf-lsr-isis-srv6-
> extensions-14: (with COMMENT)
> 
> Hi Rob,
> 
> On 5/20/21, 5:11 AM, "Robert Wilton via Datatracker" 
> wrote:
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-lsr-isis-srv6-extensions-14: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut
> this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-
> criteria.html
> for more information about DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Hi,
> 
> Thanks for this document.
> 
> In various places, this document references lists of numerical
> algorithm
> numbers, or TLV Ids without any associated human names.  I would have
> found
> this document to be a bit more readable if the names of the algorithms
> and TLVs
> were also used alongside their numerical ids.
> 
> You mean like OSPF __?  For better or worse, IS-IS has always referred to
> TLVs by their numeric code point.
[RW] 

Ah, you can see that I haven't read many IS-IS specs.  If the convention is to 
always refer to them by their code points then that is fine, I just find the 
doc harder to read/understand.

Thanks,
Rob



> 
> Thanks,
> Acee
> 
> Thanks,
> Rob
> 
> 
> 

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

Re: [Lsr] Robert Wilton's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

[Acee Lindem (acee)]

Hi Rob, 

On 5/20/21, 5:11 AM, "Robert Wilton via Datatracker"  wrote:

Robert Wilton has entered the following ballot position for
draft-ietf-lsr-isis-srv6-extensions-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/



--
COMMENT:
--

Hi,

Thanks for this document.

In various places, this document references lists of numerical algorithm
numbers, or TLV Ids without any associated human names.  I would have found
this document to be a bit more readable if the names of the algorithms and 
TLVs
were also used alongside their numerical ids.

You mean like OSPF __?  For better or worse, IS-IS has always referred to TLVs 
by their numeric code point. 

Thanks,
Acee

Thanks,
Rob




___
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)]

Speaking as WG member:

I agree with Tony.

Furthermore, the extensions in the draft provide mechanisms to constraint 
bandwidth beyond your concern that bandwidth be used as a cumulative metric. I 
support WG adoption.

Thanks,
Acee

From: Tony Li  on behalf of Tony Li 
Date: Thursday, May 20, 2021 at 12:20 AM
To: "peng.sha...@zte.com.cn" 
Cc: "shrad...@juniper.net" , Acee Lindem 
, "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 Peng Shaofu,



On May 19, 2021, at 6:55 PM, 
peng.sha...@zte.com.cn wrote:

Let's go back to the bandwidth-metric related to bandwidth capability. My worry 
is that bandwidth-metric (whether it is automatically calculated or manually 
configured) is not cumulative in nature, which is different from IGP default 
metric/TE metric/delay metric, so that SPF based on bandwidth-metric may get an 
unexpected path (see the example of the original mail). Can more text be added 
in the draft to describe why this can work ?


The whole point of the bandwidth metric (and indeed, of all of FlexAlgo) is to 
get a different path computation result than what we might get with the 
standard IGP metric. What it will do in any given topology is highly dependent 
on the topology, as you’ve seen.  It may or may not ‘work’ by whatever 
definition you have in mind. However, what matters is what the network operator 
is trying to achieve. It doesn’t have to work for every topology or every 
purpose.

Tony

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

[Lsr] Robert Wilton's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

[Robert Wilton via Datatracker]

Robert Wilton has entered the following ballot position for
draft-ietf-lsr-isis-srv6-extensions-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/



--
COMMENT:
--

Hi,

Thanks for this document.

In various places, this document references lists of numerical algorithm
numbers, or TLV Ids without any associated human names.  I would have found
this document to be a bit more readable if the names of the algorithms and TLVs
were also used alongside their numerical ids.

Thanks,
Rob



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

[Lsr] Murray Kucherawy's Abstain on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

[Murray Kucherawy via Datatracker]

Murray Kucherawy has entered the following ballot position for
draft-ietf-lsr-isis-srv6-extensions-14: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/



--
COMMENT:
--

I'm balloting ABSTAIN for the reasons cited by Warren (and, hence, Ben).

Some other unrelated comments:

I suggest asking IANA to review your IANA Considerations section sooner rather
than later to be sure they know what you're after.  I found this section
somewhat hard to follow.

I concur with John, who suggested that this document doesn't actually update
RFC 7370.  I'm aware of the conversation that happened afterwards; just going
on the record here.

Section 9:

* "It's usage is outside of the scope of this document." -- s/It's/Its/



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