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

2021-05-19 Thread Christian Hopps
"Les Ginsberg (ginsberg)" writes: Perhaps the somewhat unfortunate choice of the name of the registry - which inserts the codepoint for all the TLVs supported by the registry into the registry name - feeds into this confusion. If so, I would suggest renaming the registry to: "Sub-TLVs for

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

2021-05-19 Thread Shraddha Hegde
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

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

2021-05-19 Thread Tony Li
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

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

2021-05-19 Thread Les Ginsberg (ginsberg)
Alvaro - I don’t find the referenced draft relevant to this case. Our difference of opinion has to do with the function of a codepoint registry. Registries are created as a place to both document existing codepoints and to be updated when the need for additional codepoints arises. There is no

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

2021-05-19 Thread Christian Hopps
My final input would be that it is important to maintain the linkages. So if an RFC creates a registry and then that registry's name is changed by another RFC then, unfortunately, I think that the second RFC updates the first. Otherwise I agree with Les. How about we pick names that don't

Re: [Lsr] opsawg-l3sm-l3nm

2021-05-19 Thread Acee Lindem (acee)
Hi Tom, I would agree with your assessment. However, I'd also put this draft in the "wisdom to know the difference" category. I won't speak for the rest of the WG but fixing it isn't a priority for me. Thanks, Acee On 5/18/21, 5:46 AM, "Lsr on behalf of tom petch" wrote: Looking at

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

2021-05-19 Thread peng.shaofu
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, which is

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

2021-05-19 Thread Dongjie (Jimmy)
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>>;

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

2021-05-19 Thread Shraddha Hegde
>[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

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

2021-05-19 Thread Peter Psenak
Hi Eric, thanks for comments, please see inline (##PP): On 18/05/2021 18:05, Éric Vyncke via Datatracker wrote: Éric Vyncke 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

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

2021-05-19 Thread Eric Vyncke (evyncke)
Hello Peter, Thank you for your quick reply and addressing my non-blocking COMMENTs. You may want to have a look at EV> below (again non blocking) Regards -éric -Original Message- From: Peter Psenak Date: Wednesday, 19 May 2021 at 13:39 To: Eric Vyncke , The IESG Cc:

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

2021-05-19 Thread Alvaro Retana
Les: Hi! In this case the name is being changed, a new column is added, and all the existing code points are updated in light of the new column. I realize this may not be enough for you.  Instead of all of us discussing this specific case, we should focus our energy on clearly defining what