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

[Gyan Mishra]

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

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

Kind regards

Gyan

On Sat, May 9, 2020 at 9:25 PM Wang, Weibin (NSB - CN/Shanghai) <
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) <
> weibin.w...@nokia-sbell.com> 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  *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] Genart last call review of draft-ietf-ospf-mpls-elc-13

[elwynd]

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.- 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.- Given that 
there are now two sets of prefixes, would/SHOULD/MUST ELC be advertised with 
the 
  prefixes that are not local host prefixes?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.  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. Regards,ElwynSent 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] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 IPR Poll

[tony . li]

> On May 15, 2020, at 12:47 PM, Acee Lindem (acee) 
>  wrote:
> 
> If you are on the LSR WG email list but are not listed as an author or
> contributor, then please explicitly respond only if you are aware of
> any IPR that has not yet been disclosed in conformance with IETF rules.
>  


Hi,

Our IPR disclosure for dynamic flooding (https://datatracker.ietf.org/ipr/4044/ 
) may also apply to this draft.

I am not a lawyer and I don’t play one on this mailing list, either.

Regards,
Tony

___
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 IPR Poll

[Yanhe Fan]

I’m not aware of any IPR that applies to draft-cc-lsr-flooding-reduction-08.txt.

Thanks,
Yanhe

From: Acee Lindem (acee) 
Sent: Friday, May 15, 2020 3:47 PM
To: draft-cc-lsr-flooding-reduct...@ietf.org
Cc: lsr@ietf.org
Subject: Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 IPR Poll

Authors,

Are you aware of any IPR that applies to draft-cc-lsr-flooding-reduction-08.txt.

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee
___
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

[Yanhe Fan]

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

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 IPR Poll

[Xufeng Liu]

I am not aware of any IPR that has not yet been disclosed.

Thanks,

- Xufeng

On Mon, May 18, 2020 at 3:32 AM Aijun Wang 
wrote:

> Hi, Acee:
>
>
>
> I am not aware of any IPR that applies to
> draft-cc-lsr-flooding-reduction-08.txt.
>
>
>
>
>
> Best Regards.
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *发件人:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *代表 *Acee
> Lindem (acee)
> *发送时间:* 2020年5月16日 3:47
> *收件人:* draft-cc-lsr-flooding-reduct...@ietf.org
> *抄送:* lsr@ietf.org
> *主题:* [Lsr] Flooding Topology Computation Algorithm -
> draft-cc-lsr-flooding-reduction-08 IPR Poll
>
>
>
> Authors,
>
>
>
> Are you aware of any IPR that applies
> to draft-cc-lsr-flooding-reduction-08.txt.
>
>
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules
>
> (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as a document author or contributor please respond
>
> to this email regardless of whether or not you are aware of any
>
> relevant IPR. *The response needs to be sent to the LSR WG mailing
>
> list.* The document will not advance to the next stage until a
>
> response has been received from each author and contributor.
>
>
>
> If you are on the LSR WG email list but are not listed as an author or
>
> contributor, then please explicitly respond only if you are aware of
>
> any IPR that has not yet been disclosed in conformance with IETF rules.
>
>
>
> Thanks,
>
> Acee
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] I-D Action: draft-ietf-isis-te-app-13.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   : IS-IS TE Attributes per application
Authors : Les Ginsberg
  Peter Psenak
  Stefano Previdi
  Wim Henderickx
  John Drake
Filename: draft-ietf-isis-te-app-13.txt
Pages   : 21
Date: 2020-05-18

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
   which address both of these shortcomings.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-isis-te-app/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-isis-te-app-13
https://datatracker.ietf.org/doc/html/draft-ietf-isis-te-app-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-te-app-13


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

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


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

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

[Peter Psenak]

Hi Erik,

please see inline:


On 17/05/2020 06:36, Erik Kline via Datatracker wrote:

Erik Kline 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:
--

[[ nits ]]

[ section 1 ]
* "(e.g., SR-MPLS" is missing a closing parenthesis


yes, this has been fixed as a response to previous comments.



[ section 3 ]
* "...unless all of its interfaces...":" do management interfaces, or other
   interfaces over which no forwarding is taking place, count in this definition
   of "all"?  


no, only those over which forwarding happens should be considered.



If not, does this text need to be tightened or is this just one
   of those things all implementers will naturally figure out? (I'm actually
   betting this is just something readers will intuit.)


I would think so. It's kind of obvious that one would not take into 
consideration interfaces like loopback or other types over which real 
forwarding does not happen. The original text used line-cards instead of 
interfaces, but that was changed to interfaces based on comments from 
Alvaro.


If you insist, I can add a text to exclude the "non forwarding" 
interfaces, but I can see more questions coming in as a result :)


thanks,
Peter









___
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

[Qin Wu]

Support this work.

-Qin
发件人: lsr-boun...@ietf.org 
[mailto:lsr-boun...@ietf.org] 代表 Acee Lindem (acee)
发送时间: 2020年5月16日 3:40
收件人: lsr@ietf.org
主题: [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

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

[Aijun Wang]

Yes, support as co-author.

The algorithm is needed for the flooding reduction deployment and should be 
standardized especially in distributed mode.

 

Best Regards.

 

Aijun Wang

China Telecom

 

发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem (acee)
发送时间: 2020年5月16日 3:40
收件人: lsr@ietf.org
主题: [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

[Lsr] 答复: Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 IPR Poll

[Aijun Wang]

Hi, Acee:

 

I am not aware of any IPR that applies to 
draft-cc-lsr-flooding-reduction-08.txt.

 

 

Best Regards.

 

Aijun Wang

China Telecom

 

发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem (acee)
发送时间: 2020年5月16日 3:47
收件人: draft-cc-lsr-flooding-reduct...@ietf.org
抄送: lsr@ietf.org
主题: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 IPR Poll

 

Authors, 

 

Are you aware of any IPR that applies to draft-cc-lsr-flooding-reduction-08.txt.

 

If so, has this IPR been disclosed in compliance with IETF IPR rules 

(see RFCs 3979, 4879, 3669 and 5378 for more details).

 

If you are listed as a document author or contributor please respond

to this email regardless of whether or not you are aware of any

relevant IPR. *The response needs to be sent to the LSR WG mailing

list.* The document will not advance to the next stage until a

response has been received from each author and contributor.

 

If you are on the LSR WG email list but are not listed as an author or

contributor, then please explicitly respond only if you are aware of

any IPR that has not yet been disclosed in conformance with IETF rules.

 

Thanks,

Acee

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