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

[Huaimo Chen]

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 

Sent: Tuesday, May 19, 2020 2:39 AM
To: Yanhe Fan 
Cc: lsr@ietf.org ; Acee Lindem (acee) 

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 
mailto:y...@casa-systems.com>> wrote:

Support it as a co-author.



Thanks,

Yanhe



From: Lsr mailto:lsr-boun...@ietf.org>> 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/



Thanks,
Acee

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

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

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

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

[Benjamin Kaduk via Datatracker]

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?

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


--
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"?

   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

   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?

Section 4

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

   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.)

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?

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 IS-IS and BGP-LS.  As such, the security
   considerations as described in [RFC7981], [RFC7752], [RFC7794],
   [RFC8491], [RFC8662], [I-D.ietf-idr-bgp-ls-segment-routing-ext] and

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-msd] are applicable to this
   document.

Could we also have a brief note that the normal IS-IS authentication
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 should not be set but is
erroneously set.  Should we also say what happens if we should set the E
flag but erroneously clear it (e.g., that poor or no load-balancing may
occur)?

Section 8

I do see the note in the shepherd writeup about the sixth author (thank
you!); if we're already breaking through the 5-author limit, did we
consider making those who "should be considered as co-authors" listed as
co-authors?

Section 10.1

Should we reference RFC 7981 from Section 4 as well?  Right now we seem
to only use it for the security considerations, which is not necessarily
enough to qualify it as a normative reference.



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

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

[Benjamin Kaduk via Datatracker]

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"?

   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 should not be set but is
erroneously set.  Should we also say what happens if we should set the E
flag but erroneously clear it (e.g., that poor or no load-balancing may
occur)?

Section 8

I do see the note in the shepherd writeup about the sixth author (thank
you!); if we're already breaking through the 5-author limit, did we
consider making those who "should be considered as co-authors" listed as
co-authors?

Section 10.2

It's slightly surprising to see the core OSPF protocols only listed as
informative, but I can see how they are to be considered "basic
specifications" in the vein of
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/



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

Re: [Lsr] draft-ietf-lsr-flex-algo

[Gyan Mishra]

On Tue, May 19, 2020 at 3:38 AM Peter Psenak  wrote:

> Gyan,
>
> On 19/05/2020 03:52, Gyan Mishra wrote:
> >
> > Flex algo is usually mentioned in the context of SR-TE to help reduced
> > SRH size to circumvent MSD issues for both SRV6 and SR-MPLS,
>
> though segment list reduction may be seen as one of the benefits of the
> flex-algo, it is certainly not the primary motivation behind it. The
> primary motivation of flex-algo is to provide dynamic any to any
> constrained based routing.
>
> > however can
> > the 0-127 flex algo extensions since it’s an IGP extension used in any
> > pure IP network independent of SR flavors SR-MPLS or SRv6.
>
> SR/SRv6 is used as a dataplane. Any data plane can be used, if it
> provides a way to route an algo specific traffic.
>

Gyan> Please clarify.  I would think that since the flex algo
capability is part of the IGP independent of the data plane is what you are
saying, so any data plane can use the feature.

So you are saying even if it can that their maybe a data plane specific
algo awareness to be able to use or route the algo specific traffic.  So
for example can native IPv4 or IPv6 date plane can it without any specific
algo awareness can it utilitize flex algo constraint based steering.  Also
others mentioned is their special hooks or programming required to make it
work with RSVP-TE or PPR.

>
> >
> > Also can flex algo be used in conjunction with RSVP-TE or PPR(preferred
> > path routing).
>
> same answer as above.
>
> thanks,
> Peter
>
> >
> > Kind regards
> >
> > Gyan
> >
> > On Sat, May 9, 2020 at 9:25 PM Wang, Weibin (NSB - CN/Shanghai)
> > mailto:weibin.w...@nokia-sbell.com>>
> wrote:
> >
> > Jeff, I see what you said, thank you for sharing information;
> >
> > __ __
> >
> > __ __
> >
> > __ __
> >
> > Cheers!
> >
> > 
> >
> > __ __
> >
> > Wang Weibin
> >
> > __ __
> >
> > *From:* Jeff Tantsura  > >
> > *Sent:* 2020年5月10日 3:24
> > *To:* Wang, Weibin (NSB - CN/Shanghai)  > >
> > *Cc:* Ketan Talaulikar (ketant)  > >; lsr@ietf.org 
> > *Subject:* Re: [Lsr] draft-ietf-lsr-flex-algo
> >
> > __ __
> >
> > Weibin,
> >
> > __ __
> >
> > One could have an algo with MSD/ERLD as optimizations constrains,
> > would be quite similar to colored links. Note - ERLD has implemented
> > node capabilities only, so all links on a node will have to be
> > pruned.
> >
> > The tradeoffs are - having centralized controller with global view
> > computing a path that meets the constraints(classical BGP-LS + PCEP
> > scenario) vs building a dynamic topology of connected nodes that
> > meet a set of constrains, in first case, change in
> > topology/capabilities would cause path recalculation/reoptimization
> > on the PCE while in the second - IGP would recompute the topology
> > locally.
> >
> > __ __
> >
> > Regards,
> >
> > Jeff
> >
> >
> >
> > 
> >
> > On May 9, 2020, at 01:27, Wang, Weibin (NSB - CN/Shanghai)
> >  > > wrote:
> >
> > 
> >
> > Ketan, thank you for clarification.
> >
> > 
> >
> > 
> >
> > 
> >
> > Cheers!
> >
> > 
> >
> > Wang Weibin
> >
> > 
> >
> > *From:* Ketan Talaulikar (ketant)  > >
> > *Sent:* 2020年5月9日 14:52
> > *To:* Wang, Weibin (NSB - CN/Shanghai)
> >  > >; lsr@ietf.org
> > 
> > *Subject:* RE: draft-ietf-lsr-flex-algo
> >
> > 
> >
> > Hi Wang,
> >
> > 
> >
> > You are correct. Though I wouldn’t call it a goal but rather a
> > benefit/advantage – same applies to SR-MPLS where the label
> > stack can be reduced.
> >
> > 
> >
> > Thanks,
> >
> > Ketan
> >
> > 
> >
> > *From:* Lsr mailto:lsr-boun...@ietf.org>>
> > *On Behalf Of *Wang, Weibin (NSB - CN/Shanghai)
> > *Sent:* 08 May 2020 19:07
> > *To:* lsr@ietf.org 
> > *Subject:* [Lsr] draft-ietf-lsr-flex-algo
> >
> > 
> >
> > Hi authors:
> >
> > 
> >
> > After reading through this draft lsr-flex-algo, I want to know
> > whether there is a potential goal of this draft to reduce the
> > SRH size with enabling flex-algo with admin group in SRv6
> > deployment, because without flex-algo we have to have a big SRH
> > size when the SRH include more SRv6 SIDs, if we enable flex-algo
> > under special topology and link constraint condition, in theory
> 

[Lsr] Roman Danyliw's No Objection on draft-ietf-isis-mpls-elc-12: (with COMMENT)

[Roman Danyliw via Datatracker]

Roman Danyliw has entered the following ballot position for
draft-ietf-isis-mpls-elc-12: 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-isis-mpls-elc/



--
COMMENT:
--

Two editorial nits:
** Section 3.  Editorial.  s/ When a router propagates a prefix between ISIS
levels ([RFC5302],/When a router propagates a prefix between ISIS levels
[RFC5302],/

** Section 4.  Figure 2.  The text says that “A MSD-Type Code 2 has been
assigned by IANA”, but Figure 2 says “MSD-Type=TBD2”.



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

Re: [Lsr] Robert Wilton's No Objection on draft-ietf-isis-mpls-elc-12: (with COMMENT)

[Rob Wilton (rwilton)]

Hi Acee,

Do you think that it would be helpful to have an informative reference to 
https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1?  And 
possibly a comment somewhere in the draft to specify where the manageability 
model will be specified?

The same comment obviously applies to the OSPF draft also ...

Regards,
Rob



-Original Message-
From: Acee Lindem (acee)  
Sent: 19 May 2020 12:17
To: Rob Wilton (rwilton) ; The IESG 
Cc: draft-ietf-isis-mpls-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; 
aretana.i...@gmail.com
Subject: Re: Robert Wilton's No Objection on draft-ietf-isis-mpls-elc-12: (with 
COMMENT)

Hi Rob, 

On 5/19/20, 6:00 AM, "Robert Wilton via Datatracker"  wrote:

Robert Wilton has entered the following ballot position for
draft-ietf-isis-mpls-elc-12: 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-isis-mpls-elc/



--
COMMENT:
--

Hi,

Same comment as for equivalent OSPF draft.

Is there any associated YANG module required to manage this protocol
enhancement?  If so, is that already being worked or, or planned work for 
the
WG?

We will add the necessary IS-IS encodings to this module - 
https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/

Thanks,
Acee

Regards,
Rob




___
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

[Linda Dunbar]

Support the WG Adoption.

Linda Dunbar

From: Lsr mailto:lsr-boun...@ietf.org>> 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/

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

Re: [Lsr] [Gen-art] Genart last call review of draft-ietf-isis-mpls-elc-11

[Alissa Cooper]

Mohit, thanks for your review. Acee, thanks for your responses. I entered a No 
Objection ballot.

Alissa


> On Apr 29, 2020, at 7:26 AM, Acee Lindem (acee) 
>  wrote:
> 
> Hi Mohit, 
>  
> From: Mohit Sethi M  >
> Date: Wednesday, April 29, 2020 at 2:29 AM
> To: Acee Lindem mailto:a...@cisco.com>>, "gen-...@ietf.org 
> " mailto:gen-...@ietf.org>>
> Cc: "lsr@ietf.org "  >, "draft-ietf-isis-mpls-elc@ietf.org 
> " 
>  >, "last-c...@ietf.org 
> " mailto:last-c...@ietf.org>>
> Subject: Re: Genart last call review of draft-ietf-isis-mpls-elc-11
>  
> HI Acee,
> 
> On 4/24/20 3:38 PM, Acee Lindem (acee) wrote:
>> Hi Mohit,
>>  
>> Speaking as document shepherd. See inline. 
>>  
>> On 4/24/20, 3:39 AM, "Mohit Sethi via Datatracker"  
>>  wrote:
>>  
>> Reviewer: Mohit Sethi
>> Review result: Ready with Nits
>>  
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>>  
>> For more information, please see the FAQ at
>>  
>>  
>> .
>>  
>> Document: draft-ietf-isis-mpls-elc-11
>> Reviewer: Mohit Sethi
>> Review Date: 2020-04-24
>> IETF LC End Date: 2020-05-05
>> IESG Telechat date: Not scheduled for a telechat
>>  
>> Summary: This document specifies how Entropy Label Capability (ELC) and 
>> Entropy
>> Readable Label Depth (ERLD) are advertised using IS-IS. For advertising 
>> ELC, a
>> flag in the Prefix Attribute Flags is used. For advertising ERLD, a Node 
>> MSD
>> Advertisement is used.
>>  
>> Major issues:
>>  
>> Minor issues: The document is short and straightforward. For someone 
>> like me
>> who is not familiar with the routing area, would it make sense to 
>> explain why
>> signalling ELC information with MPLS is not sufficient (or what are the
>> benefits of advertising with IS-IS)?
>>  
>> I guess I'm wondering what you mean "signaling ELC information with MPLS"? 
>> With segment routing, the IGPs can be the only choice for signaling ELC 
>> capability. I don’t believe this comment requires any action. 
> I hope that you don't expect a gen-art reviewer to be an expert on every 
> topic. I certainly am NOT on expert on routing. I interpreted the following 
> text in the draft:
> 
>> It also
>>introduces the concept of Entropy Label Capability (ELC) and defines
>>the signaling of this capability via MPLS signaling protocols.
> to imply that signaling ELC information with MPLS is possible but this draft 
> defines a mechanism for signaling the same information with IS-IS. Maybe the 
> need for this is very obvious for those in the routing domain in which case 
> ignoring my comment is perfectly fine. 
>  
> Even though you are not an expert on routing, you should realize that “with 
> MPLS” and “via MPLS signaling protocols” have very different connotations. If 
> you reference section 3 of the reference document [RFC6790], you’ll the MPLS 
> signaling protocols currently supporting ELC signaling. As I stated 
> previously, with segment routing none of these protocols are required for 
> deployment.
>  
> Thanks,
> Acee
> --Mohit
> 
>>  
>> Thanks,
>> Acee
>>  
>>  
>> Nits/editorial comments:
>>  
>> In section 3, "used as the ECL  Flag" should perhaps be "used as the ELC 
>> Flag"?
>> In section 4, "IANA for EARLD-MSD" should perhaps be "IANA for ERLD-MSD"?
>> In section 6, "ECL Flag (E-flag)." should perhaps be "ELC Flag 
>> (E-flag)."?
>>  
>>  
>>  
> ___
> Gen-art mailing list
> gen-...@ietf.org 
> https://www.ietf.org/mailman/listinfo/gen-art 
> 

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

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

[Acee Lindem (acee)]

H Rob, 

On 5/19/20, 5:59 AM, "Robert Wilton via Datatracker"  wrote:

Robert Wilton 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:
--

Hi,

This is a straight forward document, thanks.

Is there any associated YANG module required to manage this protocol
enhancement?  If so, is that already being worked or, or planned work for 
the
WG?
We will add the necessary encoding to this module - 
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/

Thanks,
Acee

Regards,
Rob




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

Re: [Lsr] Robert Wilton's No Objection on draft-ietf-isis-mpls-elc-12: (with COMMENT)

[Acee Lindem (acee)]

Hi Rob, 

On 5/19/20, 6:00 AM, "Robert Wilton via Datatracker"  wrote:

Robert Wilton has entered the following ballot position for
draft-ietf-isis-mpls-elc-12: 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-isis-mpls-elc/



--
COMMENT:
--

Hi,

Same comment as for equivalent OSPF draft.

Is there any associated YANG module required to manage this protocol
enhancement?  If so, is that already being worked or, or planned work for 
the
WG?

We will add the necessary IS-IS encodings to this module - 
https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/

Thanks,
Acee

Regards,
Rob




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

[Lsr] Robert Wilton's No Objection on draft-ietf-isis-mpls-elc-12: (with COMMENT)

[Robert Wilton via Datatracker]

Robert Wilton has entered the following ballot position for
draft-ietf-isis-mpls-elc-12: 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-isis-mpls-elc/



--
COMMENT:
--

Hi,

Same comment as for equivalent OSPF draft.

Is there any associated YANG module required to manage this protocol
enhancement?  If so, is that already being worked or, or planned work for the
WG?

Regards,
Rob



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

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

[Robert Wilton via Datatracker]

Robert Wilton 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:
--

Hi,

This is a straight forward document, thanks.

Is there any associated YANG module required to manage this protocol
enhancement?  If so, is that already being worked or, or planned work for the
WG?

Regards,
Rob



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

[Lsr] I-D Action: draft-ietf-ospf-te-link-attr-reuse-12.txt

[internet-drafts]

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

Title   : OSPF Link Traffic Engineering Attribute Reuse
Authors : Peter Psenak
  Les Ginsberg
  Wim Henderickx
  Jeff Tantsura
  John Drake
Filename: draft-ietf-ospf-te-link-attr-reuse-12.txt
Pages   : 21
Date: 2020-05-19

Abstract:
   Existing traffic engineering related link attribute advertisements
   have been defined and are used in RSVP-TE deployments.  Since the
   original RSVP-TE use case was defined, additional applications (e.g.,
   Segment Routing Traffic Engineering, Loop Free Alternate) have been
   defined which also make use of the link attribute advertisements.  In
   cases where multiple applications wish to make use of these link
   attributes the current advertisements do not support application
   specific values for a given attribute nor do they support indication
   of which applications are using the advertised value for a given
   link.  This document introduces new link attribute advertisements in
   OSPFv2 and OSPFv3 which address both of these shortcomings.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ospf-te-link-attr-reuse-12
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-te-link-attr-reuse-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-te-link-attr-reuse-12


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

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


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

Re: [Lsr] Genart last call review of draft-ietf-ospf-mpls-elc-13

[Peter Psenak]

Elwyn,

On 18/05/2020 23:02, elwynd wrote:

Hi.

I am not convinced by the discussion that has ensued from my review.

s3, para 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.

- Both Acee amd I didn't immediately understand that 'every local host prefix' 
was not every
   prefix that the router might advertise.  It would be good to explain that 
this is the case.


what exactly needs to be explained? The local property of the prefix?



- As I previously stated, with a SHOULD it ought to be explained why one might 
not want to
   advertise the ELC with some subset of the local host prefixes.


SHOUDL is used not to say that one does it for subset of host prefixes, 
but rather because MUST can not be used for reasons mentioned earlier.


From the functionality perspective it is sufficient to advertise it 
with a single local prefix. We specified for "every local prefix" to 
make it simpler.




- Given that there are now two sets of prefixes, would/SHOULD/MUST ELC be 
advertised with the
   prefixes that are not local host prefixes?


no, only with local host prefixes. I can add  "MUST NOT be advertised 
with any other prefix" if that's what you are after.





s4, para 3:

The absence of ERLD-MSD advertisements indicates only that the
advertising node does not support advertisement of this capability.

Firstly, I cannot see why this statement or its absence might affect other EL 
mechanisms that
don't use OSPF to do signaling of ELC.


It does not. All we say that if it is not advertised by OSPF, it means 
the router does not support the advertisement in OSPF. Nothing else. It 
has no effect on any other mechanisms that might be used to derive these 
capabilities.




If I understand RFC 8662 correctly, if OSPF is being used to distribute ELC 
adverts and the ERLD
is not advertised by OSPF, then either the ERLD has to be supplied by other 
means or it will
effectively default to zero.

Thus, I would suggest that the paragraph above should be replaced with:

Advertisement of ERLD via OSPF using ERLD-MSD is OPTIONAL.  If a router 
does not advertise
ERLD, then the EL positioning calculations described in [RFC8662] will 
assume a vaue of zero
for the ERLD of this router unless a different value is supplied by 
alternative means.


I don't think we should be specifying anything that belongs to RFC8662 
here in this draft. What we specify in this draft is how to advertise 
something in OSPF, not how this is being used, because this information 
is not used by OSPF. The usage of this info is outside of the scope of 
this draft and if anything needs to be added in that regard it should be 
done by updating the RFC8662.


regards,
Peter





Regards,

Elwyn

Sent from Samsung tablet.



 Original message 
From: "Acee Lindem (acee)" 
Date: 14/05/2020 21:43 (GMT+00:00)
To: Alvaro Retana , "Peter Psenak (ppsenak)" 
, Elwyn Davies , gen-...@ietf.org

Cc: last-c...@ietf.org, draft-ietf-ospf-mpls-elc@ietf.org, lsr@ietf.org
Subject: Re: Genart last call review of draft-ietf-ospf-mpls-elc-13

Hi Alvaro, Elwyn,

*From: *Alvaro Retana 
*Date: *Thursday, May 14, 2020 at 3:46 PM
*To: *Acee Lindem , "Peter Psenak (ppsenak)" 
, Elwyn Davies , 
"gen-...@ietf.org" 
*Cc: *"last-c...@ietf.org" , 
"draft-ietf-ospf-mpls-elc@ietf.org" 
, "lsr@ietf.org" 

*Subject: *Re: Genart last call review of draft-ietf-ospf-mpls-elc-13

Hi!

Yes, we cannot specify something that routers unaware of this 
specification should or shouldn’t do.


I believe that Elwyn’s point is this: *if a router supports this 
specification* then when would it not advertise the ELC?  IOW, the 
specification only obviously applies to implementations that support it 
— in that case I would think that if a router supports ELs on all of its 
interfaces then it would always advertise the ELC, right?


That’s true – but not advertising the OSPF capability could imply that 
either ELC MSD or advertisement of the OSPF capability is not supported. 
Although I might not have worded it as such, that was clear to me from 
the text. Feel free to recommend alternate text if you feel it is 
necessary.


Thanks,

Acee

Thanks!

Alvaro.

On May 11, 2020 at 3:18:34 PM, Acee Lindem (acee) (a...@cisco.com 
) wrote:


Note that the optionality of ERLD-MSD advertisements appears on
reflection to be a more serious issue than just an editorial nit.

So what would you suggest? There are existing implementations that
support multipath forwarding entropy using MPLS entropy labels but
do not signal that capability in OSPF. We can't have a document that
retroactively mandates that they signal it. This wouldn't be
backward compatible. How can you possibly see this as a serious issue?



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

Re: [Lsr] draft-ietf-lsr-flex-algo

[Peter Psenak]

Gyan,

On 19/05/2020 03:52, Gyan Mishra wrote:


Flex algo is usually mentioned in the context of SR-TE to help reduced 
SRH size to circumvent MSD issues for both SRV6 and SR-MPLS, 


though segment list reduction may be seen as one of the benefits of the 
flex-algo, it is certainly not the primary motivation behind it. The 
primary motivation of flex-algo is to provide dynamic any to any 
constrained based routing.


however can 
the 0-127 flex algo extensions since it’s an IGP extension used in any 
pure IP network independent of SR flavors SR-MPLS or SRv6.


SR/SRv6 is used as a dataplane. Any data plane can be used, if it 
provides a way to route an algo specific traffic.




Also can flex algo be used in conjunction with RSVP-TE or PPR(preferred 
path routing).


same answer as above.

thanks,
Peter



Kind regards

Gyan

On Sat, May 9, 2020 at 9:25 PM Wang, Weibin (NSB - CN/Shanghai) 
mailto:weibin.w...@nokia-sbell.com>> wrote:


Jeff, I see what you said, thank you for sharing information;

__ __

__ __

__ __

Cheers!



__ __

Wang Weibin

__ __

*From:* Jeff Tantsura mailto:jefftant.i...@gmail.com>>
*Sent:* 2020年5月10日 3:24
*To:* Wang, Weibin (NSB - CN/Shanghai) mailto:weibin.w...@nokia-sbell.com>>
*Cc:* Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; lsr@ietf.org 
*Subject:* Re: [Lsr] draft-ietf-lsr-flex-algo

__ __

Weibin,

__ __

One could have an algo with MSD/ERLD as optimizations constrains,
would be quite similar to colored links. Note - ERLD has implemented
node capabilities only, so all links on a node will have to be
pruned.

The tradeoffs are - having centralized controller with global view
computing a path that meets the constraints(classical BGP-LS + PCEP
scenario) vs building a dynamic topology of connected nodes that
meet a set of constrains, in first case, change in
topology/capabilities would cause path recalculation/reoptimization
on the PCE while in the second - IGP would recompute the topology
locally.

__ __

Regards,

Jeff





On May 9, 2020, at 01:27, Wang, Weibin (NSB - CN/Shanghai)
mailto:weibin.w...@nokia-sbell.com>> wrote:



Ketan, thank you for clarification.







Cheers!



Wang Weibin



*From:* Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
*Sent:* 2020年5月9日 14:52
*To:* Wang, Weibin (NSB - CN/Shanghai)
mailto:weibin.w...@nokia-sbell.com>>; lsr@ietf.org

*Subject:* RE: draft-ietf-lsr-flex-algo



Hi Wang,



You are correct. Though I wouldn’t call it a goal but rather a
benefit/advantage – same applies to SR-MPLS where the label
stack can be reduced.



Thanks,

Ketan



*From:* Lsr mailto:lsr-boun...@ietf.org>>
*On Behalf Of *Wang, Weibin (NSB - CN/Shanghai)
*Sent:* 08 May 2020 19:07
*To:* lsr@ietf.org 
*Subject:* [Lsr] draft-ietf-lsr-flex-algo



Hi authors:



After reading through this draft lsr-flex-algo, I want to know
whether there is a potential goal of this draft to reduce the
SRH size with enabling flex-algo with admin group in SRv6
deployment, because without flex-algo we have to have a big SRH
size when the SRH include more SRv6 SIDs, if we enable flex-algo
under special topology and link constraint condition, in theory
we can even construct  a end to end SR path/tunnel without SRH,
but it still meet TE requirement. So my question is whether the
flex-algo can be used as tool to reduce SRH size?







/Cheers !/

**

*WANG Weibin*

___
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

--

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: gyan.s.mis...@verizon.com 





___
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

[Gyan Mishra]

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/
>
>
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Flooding across a network

[Gyan Mishra]

On Mon, May 18, 2020 at 8:42 AM  wrote:

> Hello Gyan,
>
>
>
> Nice to know that fast LSP flooding is important to you.
>
> You are right that there are existing code and knobs to improve IGP
> convergence in general, and in particular to the specific implementation
> you are referring to (I’d bet that its first letter start with C)..
>
> Focusing on efficient flooding, which is the subject of this thread,
> “fast-flood x” is indeed a nice name. AFAIR, the feature has been
> introduced approximately 15 years ago and was indeed an improvement. Many
> more have been introduced as part of the fast IGP convergence project that
> I’d been running in this company, resulting in very significant and much
> needed improvement on that implementation.
>
> Despite the name “fast flood”, I don’t think that anyone is claiming that
> it’s solving the broad issue of efficient LSP flooding.
>
> LSP-pacing may also be configured in order to influence the delay between
> two consecutively sent LSP.
>
>
>
> One question, which you have likely faced when enabling these knobs, is
> the right values to configure, depending on the receiver (’s capability)
>
If you have multiple implementation on the sender side –with different ways
> to implement ‘fast flooding’- and different platforms (‘s capability) on
> the receiver side, combined with various usages (e.g. from 2 to 50 IGP
> adjacencies, with or without BGP/RSVP-TE/multicast….) the matrix is quickly
> getting significant. Your vendor of the receiver implementation may help
> you; or not (significantly).
>
   Gyan> I completely understand the issue and that makes sense that with
the variables thrown out there with a mixed vendor environment with a
variety of platforms and sender flooding capability, and the receiver
receiving the flooded LSP capability to be processed during its local SPF
and overrunning the receivers.  So this is a real world worst case scenario
which can happen with flow control and how to deal with the resulting slow
convergence and sub optimal routing with micro loops. Got it.

Thank you for the explanation.

> With IS-IS, the problem is exacerbated because the protocol is typically
> vital to the network and all its usages and customers. So nobody wants to
> be held accountable if the parameters turned to be ‘non-optimal’ over the
> next decade. Especially as routing ‘incidents’ may already happen with
> default configuration.
>
>  Gyan>  Default change are painful for operators but unfortunately they do
> happen and throw off any tuning or standard template deployed.
>
>
>
> Sending fast is “easy”, but what we need is an effective communication
> between the two entities involved: one sender and a receiver; sometimes
> referred to as goodput. RFC 2914 “Congestion Control Principles” [1] may
> be an introduction to this.
>
> e.g. you can probably speak English to me at 200-250 words per minutes but
> I can assure you that it would be more effective to speak to me at a lower
> rate, because of limitations on the receiver side.
>
> That’s similar for machines in general and IS-IS in particular, especially
> since IS-IS is not that fast to recover from lost LSPs.
>
> The problem is not new and referred to as flow control. From [2] “In data
> communications , *flow
> control* is the process of managing the rate of data transmission between
> two nodes to prevent a fast sender from overwhelming a slow receiver. It
> provides a mechanism for the receiver to control the transmission speed, so
> that the receiving node is not overwhelmed with data from transmitting
> node.”
>
>
>
> That’s what we are working on.
>
>  Gyan>  Makes sense.
>
> Kind regards,
>
> Bruno
>
>
>
> [1] https://tools.ietf.org/html/rfc2914
>
> [2] https://en.wikipedia.org/wiki/Flow_control_(data)
>
>
>
>
>
>
>
> *From:* Gyan Mishra [mailto:hayabusa...@gmail.com]
> *Sent:* Sunday, May 17, 2020 11:07 AM
> *To:* DECRAENE Bruno TGI/OLN
> *Cc:* Christian Hopps; Les Ginsberg (ginsberg); lsr@ietf.org
> *Subject:* Re: [Lsr] Flooding across a network
>
>
>
>
>
> Am reading through this thread late but want to chime in on the discussion.
>
>
>
> Router Isis
>
> fast-flood x
>
>
>
> The concept of ISIS fast flooding has been around for decades and is
> critical for ISIS LSDB synchronization to so all nodes have all prefixes to
> avoid micro loops and within the network.
>
>
>
> The concept of fast flood feature is basically to flood the number of LSPs
> that need to be flooded before starting the local SPF.  So with fast flood
> enabled all nodes in the domain wait till the last LSP is flooded before it
> runs its local SPF.  By fast flooding it reduces the overall number of SPFs
> executed and allows the LSDB to be synchronized by all nodes in the domain.
>
>
>
> Let’s say a link went down or came up topology change.  The router should
> at a minimum flood at least that LSP that triggered the SPF before running
> its local SPF.  Fast flooding is