Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Gyan Mishra]

Great Thanks Sarah!!

Gyan

On Thu, May 21, 2020 at 10:59 PM Sarah Chen  wrote:

> Hi, Gyan,
>
> I presented
> https://www.ietf.org/id/draft-chen-lsr-dynamic-flooding-algorithm-00.html in
> the last IETF. You may find the slides below helpful in understanding the
> algorithm:
>
>
> https://datatracker.ietf.org/meeting/interim-2020-lsr-01/materials/slides-interim-2020-lsr-01-sessa-2-dynamic-flooding-algo-sarah.pdf
>
> Thanks,
> Sarah
>
> On Thu, May 21, 2020 at 7:32 PM Gyan Mishra  wrote:
>
>>
>> I see the diagrams Appendix A -  reviewing
>>
>> Thanks
>>
>> Gyan
>>
>
>> On Thu, May 21, 2020 at 10:13 PM Gyan Mishra 
>> wrote:
>>
>
>>> I think for both drafts it would be good to have a stick diagram at a
>>> minimum.
>>>
>>> I majored in EE with math  minor and both drafts are hard to follow
>>> without a diagram with labels showing the exact topology examples.
>>>
>>> Four main topologies - full mesh, partial mesh and leaf spine ( 2 tier)
>>> and CLOS ( 3 tier) - real world scenario’s.
>>>
>>> From the interim meeting was their a slide deck visual topology shared?
>>>
>>> That would help.
>>>
>>> https://datatracker.ietf.org/doc/html/draft-cc-lsr-flooding-reduction-08
>>>
>>> 4.1
>>>
>>> Step 1 - Build Cq candidate queue
>>>
>>> For each node B on FT whose D is one (from minimum to maximum
>>>node ID), find a link L attached to B such that L's remote node R
>>>has minimum D and ID, add link L between B and R into FT and
>>>increase B's D and R's D by one.  Return FT.
>>>
>>> My interpretation is the algorithm an iterative loop and starts with any
>>> node in the candidate list so could start from edge and work left to right
>>> or vice versa.  For loop to build FT from Cq = with each node B with
>>> directly attached node R via link L.  Increment node B from Cq until the FT
>>> is build for all nodes.  Instead of starting with a wide diameter FT
>>> matching physical topology we start micro topology with D=1 and go node by
>>> node.
>>>
>>> 4.2
>>>
>>> 1.  Finding and removing the first element with node A in Cq that is
>>>not on FT and one PH's D in PHs < MaxD and PH's D < PH's ConMaxD..
>>>
>>>If A is root R0, then add the element into FT
>>>
>>>otherwise  (i.e., A != R0 with one PH's D in PHs < MaxD and PH's
>>>   D < PH's ConMaxD.  Assume that PH is the first one in PHs
>>>   whose D < MaxD and PH's D < PH's ConMaxD), PH's D++, and add A
>>>   with D = 1 and PHs = {PH} into FT.
>>>
>>>Note:  if there is no element with a node in Cq satisfying the
>>>   conditions, then algorithm may be restarted from R0, ++MaxD,
>>>   Cq = {(R0,D=0,PHs = { })}, FT = { };
>>>
>>> This is similar to 4.1 with micro topology with 2 directly connected
>>> nodes
>>>
>>> https://www.ietf.org/id/draft-chen-lsr-dynamic-flooding-algorithm-00.html
>>>
>>> My interpretation of the algorithm from the verbiage.
>>>
>>> So this draft starts in the middle of the topology and is geared towards
>>> leaf spine 2 or 3 tier clos topology.
>>>
>>> For this one we build the bi graph so that could be leaf connected to
>>> two spines or spine connected to two leafs and iteratively build out the FT
>>> topology 3 node arch  spine leaf spine or leaf spine leaf.
>>>
>>> Kind regards
>>>
>>> Gyan
>>>
>>
>>> On Thu, May 21, 2020 at 7:01 PM Acee Lindem (acee) 
>>> wrote:
>>>
>> Hi Gyan,



 *From: *Gyan Mishra 
 *Date: *Thursday, May 21, 2020 at 4:20 PM
 *To: *Acee Lindem 
 *Cc: *Huaimo Chen , "lsr@ietf.org" <
 lsr@ietf.org>
 *Subject: *Re: [Lsr] Flooding Topology Computation Algorithm -
 draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call





 Yes and I have started reviewing the LSR mail archives as I am late in
 the discussion for this.



 If you have link to any particular dates in the archives would be
 helpful.



 No – it was more an “evolution” than an “epiphany”.



 That sums up all the questions I have so if all answered in the
 archives then I am all set.



 I support the draft moving forward as flood reduction is a much needed
 feature.



 I think overall both drafts will really help large data centers with
 any overlay underlay vxlan spine leaf meshed CLOS highly meshed topology
 that scales out horizontally with a large spine footprint - this is a much
 much needed feature.  This also helps eliminate complexity of the
 workaround of using BGP in the underlay which to me adds tremendous
 complexity.



 Here is the other recently presented dynamic flooding draft.




 https://datatracker.ietf.org/doc/draft-chen-lsr-dynamic-flooding-algorithm/



 You can see they both make use of the dynamic flooding infra in
 https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/



 Th

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Sarah Chen]

Hi, Gyan,

I presented
https://www.ietf.org/id/draft-chen-lsr-dynamic-flooding-algorithm-00.html in
the last IETF. You may find the slides below helpful in understanding the
algorithm:

https://datatracker.ietf.org/meeting/interim-2020-lsr-01/materials/slides-interim-2020-lsr-01-sessa-2-dynamic-flooding-algo-sarah.pdf

Thanks,
Sarah

On Thu, May 21, 2020 at 7:32 PM Gyan Mishra  wrote:

>
> I see the diagrams Appendix A -  reviewing
>
> Thanks
>
> Gyan
>
> On Thu, May 21, 2020 at 10:13 PM Gyan Mishra 
> wrote:
>
>>
>> I think for both drafts it would be good to have a stick diagram at a
>> minimum.
>>
>> I majored in EE with math  minor and both drafts are hard to follow
>> without a diagram with labels showing the exact topology examples.
>>
>> Four main topologies - full mesh, partial mesh and leaf spine ( 2 tier)
>> and CLOS ( 3 tier) - real world scenario’s.
>>
>> From the interim meeting was their a slide deck visual topology shared?
>>
>> That would help.
>>
>> https://datatracker.ietf.org/doc/html/draft-cc-lsr-flooding-reduction-08
>>
>> 4.1
>>
>> Step 1 - Build Cq candidate queue
>>
>> For each node B on FT whose D is one (from minimum to maximum
>>node ID), find a link L attached to B such that L's remote node R
>>has minimum D and ID, add link L between B and R into FT and
>>increase B's D and R's D by one.  Return FT.
>>
>> My interpretation is the algorithm an iterative loop and starts with any
>> node in the candidate list so could start from edge and work left to right
>> or vice versa.  For loop to build FT from Cq = with each node B with
>> directly attached node R via link L.  Increment node B from Cq until the FT
>> is build for all nodes.  Instead of starting with a wide diameter FT
>> matching physical topology we start micro topology with D=1 and go node by
>> node.
>>
>> 4.2
>>
>> 1.  Finding and removing the first element with node A in Cq that is
>>not on FT and one PH's D in PHs < MaxD and PH's D < PH's ConMaxD.
>>
>>If A is root R0, then add the element into FT
>>
>>otherwise  (i.e., A != R0 with one PH's D in PHs < MaxD and PH's
>>   D < PH's ConMaxD.  Assume that PH is the first one in PHs
>>   whose D < MaxD and PH's D < PH's ConMaxD), PH's D++, and add A
>>   with D = 1 and PHs = {PH} into FT.
>>
>>Note:  if there is no element with a node in Cq satisfying the
>>   conditions, then algorithm may be restarted from R0, ++MaxD,
>>   Cq = {(R0,D=0,PHs = { })}, FT = { };
>>
>> This is similar to 4.1 with micro topology with 2 directly connected
>> nodes
>>
>> https://www.ietf.org/id/draft-chen-lsr-dynamic-flooding-algorithm-00.html
>>
>> My interpretation of the algorithm from the verbiage.
>>
>> So this draft starts in the middle of the topology and is geared towards
>> leaf spine 2 or 3 tier clos topology.
>>
>> For this one we build the bi graph so that could be leaf connected to two
>> spines or spine connected to two leafs and iteratively build out the FT
>> topology 3 node arch  spine leaf spine or leaf spine leaf.
>>
>> Kind regards
>>
>> Gyan
>>
>> On Thu, May 21, 2020 at 7:01 PM Acee Lindem (acee) 
>> wrote:
>>
>>> Hi Gyan,
>>>
>>>
>>>
>>> *From: *Gyan Mishra 
>>> *Date: *Thursday, May 21, 2020 at 4:20 PM
>>> *To: *Acee Lindem 
>>> *Cc: *Huaimo Chen , "lsr@ietf.org" <
>>> lsr@ietf.org>
>>> *Subject: *Re: [Lsr] Flooding Topology Computation Algorithm -
>>> draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
>>>
>>>
>>>
>>>
>>>
>>> Yes and I have started reviewing the LSR mail archives as I am late in
>>> the discussion for this.
>>>
>>>
>>>
>>> If you have link to any particular dates in the archives would be
>>> helpful.
>>>
>>>
>>>
>>> No – it was more an “evolution” than an “epiphany”.
>>>
>>>
>>>
>>> That sums up all the questions I have so if all answered in the archives
>>> then I am all set.
>>>
>>>
>>>
>>> I support the draft moving forward as flood reduction is a much needed
>>> feature.
>>>
>>>
>>>
>>> I think overall both drafts will really help large data centers with any
>>> overlay underlay vxlan spine leaf meshed CLOS highly meshed topology that
>>> scales out horizontally with a large spine footprint - this is a much much
>>> needed feature.  This also helps eliminate complexity of the workaround of
>>> using BGP in the underlay which to me adds tremendous complexity.
>>>
>>>
>>>
>>> Here is the other recently presented dynamic flooding draft.
>>>
>>>
>>>
>>>
>>> https://datatracker.ietf.org/doc/draft-chen-lsr-dynamic-flooding-algorithm/
>>>
>>>
>>>
>>> You can see they both make use of the dynamic flooding infra in
>>> https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Acee
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Kind regards
>>>
>>>
>>>
>>> Gyan
>>>
>>>
>>>
>>> On Thu, May 21, 2020 at 4:07 PM Acee Lindem (acee) 
>>> wrote:
>>>
>>> Speaking as WG Co-chair:
>>>
>>>
>>>
>>> Hi Gyan,
>>>
>>>
>>>
>>> I guess yo

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Gyan Mishra]

I see the diagrams Appendix A -  reviewing

Thanks

Gyan

On Thu, May 21, 2020 at 10:13 PM Gyan Mishra  wrote:

>
> I think for both drafts it would be good to have a stick diagram at a
> minimum.
>
> I majored in EE with math  minor and both drafts are hard to follow
> without a diagram with labels showing the exact topology examples.
>
> Four main topologies - full mesh, partial mesh and leaf spine ( 2 tier)
> and CLOS ( 3 tier) - real world scenario’s.
>
> From the interim meeting was their a slide deck visual topology shared?
>
> That would help.
>
> https://datatracker.ietf.org/doc/html/draft-cc-lsr-flooding-reduction-08
>
> 4.1
>
> Step 1 - Build Cq candidate queue
>
> For each node B on FT whose D is one (from minimum to maximum
>node ID), find a link L attached to B such that L's remote node R
>has minimum D and ID, add link L between B and R into FT and
>increase B's D and R's D by one.  Return FT.
>
> My interpretation is the algorithm an iterative loop and starts with any
> node in the candidate list so could start from edge and work left to right
> or vice versa.  For loop to build FT from Cq = with each node B with
> directly attached node R via link L.  Increment node B from Cq until the FT
> is build for all nodes.  Instead of starting with a wide diameter FT
> matching physical topology we start micro topology with D=1 and go node by
> node.
>
> 4.2
>
> 1.  Finding and removing the first element with node A in Cq that is
>not on FT and one PH's D in PHs < MaxD and PH's D < PH's ConMaxD.
>
>If A is root R0, then add the element into FT
>
>otherwise  (i.e., A != R0 with one PH's D in PHs < MaxD and PH's
>   D < PH's ConMaxD.  Assume that PH is the first one in PHs
>   whose D < MaxD and PH's D < PH's ConMaxD), PH's D++, and add A
>   with D = 1 and PHs = {PH} into FT.
>
>Note:  if there is no element with a node in Cq satisfying the
>   conditions, then algorithm may be restarted from R0, ++MaxD,
>   Cq = {(R0,D=0,PHs = { })}, FT = { };
>
> This is similar to 4.1 with micro topology with 2 directly connected nodes
>
> https://www.ietf.org/id/draft-chen-lsr-dynamic-flooding-algorithm-00.html
>
> My interpretation of the algorithm from the verbiage.
>
> So this draft starts in the middle of the topology and is geared towards
> leaf spine 2 or 3 tier clos topology.
>
> For this one we build the bi graph so that could be leaf connected to two
> spines or spine connected to two leafs and iteratively build out the FT
> topology 3 node arch  spine leaf spine or leaf spine leaf.
>
> Kind regards
>
> Gyan
>
> On Thu, May 21, 2020 at 7:01 PM Acee Lindem (acee)  wrote:
>
>> Hi Gyan,
>>
>>
>>
>> *From: *Gyan Mishra 
>> *Date: *Thursday, May 21, 2020 at 4:20 PM
>> *To: *Acee Lindem 
>> *Cc: *Huaimo Chen , "lsr@ietf.org" <
>> lsr@ietf.org>
>> *Subject: *Re: [Lsr] Flooding Topology Computation Algorithm -
>> draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
>>
>>
>>
>>
>>
>> Yes and I have started reviewing the LSR mail archives as I am late in
>> the discussion for this.
>>
>>
>>
>> If you have link to any particular dates in the archives would be helpful.
>>
>>
>>
>> No – it was more an “evolution” than an “epiphany”.
>>
>>
>>
>> That sums up all the questions I have so if all answered in the archives
>> then I am all set.
>>
>>
>>
>> I support the draft moving forward as flood reduction is a much needed
>> feature.
>>
>>
>>
>> I think overall both drafts will really help large data centers with any
>> overlay underlay vxlan spine leaf meshed CLOS highly meshed topology that
>> scales out horizontally with a large spine footprint - this is a much much
>> needed feature.  This also helps eliminate complexity of the workaround of
>> using BGP in the underlay which to me adds tremendous complexity.
>>
>>
>>
>> Here is the other recently presented dynamic flooding draft.
>>
>>
>>
>>
>> https://datatracker.ietf.org/doc/draft-chen-lsr-dynamic-flooding-algorithm/
>>
>>
>>
>> You can see they both make use of the dynamic flooding infra in
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/
>>
>>
>>
>> Thanks,
>>
>> Acee
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Kind regards
>>
>>
>>
>> Gyan
>>
>>
>>
>> On Thu, May 21, 2020 at 4:07 PM Acee Lindem (acee) 
>> wrote:
>>
>> Speaking as WG Co-chair:
>>
>>
>>
>> Hi Gyan,
>>
>>
>>
>> I guess you’ve joined this discussion late. It might be a good idea to
>> review the LSR mailing list archives.
>>
>>
>>
>> *From: *Gyan Mishra 
>> *Date: *Thursday, May 21, 2020 at 1:51 PM
>> *To: *Huaimo Chen 
>> *Cc: *Acee Lindem , "lsr@ietf.org" 
>> *Subject: *Re: [Lsr] Flooding Topology Computation Algorithm -
>> draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
>>
>>
>>
>>
>>
>>
>>
>> On Thu, May 21, 2020 at 11:01 AM Huaimo Chen 
>> wrote:
>>
>> Hi Gyan,
>>
>>
>>
>> Thanks much for your questions.
>>
>>
>>
>>  Gyan> How does this draft compare to the WG LC 

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Gyan Mishra]

I think for both drafts it would be good to have a stick diagram at a
minimum.

I majored in EE with math  minor and both drafts are hard to follow without
a diagram with labels showing the exact topology examples.

Four main topologies - full mesh, partial mesh and leaf spine ( 2 tier) and
CLOS ( 3 tier) - real world scenario’s.

>From the interim meeting was their a slide deck visual topology shared?

That would help.

https://datatracker.ietf.org/doc/html/draft-cc-lsr-flooding-reduction-08

4.1

Step 1 - Build Cq candidate queue

For each node B on FT whose D is one (from minimum to maximum
   node ID), find a link L attached to B such that L's remote node R
   has minimum D and ID, add link L between B and R into FT and
   increase B's D and R's D by one.  Return FT.

My interpretation is the algorithm an iterative loop and starts with any
node in the candidate list so could start from edge and work left to right
or vice versa.  For loop to build FT from Cq = with each node B with
directly attached node R via link L.  Increment node B from Cq until the FT
is build for all nodes.  Instead of starting with a wide diameter FT
matching physical topology we start micro topology with D=1 and go node by
node.

4.2

1.  Finding and removing the first element with node A in Cq that is
   not on FT and one PH's D in PHs < MaxD and PH's D < PH's ConMaxD.

   If A is root R0, then add the element into FT

   otherwise  (i.e., A != R0 with one PH's D in PHs < MaxD and PH's
  D < PH's ConMaxD.  Assume that PH is the first one in PHs
  whose D < MaxD and PH's D < PH's ConMaxD), PH's D++, and add A
  with D = 1 and PHs = {PH} into FT.

   Note:  if there is no element with a node in Cq satisfying the
  conditions, then algorithm may be restarted from R0, ++MaxD,
  Cq = {(R0,D=0,PHs = { })}, FT = { };

This is similar to 4.1 with micro topology with 2 directly connected nodes

https://www.ietf.org/id/draft-chen-lsr-dynamic-flooding-algorithm-00.html

My interpretation of the algorithm from the verbiage.

So this draft starts in the middle of the topology and is geared towards
leaf spine 2 or 3 tier clos topology.

For this one we build the bi graph so that could be leaf connected to two
spines or spine connected to two leafs and iteratively build out the FT
topology 3 node arch  spine leaf spine or leaf spine leaf.

Kind regards

Gyan

On Thu, May 21, 2020 at 7:01 PM Acee Lindem (acee)  wrote:

> Hi Gyan,
>
>
>
> *From: *Gyan Mishra 
> *Date: *Thursday, May 21, 2020 at 4:20 PM
> *To: *Acee Lindem 
> *Cc: *Huaimo Chen , "lsr@ietf.org" <
> lsr@ietf.org>
> *Subject: *Re: [Lsr] Flooding Topology Computation Algorithm -
> draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
>
>
>
>
>
> Yes and I have started reviewing the LSR mail archives as I am late in the
> discussion for this.
>
>
>
> If you have link to any particular dates in the archives would be helpful..
>
>
>
> No – it was more an “evolution” than an “epiphany”.
>
>
>
> That sums up all the questions I have so if all answered in the archives
> then I am all set.
>
>
>
> I support the draft moving forward as flood reduction is a much needed
> feature.
>
>
>
> I think overall both drafts will really help large data centers with any
> overlay underlay vxlan spine leaf meshed CLOS highly meshed topology that
> scales out horizontally with a large spine footprint - this is a much much
> needed feature.  This also helps eliminate complexity of the workaround of
> using BGP in the underlay which to me adds tremendous complexity.
>
>
>
> Here is the other recently presented dynamic flooding draft.
>
>
>
> https://datatracker.ietf.org/doc/draft-chen-lsr-dynamic-flooding-algorithm/
>
>
>
> You can see they both make use of the dynamic flooding infra in
> https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/
>
>
>
> Thanks,
>
> Acee
>
>
>
>
>
>
>
>
>
> Kind regards
>
>
>
> Gyan
>
>
>
> On Thu, May 21, 2020 at 4:07 PM Acee Lindem (acee)  wrote:
>
> Speaking as WG Co-chair:
>
>
>
> Hi Gyan,
>
>
>
> I guess you’ve joined this discussion late. It might be a good idea to
> review the LSR mailing list archives.
>
>
>
> *From: *Gyan Mishra 
> *Date: *Thursday, May 21, 2020 at 1:51 PM
> *To: *Huaimo Chen 
> *Cc: *Acee Lindem , "lsr@ietf.org" 
> *Subject: *Re: [Lsr] Flooding Topology Computation Algorithm -
> draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
>
>
>
>
>
>
>
> On Thu, May 21, 2020 at 11:01 AM Huaimo Chen 
> wrote:
>
> Hi Gyan,
>
>
>
> Thanks much for your questions.
>
>
>
>  Gyan> How does this draft compare to the WG LC draft for flood
> reduction.  Would they be two eventual standard options in the operators
> toolbox  or competing features for optimized flood reduction. Would having
> two flood reduction features standardized versus one default IGP flood
> reduction feature be confusing for operators.  Just as it was confusing to
> me.
>
> https://datatracker.i

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Acee Lindem (acee)]

Hi Gyan,

From: Gyan Mishra 
Date: Thursday, May 21, 2020 at 4:20 PM
To: Acee Lindem 
Cc: Huaimo Chen , "lsr@ietf.org" 
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call


Yes and I have started reviewing the LSR mail archives as I am late in the 
discussion for this.

If you have link to any particular dates in the archives would be helpful.

No – it was more an “evolution” than an “epiphany”.

That sums up all the questions I have so if all answered in the archives then I 
am all set.

I support the draft moving forward as flood reduction is a much needed feature.

I think overall both drafts will really help large data centers with any 
overlay underlay vxlan spine leaf meshed CLOS highly meshed topology that 
scales out horizontally with a large spine footprint - this is a much much 
needed feature.  This also helps eliminate complexity of the workaround of 
using BGP in the underlay which to me adds tremendous complexity.

Here is the other recently presented dynamic flooding draft.

https://datatracker.ietf.org/doc/draft-chen-lsr-dynamic-flooding-algorithm/

You can see they both make use of the dynamic flooding infra in 
https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/

Thanks,
Acee




Kind regards

Gyan

On Thu, May 21, 2020 at 4:07 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Speaking as WG Co-chair:

Hi Gyan,

I guess you’ve joined this discussion late. It might be a good idea to review 
the LSR mailing list archives.

From: Gyan Mishra mailto:hayabusa...@gmail.com>>
Date: Thursday, May 21, 2020 at 1:51 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Cc: Acee Lindem mailto:a...@cisco.com>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call



On Thu, May 21, 2020 at 11:01 AM Huaimo Chen 
mailto:huaimo.c...@futurewei.com>> wrote:
Hi Gyan,

Thanks much for your questions.

 Gyan> How does this draft compare to the WG LC draft for flood reduction.  
Would they be two eventual standard options in the operators toolbox  or 
competing features for optimized flood reduction. Would having two flood 
reduction features standardized versus one default IGP flood reduction feature 
be confusing for operators.  Just as it was confusing to me.
https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/

[HC]: This draft plus the draft for flooding reduction can provide two 
modes of flooding reductions (i.e., centralized mode and distributed mode). The 
latter describes the two modes, but does not include any flooding topology 
computation algorithm for the distributed mode. The former proposes a flooding 
topology computation algorithm to be used in the distributed mode.

   Gyan> It maybe a good idea for both documents to reference each other as to 
how they play together or  in some respects if any provide a homogeneous 
complete holistic solution for flooding problem being solved.

It is a good idea to have this new draft reference the dynamic-flooding but not 
vice-versa. The existing dynamic flooding draft provides a framework for any 
dynamic flooding algorithm that provides a separate flooding topology. This 
algorithm is just the first to be formally proposed in a draft. Note that 
another algorithm was presented during the LSR virtual interim which replaced 
IETF 107.

In my opinion it may not be a bad idea even to combine both drafts so the 
solution is complete and holistic.  This will also make the overall 
specification flow nicely.

No – we’re not going to do this.

Thanks,
Acee

I know that efforts were made by LSR to have a common IGP solution, however 
there are many inherent differences between ISIS and OSPF that from IGP Link 
state protocol perspective you can treat like apples to apples but really it’s 
apples and oranges.  Maybe it might we wise to have separate draft for both and 
have references linking together as the same algorithm concept and 
mathematically however the actual code implementation would vary as the LSDB 
link state data structures are completely different.

Later = Dynamic flooding = 2 modes Centralized leader based and distributed

https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/

This later draft per section excerpt provides both centralized and distributed 
algorithm see below


6.4.
  Area Leader Responsibilities



   If the Area Leader operates in centralized mode, it MUST adver

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Gyan Mishra]

Yes and I have started reviewing the LSR mail archives as I am late in the
discussion for this.

If you have link to any particular dates in the archives would be helpful.

That sums up all the questions I have so if all answered in the archives
then I am all set.

I support the draft moving forward as flood reduction is a much needed
feature.

I think overall both drafts will really help large data centers with any
overlay underlay vxlan spine leaf meshed CLOS highly meshed topology that
scales out horizontally with a large spine footprint - this is a much much
needed feature.  This also helps eliminate complexity of the workaround of
using BGP in the underlay which to me adds tremendous complexity.

Kind regards

Gyan

On Thu, May 21, 2020 at 4:07 PM Acee Lindem (acee)  wrote:

> Speaking as WG Co-chair:
>
>
>
> Hi Gyan,
>
>
>
> I guess you’ve joined this discussion late. It might be a good idea to
> review the LSR mailing list archives.
>
>
>
> *From: *Gyan Mishra 
> *Date: *Thursday, May 21, 2020 at 1:51 PM
> *To: *Huaimo Chen 
> *Cc: *Acee Lindem , "lsr@ietf.org" 
> *Subject: *Re: [Lsr] Flooding Topology Computation Algorithm -
> draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
>
>
>
>
>
>
>
> On Thu, May 21, 2020 at 11:01 AM Huaimo Chen 
> wrote:
>
> Hi Gyan,
>
>
>
> Thanks much for your questions.
>
>
>
>  Gyan> How does this draft compare to the WG LC draft for flood
> reduction.  Would they be two eventual standard options in the operators
> toolbox  or competing features for optimized flood reduction. Would having
> two flood reduction features standardized versus one default IGP flood
> reduction feature be confusing for operators.  Just as it was confusing to
> me.
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/
> 
>
>
>
> [HC]: This draft plus the draft for flooding reduction can provide two
> modes of flooding reductions (i.e., centralized mode and distributed mode).
> The latter describes the two modes, but does not include any flooding
> topology computation algorithm for the distributed mode. The former
> proposes a flooding topology computation algorithm to be used in the
> distributed mode.
>
>
>
>Gyan> It maybe a good idea for both documents to reference each other
> as to how they play together or  in some respects if any provide a
> homogeneous complete holistic solution for flooding problem being solved.
>
>
>
> It is a good idea to have this new draft reference the dynamic-flooding
> but not vice-versa. The existing dynamic flooding draft provides a
> framework for any dynamic flooding algorithm that provides a separate
> flooding topology. This algorithm is just the first to be formally proposed
> in a draft. Note that another algorithm was presented during the LSR
> virtual interim which replaced IETF 107.
>
>
>
> In my opinion it may not be a bad idea even to combine both drafts so the
> solution is complete and holistic.  This will also make the overall
> specification flow nicely.
>
>
>
> No – we’re not going to do this.
>
>
>
> Thanks,
>
> Acee
>
>
>
> I know that efforts were made by LSR to have a common IGP solution,
> however there are many inherent differences between ISIS and OSPF that from
> IGP Link state protocol perspective you can treat like apples to apples but
> really it’s apples and oranges.  Maybe it might we wise to have separate
> draft for both and have references linking together as the same algorithm
> concept and mathematically however the actual code implementation would
> vary as the LSDB link state data structures are completely different.
>
>
>
> Later = Dynamic flooding = 2 modes Centralized leader based and
> distributed
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/
>
>
>
> This later draft per section excerpt provides both centralized and
> distributed algorithm see below
>
>
>
> *6.4 
> .
>   Area Leader Responsibilities*
>
>
>
>If the Area Leader operates in centralized mode, it MUST advertise
>
>algorithm 0 in its Area Leader Sub-TLV.  In order for Dynamic
>
>Flooding to be enabled it also MUST compute and advertise a flooding
>
>topology for the area.  The Area Leader may update the flooding
>
>topology at any time, however, it should not destabilize the network
>
>with undue or overly frequent topology changes.  If the Area Leader
>
>operates in centralized mode and needs to advertise a new flooding
>
>topology, it floods the new flooding topology on both the new and old
>
>flooding topologies.
>
>
>
>If the Area Le

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Acee Lindem (acee)]

Speaking as WG Co-chair:

Hi Gyan,

I guess you’ve joined this discussion late. It might be a good idea to review 
the LSR mailing list archives.

From: Gyan Mishra 
Date: Thursday, May 21, 2020 at 1:51 PM
To: Huaimo Chen 
Cc: Acee Lindem , "lsr@ietf.org" 
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call



On Thu, May 21, 2020 at 11:01 AM Huaimo Chen 
mailto:huaimo.c...@futurewei.com>> wrote:
Hi Gyan,

Thanks much for your questions.

 Gyan> How does this draft compare to the WG LC draft for flood reduction.  
Would they be two eventual standard options in the operators toolbox  or 
competing features for optimized flood reduction. Would having two flood 
reduction features standardized versus one default IGP flood reduction feature 
be confusing for operators.  Just as it was confusing to me.
https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/

[HC]: This draft plus the draft for flooding reduction can provide two 
modes of flooding reductions (i.e., centralized mode and distributed mode). The 
latter describes the two modes, but does not include any flooding topology 
computation algorithm for the distributed mode. The former proposes a flooding 
topology computation algorithm to be used in the distributed mode.

   Gyan> It maybe a good idea for both documents to reference each other as to 
how they play together or  in some respects if any provide a homogeneous 
complete holistic solution for flooding problem being solved.

It is a good idea to have this new draft reference the dynamic-flooding but not 
vice-versa. The existing dynamic flooding draft provides a framework for any 
dynamic flooding algorithm that provides a separate flooding topology. This 
algorithm is just the first to be formally proposed in a draft. Note that 
another algorithm was presented during the LSR virtual interim which replaced 
IETF 107.

In my opinion it may not be a bad idea even to combine both drafts so the 
solution is complete and holistic.  This will also make the overall 
specification flow nicely.

No – we’re not going to do this.

Thanks,
Acee

I know that efforts were made by LSR to have a common IGP solution, however 
there are many inherent differences between ISIS and OSPF that from IGP Link 
state protocol perspective you can treat like apples to apples but really it’s 
apples and oranges.  Maybe it might we wise to have separate draft for both and 
have references linking together as the same algorithm concept and 
mathematically however the actual code implementation would vary as the LSDB 
link state data structures are completely different.

Later = Dynamic flooding = 2 modes Centralized leader based and distributed

https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/

This later draft per section excerpt provides both centralized and distributed 
algorithm see below


6.4.
  Area Leader Responsibilities



   If the Area Leader operates in centralized mode, it MUST advertise

   algorithm 0 in its Area Leader Sub-TLV.  In order for Dynamic

   Flooding to be enabled it also MUST compute and advertise a flooding

   topology for the area.  The Area Leader may update the flooding

   topology at any time, however, it should not destabilize the network

   with undue or overly frequent topology changes.  If the Area Leader

   operates in centralized mode and needs to advertise a new flooding

   topology, it floods the new flooding topology on both the new and old

   flooding topologies.



   If the Area Leader operates in distributed mode, it MUST advertise a

   non-zero algorithm in its Area Leader Sub-TLV.



   When the Area Leader advertises algorithm 0 in its Area Leader Sub-

   TLV and does not advertise a flooding topology, Dynamic Flooding is

   disabled for the area.  Note this applies whether the Area Leader

   intends to operate in centralized mode or in distributed mode.



   Note that once Dynamic Flooding is enabled, disabling it risks

   destabilizing the network.



6.5.
  Distributed Flooding Topology Calculation



   If the Area Leader advertises a non-zero algorithm in its Area Leader

   Sub-TLV, all nodes in the area that support Dynamic Flooding and the

   value of algorithm advertised by the Area Leader MUST compute the

   flooding topology based on the Area Leader's advertised algorithm.



   Nodes that do not support the value of algorithm advertised by the

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-mpls-elc-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

On Thu, May 21, 2020 at 12:16:44PM +0200, Peter Psenak wrote:
> Hi Benjamin,
> 
> thanks for review.
> 
> Please see inline (##PP) two responses to OSPF specific comments.
> 
> 
> On 20/05/2020 00:43, Benjamin Kaduk via Datatracker wrote:
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-ospf-mpls-elc-13: 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 IESG DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/
> > 
> > 
> > 
> > --
> > DISCUSS:
> > --
> > 
> > I have a question about the scope of some normative language, which may
> > or may not be problematic but I'm too ignorant of OSPF details to be
> > able to answer myself.  In Section 3 we say that:
> > 
> > When an OSPF Area Border Router (ABR) distributes information between
> > connected areas it MUST preserve the ELC setting.
> > 
> > My undesrtanding is that it's normal operation for an ABR to
> > distribution information about prefixes and such between areas, and in
> > particular that an ABR does not necessarily need to know the semantic
> > details of every bit of information being distributed in that fashion.
> > So, I am imagining a scenario where some routers in both areas
> > advertise/understand the ELC flag but the ABR between them does not
> > implement this spec.  What would happen in such a scenario?  If the ABR
> > is still expected to distribute the ELC setting without change, isn't
> > that just a core requirement from the respective OSPF specs, as opposed
> > to a new requirement imposed by this spec (which, in this scenario, the
> > ABR is not claiming to adhere to anyway)?
> > 
> > There is perhaps a similar question about the ASBR guidance, though when
> > doing cross-protocol signalling there is a more clear need for the ASBR
> > to understand the semantics of the flags it is redistributing (and it's
> > only a "SHOULD").
> > 
> > 
> > --
> > COMMENT:
> > --
> > 
> > Section 1
> > 
> > The abstract is pretty explicit that "this draft defines" both ELC and
> > ERLD signaling capabilities, but this section only has a clear statement
> > for the ELC.  Should we put something at the end of the last paragraph
> > about "this document defines a mechanism to signal the ERLD using OSPFv2
> > and OSPFv3"?
> 
> ##PP
> this has been already addressed based on previous comments. Latest text 
> is as follows:
> 
> "Multiprotocol Label Switching (MPLS) has defined a mechanism to 
> load-balance traffic flows using Entropy Labels (EL). An ingress Label
> Switching Router (LSR) cannot insert ELs for packets going into a given 
> Label Switched Path (LSP) unless an egress LSR has indicated via 
> signaling that it has the capability to process ELs, referred to as the 
> Entropy Label Capability (ELC), on that LSP. In addition, it would be 
> useful for ingress LSRs to know each LSR's capability for reading the 
> maximum label stack depth and performing EL-based load-balancing, 
> referred to as Entropy Readable Label Depth (ERLD). This document 
> defines a mechanism to signal these two capabilities using OSPFv2 and 
> OSPFv3 and BGP-LS."

Great; thanks!

> > In cases where LSPs are used (e.g., SR-MPLS [RFC8660], it would be
> > 
> > side note(?): I don't know that SR-MPLS is so popular so as to be
> > privileged as the only example given for LSP usage.  If we instead
> > talked about using IGPs to signal labels, this selection would seem less
> > surprising to me.
> > 
> > Section 3
> > 
> > If the router supports ELs on all of its interfaces, it SHOULD
> > advertise the ELC with every local host prefix it advertises in OSPF.
> > 
> > Do we want to say anything about (not) advertising the ELC for other
> > prefixes?
> > 
> > Section 7
> > 
> > Should we say anything about considerations for redistributing ELC/ERLD
> > information at the ASBR with respect to exposing "internal information"
> > to external parties?
> > 
> > This document specifies the ability to advertise additional node
> > capabilities using OSPF and BGP-LS.  As such, the security
> > considerations as described in [RFC5340], [RFC7770], [RFC7752],
> > [RFC7684], [RFC8476], [RFC8662],
> > 
> > RFC 8662's security considerations have a pretty hard dependency on RFC
> > 6790's security considerations; it might be worth mentioning 6790
> > directly in this lis

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

Hi Peter,

On Thu, May 21, 2020 at 12:05:39PM +0200, Peter Psenak wrote:
> Benjamin,
> 
> thanks for review, please see inline (##PP):
> 
> On 20/05/2020 00:44, Benjamin Kaduk via Datatracker wrote:
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-isis-mpls-elc-12: 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 IESG DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/
> > 
> > 
> > 
> > --
> > DISCUSS:
> > --
> > 
> > As for other reviewers, many of my comments duplicate those for the OSPF
> > document; I expect that the analogous responses apply and am fine if
> > they only appear for one document's review.
> > 
> > Here, the question I have about normative language applies to the text
> > in Section 3:
> > 
> > When a router propagates a prefix between ISIS levels ([RFC5302], it
> > MUST preserve the ELC signaling for this prefix.
> > 
> > The scenario in question is analogous to the OSPF cross-area case: is
> > the router propagating the prefix between ISIS levels required to
> > implement this document; is preservation of the flag value a new
> > requirement from this document vs. a preexisting property; and is this
> > document trying to make normative requirements of devices that don't
> > implement this document?
> 
> ##PP
> this is a new requirement and only applies to the routers that support 
> this document. We are not making normative requirements of devices that 
> don't implement this document, we cannot.
> 
> Maybe we can add that it only applies to the routers that supports this 
> extension:
> 
> "When a router supporting this extension propagates a prefix between 
> ISIS levels ([RFC5302], it MUST preserve the ELC signaling for this prefix."
> 
> Would it work?

That would work, yes.
I think what bothers me about the current text is that it feels like a
global statement that holds universally everywhere (and as such would be
"scope overreach").  Even to say something like "ELC signaling MUST be
preserved when a router propagates a prefix between ISIS levels" (which is
superficially similar) does not bother me very much, since it presumes a
knowledge of what ELC signaling is (and thus, implementation of this
document) in a way that "unknown prefix attribute flag 3" does not.  That
is, we clearly (given your above explanation) don't expect the "unknown
prefix attribute flag 3" to get propagaged, and only when we know that it's
the ELC signalling does the requirement kick in, if that makes sense.

With respect to Alvaro's clarification, your answer for (1) makes sense;
thanks!  I think Alvaro has offered to help work out what (if any)
additional text we might want to be sure that the answer to (2) is clear in
the document.

> 
> > 
> > Likewise, the ASBR case for cross-protocol redistribution seems to
> > rather inherently require understanding the semantics of the flags being
> > translated.
> 
> similarly to the above I can chnage to:
> 
> "When a router supporting this extension redistribute a prefix ..."
> 
> 
> > 
> > 
> > --
> > COMMENT:
> > --
> > 
> > Section 1
> > 
> > Should we add a sentence at the end of the last paragraph about how
> > "this document defines a mechanism to signal the ERLD using IS-IS"?
> 
> not sure I understand, how is described in the body of the document.

I think I maybe put a little more detail on the motivation for this
question in the OSPF document's comments.  Basically, it's about parity
between Abstract and Introduction -- the Introduction says clearly "this
draft defines a mechanism to signal the ELC using IS-IS", but there is not
an analogous statement about the ERLD signaling mechanism.  As such, it's
an editorial matter of style and you should feel free to ignore the comment
or do what you see fit.

> > 
> > In cases where LSPs are used (e.g., SR-MPLS [RFC8660], it would be
> > 
> > side note(?): I don't know that SR-MPLS is so popular so as to be
> > privileged as the only example given for LSP usage.  If we instead
> > talked about using IGPs to signal labels, this selection would seem less
> > surprising to me.
> 
> this document describes the ELC/ERLD capability signaling for SR MPLS. 
> For non SR MPLS cases, thee are existing mechanisms to learn ELC/ERLD.
> 
> I can replace the text with:
> 
> "In cases where SR is used with the MPLS Data Plane"

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Gyan Mishra]

On Thu, May 21, 2020 at 11:01 AM Huaimo Chen 
wrote:

> Hi Gyan,
>
> Thanks much for your questions.
>
>  Gyan> How does this draft compare to the WG LC draft for flood
> reduction.  Would they be two eventual standard options in the operators
> toolbox  or competing features for optimized flood reduction. Would having
> two flood reduction features standardized versus one default IGP flood
> reduction feature be confusing for operators.  Just as it was confusing to
> me.
> https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/
> 
>
>
> [HC]: This draft plus the draft for flooding reduction can provide two
> modes of flooding reductions (i.e., centralized mode and distributed mode).
> The latter describes the two modes, but does not include any flooding
> topology computation algorithm for the distributed mode. The former
> proposes a flooding topology computation algorithm to be used in the
> distributed mode.
>

   Gyan> It maybe a good idea for both documents to reference each other as
to how they play together or  in some respects if any provide a homogeneous
complete holistic solution for flooding problem being solved.

In my opinion it may not be a bad idea even to combine both drafts so the
solution is complete and holistic.  This will also make the overall
specification flow nicely.

I know that efforts were made by LSR to have a common IGP solution, however
there are many inherent differences between ISIS and OSPF that from IGP
Link state protocol perspective you can treat like apples to apples but
really it’s apples and oranges.  Maybe it might we wise to have separate
draft for both and have references linking together as the same algorithm
concept and mathematically however the actual code implementation would
vary as the LSDB link state data structures are completely different.

Later = Dynamic flooding = 2 modes Centralized leader based and distributed

https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/

This later draft per section excerpt provides both centralized and
distributed algorithm see below

6.4 
.
Area Leader Responsibilities

   If the Area Leader operates in centralized mode, it MUST advertise
   algorithm 0 in its Area Leader Sub-TLV.  In order for Dynamic
   Flooding to be enabled it also MUST compute and advertise a flooding
   topology for the area.  The Area Leader may update the flooding
   topology at any time, however, it should not destabilize the network
   with undue or overly frequent topology changes.  If the Area Leader
   operates in centralized mode and needs to advertise a new flooding
   topology, it floods the new flooding topology on both the new and old
   flooding topologies.

   If the Area Leader operates in distributed mode, it MUST advertise a
   non-zero algorithm in its Area Leader Sub-TLV.

   When the Area Leader advertises algorithm 0 in its Area Leader Sub-
   TLV and does not advertise a flooding topology, Dynamic Flooding is
   disabled for the area.  Note this applies whether the Area Leader
   intends to operate in centralized mode or in distributed mode.

   Note that once Dynamic Flooding is enabled, disabling it risks
   destabilizing the network.
6.5 
.
Distributed Flooding Topology Calculation

   If the Area Leader advertises a non-zero algorithm in its Area Leader
   Sub-TLV, all nodes in the area that support Dynamic Flooding and the
   value of algorithm advertised by the Area Leader MUST compute the
   flooding topology based on the Area Leader's advertised algorithm.

   Nodes that do not support the value of algorithm advertised by the
   Area Leader MUST continue to use standard flooding mechanism as
   defined by the protocol.

   Nodes that do not support the value of algorithm advertised by the
   Area Leader MUST be considered as Dynamic Flooding incapable nodes by
   the Area Leader.

   If the value of the algorithm advertised by the Area Leader is from
   the range 128-254 (private distributed algorithms), it is the
responsibility of the

network operator to guarantee that all nodes in the area have a common
understanding of what the given algorithm value represents.


Former = WG LC
https://datatracker.ietf.org/doc/html/draft-cc-lsr-flooding-reduction-08

Provides algorithm for distributed mode for this draft as well as the
algorithm to be used for distributed mode later dynamic flooding draft

Separate question-

In light of the flooding algorithm and seeing that at the bottom of section
6

Re: [Lsr] Alissa Cooper's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)ret, .

[Peter Psenak]

Alissa,

as Les correctly pointed out privately to me, this updated text is not 
entirely correct. Not advertising the ELC bit can be result of:


a) router not supporting this extension
b) router supporting this extension, but not supporting ELC

So I would rather keep the original text unchanged.

This is not anything new. This ambiguity is common for any new protocol 
extension that signals a boolean type of information.


thanks,
Peter


On 21/05/2020 15:09, Alissa Cooper wrote:

Thanks!
Alissa

On May 21, 2020, at 3:51 AM, Peter Psenak > wrote:


Hi Alissa,

On 20/05/2020 21:57, Alissa Cooper via Datatracker wrote:

Alissa Cooper has entered the following ballot position for
draft-ietf-ospf-mpls-elc-13: 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 IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/
--
COMMENT:
--
I wasn't clear on where the  thread ended up from the Gen-ART review, 
but I'm
nevertheless suggesting some text below to resolve the main sticking 
point.

OLD
If the router supports ELs on all of its interfaces, it SHOULD 
advertise the

ELC with every local host prefix it advertises in OSPF.
NEW
If the router supports ELs on all of its interfaces, it SHOULD 
advertise the
ELC with every local host prefix it advertises in OSPF. The absence 
of these

advertisements implies that advertisement of the ELC is not supported.


I added the suggested text, plus I added "OSPF" at the end. So the 
text is:


"If the router supports ELs on all of its interfaces, it SHOULD 
advertise the ELC with every local host prefix it advertises in OSPF. 
The absence of these advertisements implies that advertisement of the 
ELC is not supported in OSPF."


I added similar text to ISIS ELC draft.

thanks,
Peter


Not sure if that matches the intent though.




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

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Huaimo Chen]

Hi Gyan,

Thanks much for your questions.

 Gyan> How does this draft compare to the WG LC draft for flood reduction.  
Would they be two eventual standard options in the operators toolbox  or 
competing features for optimized flood reduction. Would having two flood 
reduction features standardized versus one default IGP flood reduction feature 
be confusing for operators.  Just as it was confusing to me.
https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/

[HC]: This draft plus the draft for flooding reduction can provide two 
modes of flooding reductions (i.e., centralized mode and distributed mode). The 
latter describes the two modes, but does not include any flooding topology 
computation algorithm for the distributed mode. The former proposes a flooding 
topology computation algorithm to be used in the distributed mode.

Best Regards,
Huaimo

From: Gyan Mishra 
Sent: Thursday, May 21, 2020 10:36 AM
To: Huaimo Chen 
Cc: Acee Lindem (acee) ; lsr@ietf.org 

Subject: Re: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call



On Wed, May 20, 2020 at 11:59 PM Huaimo Chen 
mailto:huaimo.c...@futurewei.com>> wrote:
Hi Gyan,

Thanks much for your questions. My answers are inline below with [HC].

Best Regards,
Huaimo

From: Gyan Mishra mailto:hayabusa...@gmail.com>>
Sent: Wednesday, May 20, 2020 11:14 AM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Cc: Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>; 
lsr@ietf.org mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

Huaimo

This is a much needed feature that operators have been needing for densely 
meshed topologies that commonly exist in data centers to accommodate very high 
bandwidth E-W traffic.
[HC]: Thank you very much.

Below is link from Cisco which has introduced feature for dynamic flooding in 
clos high density ECMP data center topologies.

Please look at the feature description and it does seem to be exactly the same 
as this draft.  Please confirm.
[HC]: It seems different.

There maybe other vendors due to industry demand have to get the feature 
deployed before it reaches standards vendor consensus with the IETF.

https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-743015.html

We are testing this feature and planning to deploy but wanted to ensure that 
this is the same as the draft on the standards track.
[HC]: The feature appears implemented draft "Dynamic Flooding on Dense Graphs", 
which does not include any flooding topology computation algorithm.

Gyan> How does this draft compare to the WG LC draft for flood reduction.  
Would they be two eventual standard options in the operators toolbox  or 
competing features for optimized flood reduction. Would having two flood 
reduction features standardized versus one default IGP flood reduction feature 
be confusing for operators.  Just as it was confusing to me.


https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/

Kind regards

Gyan


On Tue, May 19, 2020 at 11:52 PM Huaimo Chen 
mailto:huaimo.c...@futurewei.com>> wrote:
Hi Gyan,

Thank you very much for your questions and support.

This Flooding Topology Computation algorithm can be used in the Dynamic 
Flooding on Dense Graphs to compute the flooding topologies for the data center 
clos dense meshed topologies with many ECMP paths. It can be used by the area 
leader in the centralized mode to compute the flooding topology.

Best Regards,
Huaimo

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Gyan 
Mishra mailto:hayabusa...@gmail.com>>
Sent: Tuesday, May 19, 2020 2:39 AM
To: Yanhe Fan mailto:y...@ca

Re: [Lsr] Tsvart last call review of draft-ietf-isis-te-app-13

[Les Ginsberg (ginsberg)]

Kyle –

Inline.

From: Kyle Rose 
Sent: Thursday, May 21, 2020 6:09 AM
To: Les Ginsberg (ginsberg) 
Cc: tsv-...@ietf.org; draft-ietf-isis-te-app@ietf.org; lsr@ietf.org; 
last-c...@ietf.org
Subject: Re: Tsvart last call review of draft-ietf-isis-te-app-13

On Thu, May 21, 2020 at 2:28 AM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
> * Update language?
>
> There are several places in which it is possible that normative language in
> prior RFCs is revised. For example, in section 6.1, the last paragraph states:
>
>   New applications which future documents define to make use of the
>   advertisements defined in this document MUST NOT make use of legacy
>   advertisements.
>
> This looks like it was written in such a way as to avoid requiring such
> updates, but it would be good to confirm that there is no normative language
> in
> older documents that would conflict with this requirement.
>
[Les:] For applications which preexisted the writing of this draft (the ones 
defined in Section 7.4) there are existing deployments which use legacy 
advertisements.
Transitioning to use new advertisements has to account for partial deployment 
of such support.
And the transition has to be managed by the network operator using knobs 
provided by implementations. This is onerous - but unavoidable in these cases.

For new applications we want to avoid this complexity/pain. So we specify new 
applications MUST use the new advertisements from day ONE.

As these are new applications there is no legacy to deal with and no existing 
specification which would be in conflict.

That's what I figured. Is it the case that new standardized applications 
require an RFC? If so, I think this is fine.

[Les:] Yes. In order to obtain a new bit in the new Link Attribute Application 
Identifier Registry defined in Section 7.4 the process defined in RFC 8126 
Standards Action is required – which means an RFC has to be written for the new 
application.


> * Encoding
>
> In section 4.1, the bit masks are defined with a 7 bit length field for which
> only 4 bits are useful (values 0-8). It may make sense to keep the 3 high 
> order
> bits as "reserved" and set to zero, but either way it would be nice to
> understand the justification for whatever design decision is made.
>
> You go to some length to save space (e.g., a zero-length SABM means "all
> applications") but always include an octet for UDABM length, which I
> presume
> will be zero outside the lab in most cases. How much does an extra octet
> cost?
> If it's a lot, you could use the three high-order bits to represent the first
> three applications (RSVP-TE, SRTE, and LFA) and save yourself an octet until a
> fourth application appears.
>
> For that matter, how likely are you to get to 256 standardized applications
> under IS-IS?
>
[Les:] The limitation for the xABM length to be no more than 8 bytes was 
introduced only recently based on a review comment.
The concern was that without a limit, it would be theoretically possible for 
the ABM itself to consume the full sub-TLV space, leaving no room for the 
actual link attribute advertisements.
So we placed a maximum length to avoid this potential issue.
As each application consumes one bit, with an 8 byte maximum length we can 
support 64 applications.
Sigh... yes, math is hard.

This seems more than we will ever get to - but if anyone in the WG thinks this 
is not large enough they should speak now so we can increase the maximum.

I suspect even 64 is safely more than you'll need, but if not there's always 
the possibility of a new TLV later on. :-)

There are existing implementations of this draft which have been deployed. 
Changing the bit positions as you suggested would not be backwards compatible.
I do not think the small space savings would be worth the trouble.

Understood, though I will point out that this illustrates the potential harm in 
deploying something hard to change prior to standardization. Thankfully, IS-IS 
is not interdomain, meaning that any such change would impose costs only on 
those who deployed early.
[Les:] Agreed – but it is also good to have demonstrated the viability of the 
extensions – as well as interoperability – before going to RFC. So early 
implementations have great value.
But, also, let’s not overvalue the space optimization.
IS-IS has always tried to be “frugal” in its use of space – but I think we can 
afford the extra byte. 😊

> In effect, use of legacy advertisements vs. app-specific advertisements is
> all-or-nothing. If that's the case, wouldn't a top-level TLV specifying a
> legacy mask for applications be more compact, less redundant, and further
> reduce the overall number/size of advertisements?
>
[Les:] The information being advertised here (link attributes) is necessarily 
associated with a top level TLV describing a link to a neighbor (TLVs 22, 23, 
25, 141, 222, and 223) . Without that context the link attribute information is 
meaningless.

Yes, this makes sense,

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Gyan Mishra]

On Wed, May 20, 2020 at 11:59 PM Huaimo Chen 
wrote:

> Hi Gyan,
>
> Thanks much for your questions. My answers are inline below with [HC]..
>
> Best Regards,
> Huaimo
> --
> *From:* Gyan Mishra 
> *Sent:* Wednesday, May 20, 2020 11:14 AM
> *To:* Huaimo Chen 
> *Cc:* Acee Lindem (acee) ; lsr@ietf.org <
> lsr@ietf.org>
> *Subject:* Re: [Lsr] Flooding Topology Computation Algorithm -
> draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
>
> Huaimo
>
> This is a much needed feature that operators have been needing for densely
> meshed topologies that commonly exist in data centers to accommodate very
> high bandwidth E-W traffic.
> [HC]: Thank you very much.
>
> Below is link from Cisco which has introduced feature for dynamic flooding
> in clos high density ECMP data center topologies.
>
> Please look at the feature description and it does seem to be exactly the
> same as this draft.  Please confirm.
> [HC]: It seems different.
>
> There maybe other vendors due to industry demand have to get the feature
> deployed before it reaches standards vendor consensus with the IETF.
>
>
> https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-743015.html
> 
>
> We are testing this feature and planning to deploy but wanted to ensure
> that this is the same as the draft on the standards track.
> [HC]: The feature appears implemented draft "Dynamic Flooding on Dense
> Graphs", which does not include any flooding topology computation
> algorithm.
>

Gyan> How does this draft compare to the WG LC draft for flood
reduction.  Would they be two eventual standard options in the operators
toolbox  or competing features for optimized flood reduction. Would having
two flood reduction features standardized versus one default IGP flood
reduction feature be confusing for operators.  Just as it was confusing to
me.


https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/

>
> Kind regards
>
> Gyan
>
>
> On Tue, May 19, 2020 at 11:52 PM Huaimo Chen 
> wrote:
>
> Hi Gyan,
>
> Thank you very much for your questions and support.
>
> This Flooding Topology Computation algorithm can be used in the Dynamic
> Flooding on Dense Graphs to compute the flooding topologies for the data
> center clos dense meshed topologies with many ECMP paths. It can be used by
> the area leader in the centralized mode to compute the flooding topology.
>
> Best Regards,
> Huaimo
> --
> *From:* Lsr  on behalf of Gyan Mishra <
> hayabusa...@gmail.com>
> *Sent:* Tuesday, May 19, 2020 2:39 AM
> *To:* Yanhe Fan 
> *Cc:* lsr@ietf.org ; Acee Lindem (acee)  40cisco@dmarc.ietf.org>
> *Subject:* Re: [Lsr] Flooding Topology Computation Algorithm -
> draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
>
>
> I support WG adoption and have a few questions related to the draft.
>
> Does this flooding algorithm use the dynamic flooding algorithm used in
> data center clos dense meshed topologies with many ECMP paths where the
> flood is decoupled from the physical topology.  In the dynamic flooding
> algorithm mentioned in centralized mode the flooding is computed by the
> area leader and distributed to all nodes.  In distributed mode each mode
> the area leader determines the algorithm and then each node computes the
> flooding topology based on the algorithm.
>
> This dynamic algorithm for optimized flood reduction would reduce the
> amount of redundant flooding in highly densely meshed ospf or Isis
> topologies.  So this optimization of flooding would improving overall link
> state routing protocol convergence.
>
> Gyan
>
> On Mon, May 18, 2020 at 3:37 PM Yanhe Fan  wrote:
>
> Support it as a co-author.
>
>
>
> Thanks,
>
> Yanhe
>
>
>
> *From:* Lsr  *On Behalf Of *Acee Lindem (acee)
> *Sent:* Friday, May 15, 2020 3:40 PM
> *To:* lsr@ietf.org
> *Subject:* [Lsr] Flooding Topology Computation Algorithm -
> draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
>
>
>
> This begins a 3 week (due to holidays) WG adoption call for the “Flooding
> Topology Computation Algorithm” draft. Please issue your support or
> objection to this list by 11:59 PM, UTC on June 5th, 2020. Here is a URL
> for your convenience.
>
>
>
> https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/
> 

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Xufeng Liu]

Support as a co-author.
Thanks,
- Xufeng

On Fri, May 15, 2020 at 3:40 PM Acee Lindem (acee)  wrote:

> This begins a 3 week (due to holidays) WG adoption call for the “Flooding
> Topology Computation Algorithm” draft. Please issue your support or
> objection to this list by 11:59 PM, UTC on June 5th, 2020. Here is a URL
> for your convenience.
>
>
>
> https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/
>
>
>
> Thanks,
> 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] Alissa Cooper's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)

[Alissa Cooper]

Thanks!
Alissa

> On May 21, 2020, at 3:51 AM, Peter Psenak  wrote:
> 
> Hi Alissa,
> 
> On 20/05/2020 21:57, Alissa Cooper via Datatracker wrote:
>> Alissa Cooper has entered the following ballot position for
>> draft-ietf-ospf-mpls-elc-13: 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 IESG DISCUSS and COMMENT positions.
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/
>> --
>> COMMENT:
>> --
>> I wasn't clear on where the  thread ended up from the Gen-ART review, but I'm
>> nevertheless suggesting some text below to resolve the main sticking point.
>> OLD
>> If the router supports ELs on all of its interfaces, it SHOULD advertise the
>> ELC with every local host prefix it advertises in OSPF.
>> NEW
>> If the router supports ELs on all of its interfaces, it SHOULD advertise the
>> ELC with every local host prefix it advertises in OSPF. The absence of these
>> advertisements implies that advertisement of the ELC is not supported.
> 
> I added the suggested text, plus I added "OSPF" at the end. So the text is:
> 
> "If the router supports ELs on all of its interfaces, it SHOULD advertise the 
> ELC with every local host prefix it advertises in OSPF. The absence of these 
> advertisements implies that advertisement of the ELC is not supported in 
> OSPF."
> 
> I added similar text to ISIS ELC draft.
> 
> thanks,
> Peter
> 
>> Not sure if that matches the intent though.

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

Re: [Lsr] Tsvart last call review of draft-ietf-isis-te-app-13

[Kyle Rose]

On Thu, May 21, 2020 at 2:28 AM Les Ginsberg (ginsberg) 
wrote:

> > * Update language?
> >
> > There are several places in which it is possible that normative language
> in
> > prior RFCs is revised. For example, in section 6.1, the last paragraph
> states:
> >
> >   New applications which future documents define to make use of the
> >   advertisements defined in this document MUST NOT make use of legacy
> >   advertisements.
> >
> > This looks like it was written in such a way as to avoid requiring such
> > updates, but it would be good to confirm that there is no normative
> language
> > in
> > older documents that would conflict with this requirement.
> >
> [Les:] For applications which preexisted the writing of this draft (the
> ones defined in Section 7.4) there are existing deployments which use
> legacy advertisements.
> Transitioning to use new advertisements has to account for partial
> deployment of such support.
> And the transition has to be managed by the network operator using knobs
> provided by implementations. This is onerous - but unavoidable in these
> cases.
>
> For new applications we want to avoid this complexity/pain. So we specify
> new applications MUST use the new advertisements from day ONE.
>
> As these are new applications there is no legacy to deal with and no
> existing specification which would be in conflict.
>

That's what I figured. Is it the case that new standardized applications
require an RFC? If so, I think this is fine.


> > * Encoding
> >
> > In section 4.1, the bit masks are defined with a 7 bit length field for
> which
> > only 4 bits are useful (values 0-8). It may make sense to keep the 3
> high order
> > bits as "reserved" and set to zero, but either way it would be nice to
> > understand the justification for whatever design decision is made.
> >
> > You go to some length to save space (e.g., a zero-length SABM means "all
> > applications") but always include an octet for UDABM length, which I
> > presume
> > will be zero outside the lab in most cases. How much does an extra octet
> > cost?
> > If it's a lot, you could use the three high-order bits to represent the
> first
> > three applications (RSVP-TE, SRTE, and LFA) and save yourself an octet
> until a
> > fourth application appears.
> >
> > For that matter, how likely are you to get to 256 standardized
> applications
> > under IS-IS?
> >
> [Les:] The limitation for the xABM length to be no more than 8 bytes was
> introduced only recently based on a review comment.
> The concern was that without a limit, it would be theoretically possible
> for the ABM itself to consume the full sub-TLV space, leaving no room for
> the actual link attribute advertisements.
> So we placed a maximum length to avoid this potential issue.
> As each application consumes one bit, with an 8 byte maximum length we can
> support 64 applications.
>
Sigh... yes, math is hard.


> This seems more than we will ever get to - but if anyone in the WG thinks
> this is not large enough they should speak now so we can increase the
> maximum.
>

I suspect even 64 is safely more than you'll need, but if not there's
always the possibility of a new TLV later on. :-)


> There are existing implementations of this draft which have been deployed.
> Changing the bit positions as you suggested would not be backwards
> compatible.
> I do not think the small space savings would be worth the trouble.
>

Understood, though I will point out that this illustrates the potential
harm in deploying something hard to change prior to standardization.
Thankfully, IS-IS is not interdomain, meaning that any such change would
impose costs only on those who deployed early.

> > In effect, use of legacy advertisements vs. app-specific advertisements
> is
> > all-or-nothing. If that's the case, wouldn't a top-level TLV specifying a
> > legacy mask for applications be more compact, less redundant, and further
> > reduce the overall number/size of advertisements?
> >
> [Les:] The information being advertised here (link attributes) is
> necessarily associated with a top level TLV describing a link to a neighbor
> (TLVs 22, 23, 25, 141, 222, and 223) . Without that context the link
> attribute information is meaningless.
>

Yes, this makes sense, and probably would have been obvious were I more
familiar with IS-IS and link state routing in general.
Thanks,
Kyle
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)

[Peter Psenak]

Hi Alvaro,

On 21/05/2020 13:44, Alvaro Retana wrote:

On May 21, 2020 at 6:05:41 AM, Peter Psenak wrote:


Peter:

Hi!



--
DISCUSS:
--

As for other reviewers, many of my comments duplicate those for the OSPF
document; I expect that the analogous responses apply and am fine if
they only appear for one document's review.

Here, the question I have about normative language applies to the text
in Section 3:

When a router propagates a prefix between ISIS levels ([RFC5302], it
MUST preserve the ELC signaling for this prefix.

The scenario in question is analogous to the OSPF cross-area case: is
the router propagating the prefix between ISIS levels required to
implement this document; is preservation of the flag value a new
requirement from this document vs. a preexisting property; and is this
document trying to make normative requirements of devices that don't
implement this document?


##PP
this is a new requirement and only applies to the routers that support
this document. We are not making normative requirements of devices that
don't implement this document, we cannot.

Maybe we can add that it only applies to the routers that supports this
extension:

"When a router supporting this extension propagates a prefix between
ISIS levels ([RFC5302], it MUST preserve the ELC signaling for this prefix."

Would it work?



You're right, we can only apply requirements to routers that support
this specification.  IOW, adding the clarification is not necessary.


My interpretation of Ben's question is two-fold:

(1) Would ISIS routers normally propagate the information to a
different level?  The ELC is a new prefix attribute flag -- are prefix
attributes always propagated (unchanged) to other levels?  If so, then
the requirement (MUST) is not needed.  My reading of rfc7794 is that
the propagation is optional...


depends on the attribute or a bit. Some are propagated some are not. 
That's why we are saying this one MUST be preserved.




(2) If the propagation is not automatic, and the L1L2 router doesn't
support this specification, then what are the drawbacks/failure
scenarios?  IOW, for multi-level operation is it a requirement that
the L1L2 support this specification?


drawback are identical to what is mentioned in the Security 
Considerations section.


thanks,
Peter





Thanks!

Alvaro.




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

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)

[Alvaro Retana]

On May 21, 2020 at 6:05:41 AM, Peter Psenak wrote:


Peter:

Hi!


> > --
> > DISCUSS:
> > --
> >
> > As for other reviewers, many of my comments duplicate those for the OSPF
> > document; I expect that the analogous responses apply and am fine if
> > they only appear for one document's review.
> >
> > Here, the question I have about normative language applies to the text
> > in Section 3:
> >
> > When a router propagates a prefix between ISIS levels ([RFC5302], it
> > MUST preserve the ELC signaling for this prefix.
> >
> > The scenario in question is analogous to the OSPF cross-area case: is
> > the router propagating the prefix between ISIS levels required to
> > implement this document; is preservation of the flag value a new
> > requirement from this document vs. a preexisting property; and is this
> > document trying to make normative requirements of devices that don't
> > implement this document?
>
> ##PP
> this is a new requirement and only applies to the routers that support
> this document. We are not making normative requirements of devices that
> don't implement this document, we cannot.
>
> Maybe we can add that it only applies to the routers that supports this
> extension:
>
> "When a router supporting this extension propagates a prefix between
> ISIS levels ([RFC5302], it MUST preserve the ELC signaling for this prefix."
>
> Would it work?


You're right, we can only apply requirements to routers that support
this specification.  IOW, adding the clarification is not necessary.


My interpretation of Ben's question is two-fold:

(1) Would ISIS routers normally propagate the information to a
different level?  The ELC is a new prefix attribute flag -- are prefix
attributes always propagated (unchanged) to other levels?  If so, then
the requirement (MUST) is not needed.  My reading of rfc7794 is that
the propagation is optional...

(2) If the propagation is not automatic, and the L1L2 router doesn't
support this specification, then what are the drawbacks/failure
scenarios?  IOW, for multi-level operation is it a requirement that
the L1L2 support this specification?


Thanks!

Alvaro.

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

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-mpls-elc-13: (with DISCUSS and COMMENT)

[Peter Psenak]

Hi Benjamin,

thanks for review.

Please see inline (##PP) two responses to OSPF specific comments.


On 20/05/2020 00:43, Benjamin Kaduk via Datatracker wrote:

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ospf-mpls-elc-13: 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 IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/



--
DISCUSS:
--

I have a question about the scope of some normative language, which may
or may not be problematic but I'm too ignorant of OSPF details to be
able to answer myself.  In Section 3 we say that:

When an OSPF Area Border Router (ABR) distributes information between
connected areas it MUST preserve the ELC setting.

My undesrtanding is that it's normal operation for an ABR to
distribution information about prefixes and such between areas, and in
particular that an ABR does not necessarily need to know the semantic
details of every bit of information being distributed in that fashion.
So, I am imagining a scenario where some routers in both areas
advertise/understand the ELC flag but the ABR between them does not
implement this spec.  What would happen in such a scenario?  If the ABR
is still expected to distribute the ELC setting without change, isn't
that just a core requirement from the respective OSPF specs, as opposed
to a new requirement imposed by this spec (which, in this scenario, the
ABR is not claiming to adhere to anyway)?

There is perhaps a similar question about the ASBR guidance, though when
doing cross-protocol signalling there is a more clear need for the ASBR
to understand the semantics of the flags it is redistributing (and it's
only a "SHOULD").


--
COMMENT:
--

Section 1

The abstract is pretty explicit that "this draft defines" both ELC and
ERLD signaling capabilities, but this section only has a clear statement
for the ELC.  Should we put something at the end of the last paragraph
about "this document defines a mechanism to signal the ERLD using OSPFv2
and OSPFv3"?


##PP
this has been already addressed based on previous comments. Latest text 
is as follows:


"Multiprotocol Label Switching (MPLS) has defined a mechanism to 
load-balance traffic flows using Entropy Labels (EL). An ingress Label
Switching Router (LSR) cannot insert ELs for packets going into a given 
Label Switched Path (LSP) unless an egress LSR has indicated via 
signaling that it has the capability to process ELs, referred to as the 
Entropy Label Capability (ELC), on that LSP. In addition, it would be 
useful for ingress LSRs to know each LSR's capability for reading the 
maximum label stack depth and performing EL-based load-balancing, 
referred to as Entropy Readable Label Depth (ERLD). This document 
defines a mechanism to signal these two capabilities using OSPFv2 and 
OSPFv3 and BGP-LS."


In cases where LSPs are used (e.g., SR-MPLS [RFC8660], it would be

side note(?): I don't know that SR-MPLS is so popular so as to be
privileged as the only example given for LSP usage.  If we instead
talked about using IGPs to signal labels, this selection would seem less
surprising to me.

Section 3

If the router supports ELs on all of its interfaces, it SHOULD
advertise the ELC with every local host prefix it advertises in OSPF.

Do we want to say anything about (not) advertising the ELC for other
prefixes?

Section 7

Should we say anything about considerations for redistributing ELC/ERLD
information at the ASBR with respect to exposing "internal information"
to external parties?

This document specifies the ability to advertise additional node
capabilities using OSPF and BGP-LS.  As such, the security
considerations as described in [RFC5340], [RFC7770], [RFC7752],
[RFC7684], [RFC8476], [RFC8662],

RFC 8662's security considerations have a pretty hard dependency on RFC
6790's security considerations; it might be worth mentioning 6790
directly in this list as well.

[I-D.ietf-idr-bgp-ls-segment-routing-ext] and
[I-D.ietf-idr-bgp-ls-segment-routing-msd] are applicable to this
document.

Could we also have a brief note that the (respective) OSPF security
mechanisms serve to protect the ELC/ERLD information?

Incorrectly setting the E flag during origination, propagation or
redistribution may lead to black-holing of the traffic on the egress
node.

This is what happens when the E flag shoul

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)

[Peter Psenak]

Benjamin,

thanks for review, please see inline (##PP):

On 20/05/2020 00:44, Benjamin Kaduk via Datatracker wrote:

Benjamin Kaduk has entered the following ballot position for
draft-ietf-isis-mpls-elc-12: 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 IESG DISCUSS and COMMENT positions.


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



--
DISCUSS:
--

As for other reviewers, many of my comments duplicate those for the OSPF
document; I expect that the analogous responses apply and am fine if
they only appear for one document's review.

Here, the question I have about normative language applies to the text
in Section 3:

When a router propagates a prefix between ISIS levels ([RFC5302], it
MUST preserve the ELC signaling for this prefix.

The scenario in question is analogous to the OSPF cross-area case: is
the router propagating the prefix between ISIS levels required to
implement this document; is preservation of the flag value a new
requirement from this document vs. a preexisting property; and is this
document trying to make normative requirements of devices that don't
implement this document?


##PP
this is a new requirement and only applies to the routers that support 
this document. We are not making normative requirements of devices that 
don't implement this document, we cannot.


Maybe we can add that it only applies to the routers that supports this 
extension:


"When a router supporting this extension propagates a prefix between 
ISIS levels ([RFC5302], it MUST preserve the ELC signaling for this prefix."


Would it work?




Likewise, the ASBR case for cross-protocol redistribution seems to
rather inherently require understanding the semantics of the flags being
translated.


similarly to the above I can chnage to:

"When a router supporting this extension redistribute a prefix ..."





--
COMMENT:
--

Section 1

Should we add a sentence at the end of the last paragraph about how
"this document defines a mechanism to signal the ERLD using IS-IS"?


not sure I understand, how is described in the body of the document.



In cases where LSPs are used (e.g., SR-MPLS [RFC8660], it would be

side note(?): I don't know that SR-MPLS is so popular so as to be
privileged as the only example given for LSP usage.  If we instead
talked about using IGPs to signal labels, this selection would seem less
surprising to me.


this document describes the ELC/ERLD capability signaling for SR MPLS. 
For non SR MPLS cases, thee are existing mechanisms to learn ELC/ERLD.


I can replace the text with:

"In cases where SR is used with the MPLS Data Plane"

Would it work?




Section 3

unless all of its interfaces are capable of processing ELs.  If a
router supports ELs on all of its interfaces, it SHOULD set the ELC
for every local host prefix it advertises in IS-IS.

Do we want to say anything about (not) advertising the ELC for other
prefixes?


Do we have to? I can add "MUST NOT set ELC with for any other prefix", 
but I find it unneeded.




Section 4

I agree with Roman's comment about code 2 vs TBD2.


that has been fixed already.



ERLD in the range between 0 to 255.  The scope of the advertisement
depends on the application.  If a router has multiple interfaces with

Just to check: w.r.t. "scope", both this document and the OSPF one only
define usage of this MSD type at the scope of a single node, right?  (I
don't see a particular reason to preclude using it at a different
scope.)


the scope here means where the information will be flooded - area only 
or network wide. No such thing as a node scope.





Section 6

   - Bit 3 in the Bit Values for Prefix Attribute Flags Sub-TLV
   registry has been assigned to the ELC Flag.  IANA is asked to

Is there an "IS-IS" in the name of this registry?


no the registry name is "Bit Values for Prefix Attribute Flags Sub-TLV".




Section 7

Should we say anything about considerations for redistributing ELC/ERLD
information at the ASBR with respect to exposing "internal information"
to external parties?


why would this be "internal information" and why redistribution would be 
"external party"? Redistribution between IGPs is predominantly done 
between IGPs under same administrative domain.





This document specifies the ability to advertise additional node
capabilities using IS-IS and BGP-LS.  As such, the security
consideration

Re: [Lsr] Alissa Cooper's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)

[Peter Psenak]

Hi Alissa,

On 20/05/2020 21:57, Alissa Cooper via Datatracker wrote:

Alissa Cooper has entered the following ballot position for
draft-ietf-ospf-mpls-elc-13: 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 IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/



--
COMMENT:
--

I wasn't clear on where the  thread ended up from the Gen-ART review, but I'm
nevertheless suggesting some text below to resolve the main sticking point.

OLD
If the router supports ELs on all of its interfaces, it SHOULD advertise the
ELC with every local host prefix it advertises in OSPF.

NEW
If the router supports ELs on all of its interfaces, it SHOULD advertise the
ELC with every local host prefix it advertises in OSPF. The absence of these
advertisements implies that advertisement of the ELC is not supported.


I added the suggested text, plus I added "OSPF" at the end. So the text is:

"If the router supports ELs on all of its interfaces, it SHOULD 
advertise the ELC with every local host prefix it advertises in OSPF. 
The absence of these advertisements implies that advertisement of the 
ELC is not supported in OSPF."


I added similar text to ISIS ELC draft.

thanks,
Peter



Not sure if that matches the intent though.







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