Re: [Lsr] [IANA #1171772] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04

[Loa Andersson]

Amanda,

Thanks, for the clarification. I have not had to manage code point 
allocation for Expert Review registries and had not looked at 7370.


Small question, if you do the hybrid early allocation and then 6 months 
later the document is  is approved as an RFC is that the time when you

mark the allocations permanent?

/Loa

On 03/06/2020 03:17, Amanda Baber via RT wrote:

Hi Loa, all,

A note about this:


Yeah - you are requesting code points from registries where the
registration procedures are "Expert Review". But those are not early
allocation, they are permanent.


There is a kind of hybrid early allocation/Expert Review procedure for the 
IS-IS Exert Review registries, which is what I understood to be in use here. If 
the experts approve, we mark the registrations as temporary and ask them to 
re-approve a year later. It's described in Section 4 of RFC 7370:

https://tools.ietf.org/html/rfc7370#section-4

thanks,
Amanda

On Tue Jun 02 18:01:21 2020, l...@pi.nu wrote:

Tony,

inline plz.

On 02/06/2020 22:42, Tony Przygienda wrote:

Loa, fair points though I would say adoption is kind of a different
kettle of fish than early allocation.


yeah - but the point I made, modulo some small updates in the IANA
considerations I think the document is ready for wg adoption. And
really the updates in the IANA considerations is strictly not
necessary for wg adoption, but I prefer to have the IANA registries
in scope clearly pointed out.


RFC7120 does not seem to apply given ISIS registries are under expert
review (largely due to historical reasons AFAIS).


Yeah - you are right. I missed that, was to focused on the
requirements
in 7120.


I watch that with lots of interest since due to customer
discussions/(deployment) planning we request with experts early
allocation for
https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-
reflection/


Yeah - you are requesting code points from registries where the
registration procedures are "Expert Review". But those are not early
allocation, they are permanent.


We have however the benefit of not needing any new registries.


Yes, that is a blessing, but for a new registry you can actually
capture
in the draft and populate it with code point values, the only thing is
that once you put a value in there it should not be changed.
Especially
if you know of early implementations.

For your draft the registries should be called:

Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV); and
  Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS
  reachability, IS Neighbor Attribute, L2 Bundle Member Attributes,
  inter-AS reachability information, MT-ISN, and MT IS Neighbor
Attribute
TLVs)

(Don't blame me, I didn't name the registries :) ).


and both registries are found in the IS-IS TLV Codepoints namespace.

/Loa



thanks

-- tony

On Tue, Jun 2, 2020 at 1:00 AM Loa Andersson mailto:l...@pi.nu>> wrote:

Folks,

I have two questions on the early allocation.

RFC 7120 allows early allocation for two types of

     The processes described below assume that the document in
question is
     the product of an IETF Working Group (WG).  If this is not the
case,
     replace "WG chairs" below with "Shepherding Area Director".

draft-li-lsr-isis-area-proxy is an individual document, i.e. not a
product of a working group nor shepherded by an AD, and does not seem
to
meet the criteria for early allocation.

Also. draft-li-lsr-isis-area-proxy request that IANA create a new
registry, as far as I understand new registries can't be created
through
early allocation. It is hardly necessary.

The code points are requested from "the IS-IS TLV Codepoints
registry",
howver the "IS-IS TLV Codepoints" is a name space with 14 different
registries. I think the the registry you want to allocated code point
from the "TLV Codepoints registry"

Since the document, at least I read it, well meet the criteria for
becoming a working document (minor update to the IANA section), I
think
that the easy way out is to start the working group adoption poll.

/Loa


On 02/06/2020 12:52, Tony Li wrote:
  >
  > Hi Amanda,
  >
  >> However, the IANA Considerations section is missing some
information.
  >> How would we fill in the IIH, LSP, SNP, and Purge fields for
  >> the
TLV
  >> Codepoint registrations?
  >
  >
  > We’ve addressed this in
  > https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-06..
  >
  > Thanks,
  > Sarah & Tony
  >
  >
  > ___
  > Lsr mailing list
  > Lsr@ietf.org 
  > https://www.ietf.org/mailman/listinfo/lsr
  >

--

My mail server from time to time has come under DOS attacks,
we are working to fix it but it may take some time. If you
get denial of service sending to me plz try to use
loa.pi.nu@gmail


Loa Andersson                        email: l...@pi.nu

Senior MPLS Expert
Bronze Dragon Consulting      

Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

[wangyali]

Hi Peter,

Please see inline . Thanks.

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Wednesday, June 3, 2020 11:04 PM
To: wangyali ; lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Yali,

On 03/06/2020 15:51, wangyali wrote:
> Hi Peter,
> 
> Thanks for your reply. please see inline .
> 
> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Wednesday, June 3, 2020 7:44 PM
> To: wangyali ; lsr@ietf.org
> Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt
> 
> Yali,
> 
> 
> On 03/06/2020 13:35, wangyali wrote:
>> Hi authors,
>>
>> After reading this draft, I am not clear with following points.
>>
>> First,  as said " Even though ELC is a property of the node, in some cases 
>> it is advantageous to associate and advertise the ELC with a prefix.", what 
>> are "some cases" in which it is advantageous to associate and advertise the 
>> ELC with a prefix? And ELC is a property of the node, why don't extend the 
>> OSPF RI Opaque LSA to carry ELC?
> 
> this has been discussed on the WG alias endlessly, please go over the 
> archives.
>  Thanks. I think I lost some emails. I will search them. While I 
> suggest give an illustration or some examples about the "some cases" in the 
> draft. Please take it into account.

I will not make any changes to the draft at this point. The draft is in the RFC 
queue, too late to make changes.
 Thanks. I am going over the mail archive to find these cases. I am very 
willing to learn and understand key points of this draft. 

> 
>>
>> Second, as said " If a router has multiple interfaces, the router MUST NOT 
>> announce ELC unless all of its interfaces are capable of processing ELs. ", 
>> why do not consider ELC advertisement in link granularity?
> 
> and how do you as a remote router know over which interface, or better line 
> card, the traffic that you are sending going to arrive on a remote node? Does 
> not make much sense.
>  So can we say that ELC advertisement in node granularity is expressed 
> by host prefix attributes advertisement?

yes, pretty much that is the idea.
 I am appreciate if you could summary the reason.

> 
>>
>> Third, as said " If the router supports ELs on all of its interfaces, it 
>> SHOULD advertise the ELC with every local host prefix it advertises in 
>> OSPF.", what is the "every local host prefix"?
> 
> it's a locally generated host prefix.
> 
>>
>> Last one, as defined that ERLD is advertised in a Node MSD TLV, why the 
>> ERLD-MSD type can be received in the OSPFv2 or OSPFv3 Link MSD sub-TLV? " 
>> When the ERLD-MSD type is received in the OSPFv2 or OSPFv3 Link MSD Sub-TLV 
>> [RFC8476], it MUST be ignored."
> 
> yes, what's wrong with that statement?
>  I think it will not happen. Why is it necessary to specify this case?

If someone sends this as link MSD, we need to say how to deal with it as in 
general MSDs can be send as node or link attributes.
 OK. I think I got your point and I read sec.4 again. So ERLD 
advertisement in a Node MSD TLV [RFC8476] is an optional method but not 
mandatory, is it right?

regards,
Peter



> 
> regards,
> Peter
> 
> 
>>
>> Best regards,
>> Yali
>>
>> -Original Message-
>> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
>> Sent: Monday, June 1, 2020 4:42 PM
>> To: i-d-annou...@ietf.org
>> Cc: lsr@ietf.org
>> Subject: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt
>>
>>
>> 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   : Signaling Entropy Label Capability and Entropy 
>> Readable Label Depth Using OSPF
>>   Authors : Xiaohu Xu
>> Sriganesh Kini
>> Peter Psenak
>> Clarence Filsfils
>> Stephane Litkowski
>> Matthew Bocci
>>  Filename: draft-ietf-ospf-mpls-elc-15.txt
>>  Pages   : 9
>>  Date: 2020-06-01
>>
>> Abstract:
>>  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.
>>
>>
>> The IETF datatracker status page for 

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

[Kiran Makhijani]

Support WG adoption.
Regards,
Kiran

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Friday, May 15, 2020 12: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

[Yi Yang]

Hi Acee,


I am not aware of any IPRs applying to draft-cc-lsr-flooding-reduction-08.


Best Regards,


Yi

On 5/15/20 3:47 PM, Acee Lindem (acee) wrote:


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

[Yi Yang]

Support.


Yi

On 5/15/20 3:39 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 5^th , 
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

[Lsr] FW: New Version Notification for draft-chen-lsr-isis-rfc5316bis-02.txt

[Les Ginsberg (ginsberg)]

Folks -

This is a refresh on this draft.

   Les

-Original Message-
From: internet-dra...@ietf.org  
Sent: Wednesday, June 03, 2020 6:56 AM
To: Les Ginsberg (ginsberg) ; Stefano Previdi 
; Mach Chen (Guoyi) ; Mach Chen 
; Xiaodong Duan 
Subject: New Version Notification for draft-chen-lsr-isis-rfc5316bis-02.txt


A new version of I-D, draft-chen-lsr-isis-rfc5316bis-02.txt
has been successfully submitted by Les Ginsberg and posted to the
IETF repository.

Name:   draft-chen-lsr-isis-rfc5316bis
Revision:   02
Title:  ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS 
and GMPLS Traffic Engineering
Document date:  2020-06-03
Group:  Individual Submission
Pages:  20
URL:
https://www.ietf.org/internet-drafts/draft-chen-lsr-isis-rfc5316bis-02.txt
Status: https://datatracker.ietf.org/doc/draft-chen-lsr-isis-rfc5316bis/
Htmlized:   https://tools.ietf.org/html/draft-chen-lsr-isis-rfc5316bis-02
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-chen-lsr-isis-rfc5316bis
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-chen-lsr-isis-rfc5316bis-02

Abstract:
   This document describes extensions to the Intermediate System to
   Intermediate System (IS-IS) protocol to support Multiprotocol Label
   Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
   (TE) for multiple Autonomous Systems (ASs).  It defines IS-IS
   extensions for the flooding of TE information about inter-AS links,
   which can be used to perform inter-AS TE path computation.

   No support for flooding information from within one AS to another AS
   is proposed or defined in this document.

   This document obsoletes RFC 5316.



  


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.

The IETF Secretariat


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

Re: [Lsr] Rtgdir last call review of draft-ietf-ospf-te-link-attr-reuse-12

[Daniele Ceccarelli]

Hi Peter,

Please see in line.

BR
Daniele  

-Original Message-
From: Peter Psenak  
Sent: den 1 juni 2020 12:15
To: Daniele Ceccarelli ; rtg-...@ietf.org
Cc: last-c...@ietf.org; lsr@ietf.org; 
draft-ietf-ospf-te-link-attr-reuse@ietf.org
Subject: Re: Rtgdir last call review of draft-ietf-ospf-te-link-attr-reuse-12

Hi Daniele,

please see inline (##PP)

On 29/05/2020 18:18, Daniele Ceccarelli via Datatracker wrote:
> Reviewer: Daniele Ceccarelli
> Review result: Has Nits
> 
> Hello,
> 
> I have been selected as the Routing Directorate reviewer for this 
> draft. The Routing Directorate seeks to review all routing or 
> routing-related drafts as they pass through IETF last call and IESG 
> review, and sometimes on special request. The purpose of the review is to 
> provide assistance to the Routing ADs.
> For more information about the Routing Directorate, please see 
> ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> 
> Although these comments are primarily for the use of the Routing ADs, 
> it would be helpful if you could consider them along with any other 
> IETF Last Call comments that you receive, and strive to resolve them 
> through discussion or by updating the draft.
> 
> Document: draft-ietf-ospf-te-link-attr-reuse-12
> Reviewer: Daniele Ceccarelli
> Review Date: 2020-05-29
> IETF LC End Date: date-if-known
> Intended Status: Standard Track
> 
> Summary:
> 
> The readibility of the draft has been significantly improved since my 
> last review (v07), mostly the abstract and the introduction, which now 
> cleary state what is the scope of the draft. I also appreciated the 
> introduction of section
> 3 where a description of the existing solution is described.
> 
> Minor issues:
> - Section 4.1 - Advantages with respect to RSVP-TE are described while 
> the text speaks about advantages with respect to RSVP-TE and GMPLS, 
> probably it could be changed into: advantages with respect to RSVP-TE 
> when used in packet networks and in GMPLS, something like this.

##PP
I can change to something like this:

"Advantages of Extended Link Opaque LSAs as defined in [RFC7684] for
OSPFv2 and Extended Router-LSAs [RFC8362] for OSPFv3 with respect to 
advertisement of link attributes originally defined for RSVP-TE when used in 
packet networks and in GMPLS"

Would that work?

[DC] yes, perfect.

 >
>- Section 5 - Why for the UDABM it doens't  say the value MUST be 0,4,8 
>but rather says "the legal values are" ? Is 8  octets future-proof 
>enough? or conversely, if only 3 values are defined why do  we need 8 
>octects as option?

##PP
I have corrected that and use the same text (with MUST) for both SABM and UDABM.
[DC] ok

We did not limit the size at the beginning, but later due to limited size of 
ISIS TLVs we limited it to 8 bytes to leave some space for the attributes 
itself (draft-ietf-isis-te-app). We wanted to keep the consistency between ISIS 
and OSPF which also helps BGP-LS. 8 octets should be future-proof enough (64 
apps).
[DC] makes sense.

 >
 >
>- Section 8 - I really find it hard to understand  this small section.

##PP
this section says that Extended TE Metrics can be advertised per application as 
well as application independent and suggests how that can be done.
[DC] that's not super clear from the text, but now I understand what's the 
message that it conveys. I suggest a better phrasing to make it clear.


> 
> Typos:
> -  Unidirectional Link Dela [RFC7471]

##PP
fixed.

thanks,
Peter

> 
> 
> 
> 
> 

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

Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

[wangyali]

Hi Acee,

Thanks for your kind suggestion. 

Best regards,
Yali

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Wednesday, June 3, 2020 9:46 PM
To: wangyali ; lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Speaking as WG chair:

It seems were getting a number of questions and comments on these ELC signaling 
documents as they go to the RFC Queue. I'd like to encourage review and 
discussion of LSR documents earlier in the WG process. One way to facilitate 
this would be for the authors to solicit review and discussion on the LSR list. 
This can be done at any time but should be done when documents are refreshed. 

Thanks,
Acee

On 6/3/20, 7:36 AM, "Lsr on behalf of wangyali"  wrote:

Hi authors,

After reading this draft, I am not clear with following points.

First,  as said " Even though ELC is a property of the node, in some cases 
it is advantageous to associate and advertise the ELC with a prefix.", what are 
"some cases" in which it is advantageous to associate and advertise the ELC 
with a prefix? And ELC is a property of the node, why don't extend the OSPF RI 
Opaque LSA to carry ELC?

Second, as said " If a router has multiple interfaces, the router MUST NOT 
announce ELC unless all of its interfaces are capable of processing ELs. ", why 
do not consider ELC advertisement in link granularity? 

Third, as said " If the router supports ELs on all of its interfaces, it 
SHOULD advertise the ELC with every local host prefix it advertises in OSPF.", 
what is the "every local host prefix"?

Last one, as defined that ERLD is advertised in a Node MSD TLV, why the 
ERLD-MSD type can be received in the OSPFv2 or OSPFv3 Link MSD sub-TLV? " When 
the ERLD-MSD type is received in the OSPFv2 or OSPFv3 Link MSD Sub-TLV 
[RFC8476], it MUST be ignored."

Best regards,
Yali

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, June 1, 2020 4:42 PM
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt


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   : Signaling Entropy Label Capability and Entropy 
Readable Label Depth Using OSPF
Authors : Xiaohu Xu
  Sriganesh Kini
  Peter Psenak
  Clarence Filsfils
  Stephane Litkowski
  Matthew Bocci
Filename: draft-ietf-ospf-mpls-elc-15.txt
Pages   : 9
Date: 2020-06-01

Abstract:
   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.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-15
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-mpls-elc-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-mpls-elc-15


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

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

Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

[wangyali]

Hi Peter,

Thanks for your reply. please see inline .

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Wednesday, June 3, 2020 7:44 PM
To: wangyali ; lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Yali,


On 03/06/2020 13:35, wangyali wrote:
> Hi authors,
> 
> After reading this draft, I am not clear with following points.
> 
> First,  as said " Even though ELC is a property of the node, in some cases it 
> is advantageous to associate and advertise the ELC with a prefix.", what are 
> "some cases" in which it is advantageous to associate and advertise the ELC 
> with a prefix? And ELC is a property of the node, why don't extend the OSPF 
> RI Opaque LSA to carry ELC?

this has been discussed on the WG alias endlessly, please go over the archives.
 Thanks. I think I lost some emails. I will search them. While I suggest 
give an illustration or some examples about the "some cases" in the draft. 
Please take it into account. 

> 
> Second, as said " If a router has multiple interfaces, the router MUST NOT 
> announce ELC unless all of its interfaces are capable of processing ELs. ", 
> why do not consider ELC advertisement in link granularity?

and how do you as a remote router know over which interface, or better line 
card, the traffic that you are sending going to arrive on a remote node? Does 
not make much sense.
 So can we say that ELC advertisement in node granularity is expressed by 
host prefix attributes advertisement? 

> 
> Third, as said " If the router supports ELs on all of its interfaces, it 
> SHOULD advertise the ELC with every local host prefix it advertises in 
> OSPF.", what is the "every local host prefix"?

it's a locally generated host prefix.

> 
> Last one, as defined that ERLD is advertised in a Node MSD TLV, why the 
> ERLD-MSD type can be received in the OSPFv2 or OSPFv3 Link MSD sub-TLV? " 
> When the ERLD-MSD type is received in the OSPFv2 or OSPFv3 Link MSD Sub-TLV 
> [RFC8476], it MUST be ignored."

yes, what's wrong with that statement?
 I think it will not happen. Why is it necessary to specify this case? 

regards,
Peter


> 
> Best regards,
> Yali
> 
> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Monday, June 1, 2020 4:42 PM
> To: i-d-annou...@ietf.org
> Cc: lsr@ietf.org
> Subject: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt
> 
> 
> 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   : Signaling Entropy Label Capability and Entropy 
> Readable Label Depth Using OSPF
>  Authors : Xiaohu Xu
>Sriganesh Kini
>Peter Psenak
>Clarence Filsfils
>Stephane Litkowski
>Matthew Bocci
>   Filename: draft-ietf-ospf-mpls-elc-15.txt
>   Pages   : 9
>   Date: 2020-06-01
> 
> Abstract:
> 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.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-15
> https://datatracker.ietf.org/doc/html/draft-ietf-ospf-mpls-elc-15
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-mpls-elc-15
> 
> 
> 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
> 
> 

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

Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

[Acee Lindem (acee)]

Speaking as WG chair:

It seems were getting a number of questions and comments on these ELC signaling 
documents as they go to the RFC Queue. I'd like to encourage review and 
discussion of LSR documents earlier in the WG process. One way to facilitate 
this would be for the authors to solicit review and discussion on the LSR list. 
This can be done at any time but should be done when documents are refreshed. 

Thanks,
Acee

On 6/3/20, 7:36 AM, "Lsr on behalf of wangyali"  wrote:

Hi authors,

After reading this draft, I am not clear with following points.

First,  as said " Even though ELC is a property of the node, in some cases 
it is advantageous to associate and advertise the ELC with a prefix.", what are 
"some cases" in which it is advantageous to associate and advertise the ELC 
with a prefix? And ELC is a property of the node, why don't extend the OSPF RI 
Opaque LSA to carry ELC?

Second, as said " If a router has multiple interfaces, the router MUST NOT 
announce ELC unless all of its interfaces are capable of processing ELs. ", why 
do not consider ELC advertisement in link granularity? 

Third, as said " If the router supports ELs on all of its interfaces, it 
SHOULD advertise the ELC with every local host prefix it advertises in OSPF.", 
what is the "every local host prefix"?

Last one, as defined that ERLD is advertised in a Node MSD TLV, why the 
ERLD-MSD type can be received in the OSPFv2 or OSPFv3 Link MSD sub-TLV? " When 
the ERLD-MSD type is received in the OSPFv2 or OSPFv3 Link MSD Sub-TLV 
[RFC8476], it MUST be ignored."

Best regards,
Yali

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, June 1, 2020 4:42 PM
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt


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   : Signaling Entropy Label Capability and Entropy 
Readable Label Depth Using OSPF
Authors : Xiaohu Xu
  Sriganesh Kini
  Peter Psenak
  Clarence Filsfils
  Stephane Litkowski
  Matthew Bocci
Filename: draft-ietf-ospf-mpls-elc-15.txt
Pages   : 9
Date: 2020-06-01

Abstract:
   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.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-15
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-mpls-elc-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-mpls-elc-15


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

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

Re: [Lsr] A question about draft-ietf-lsr-flex-algo

[Peter Psenak]

Hi Zhibo,

n 03/06/2020 14:40, Huzhibo wrote:

Hi Alexander, Peter:

  Thank you very much，After I read the WG alias, I still have a lot 
of doubts, can we calculate the disjoint path by exclude  SRLG in 
flexalgo? In fact, unless you previously defined two disjoint planes 
using SRLG, you cannot guarantee that different FlexAlgo can calculate 
disjoint paths.


the point is that if you did provide such path, flex-algo can calculate 
them. As I mentioned earlier, this use case came from the field, so 
people out there apparently have such topologies and SRLG assignments.


At the end of the day, use of any of the FAD constraints is optional. 
Look at them as lego blocks - if they fit to your network, use them, if 
they don't, leave them alone.


thanks,
Peter



Thanks

Zhibo Hu

*From:*Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
*Sent:* Wednesday, June 3, 2020 8:19 PM
*To:* Huzhibo ; Peter Psenak (ppsenak) 


*Cc:* lsr@ietf.org; draft-ietf-lsr-flex-a...@ietf.org
*Subject:* RE: A question about draft-ietf-lsr-flex-algo

Hi Zhibo Hu,

Welcome to the club - I have already asked the same question and got a 
response from Peter.


You can find the relevant email thread here 
.


My 2c,

Sasha

Office: +972-39266302

Cell:  +972-549266302

Email: alexander.vainsht...@ecitele.com 



*From:*Lsr mailto:lsr-boun...@ietf.org>> *On 
Behalf Of *Huzhibo

*Sent:* Wednesday, June 3, 2020 3:07 PM
*To:* Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>
*Cc:* lsr@ietf.org ; 
draft-ietf-lsr-flex-a...@ietf.org 

*Subject:* [Lsr] A question about draft-ietf-lsr-flex-algo

Hi Peter:

I noticed that draft-ietf-lsr-flex-algo-07 adds exclude SRLG TLV. SRLG 
defines a group of risk-sharing link groups. It is generally used to 
prevent the primary and standby paths from passing the same risk-sharing 
link group .I don't know why a group of SRLG links should be excluded 
from the FlexAlgo calculation. What is its usecase?


Thanks

Zhibo Hu


___

This e-mail message is intended for the recipient only and contains 
information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have 
received this
transmission in error, please inform us by e-mail, phone or fax, and 
then delete the original

and all copies thereof.
___



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

Re: [Lsr] A question about draft-ietf-lsr-flex-algo

[Huzhibo]

Hi Alexander, Peter:

 Thank you very much，After I read the WG alias, I still have a lot of 
doubts, can we calculate the disjoint path by exclude  SRLG in flexalgo? In 
fact, unless you previously defined two disjoint planes using SRLG, you cannot 
guarantee that different FlexAlgo can calculate disjoint paths.

Thanks

Zhibo Hu
From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: Wednesday, June 3, 2020 8:19 PM
To: Huzhibo ; Peter Psenak (ppsenak) 
Cc: lsr@ietf.org; draft-ietf-lsr-flex-a...@ietf.org
Subject: RE: A question about draft-ietf-lsr-flex-algo

Hi Zhibo Hu,
Welcome to the club - I have already asked the same question and got a response 
from Peter.
You can find the relevant email thread 
here.

My 2c,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Huzhibo
Sent: Wednesday, June 3, 2020 3:07 PM
To: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>
Cc: lsr@ietf.org; 
draft-ietf-lsr-flex-a...@ietf.org
Subject: [Lsr] A question about draft-ietf-lsr-flex-algo

Hi Peter:

I noticed that draft-ietf-lsr-flex-algo-07 adds exclude SRLG TLV. SRLG defines 
a group of risk-sharing link groups. It is generally used to prevent the 
primary and standby paths from passing the same risk-sharing link group .I 
don't know why a group of SRLG links should be excluded from the FlexAlgo 
calculation. What is its usecase?

Thanks

Zhibo Hu

___

This e-mail message is intended for the recipient only and contains information 
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original
and all copies thereof.
___
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] A question about draft-ietf-lsr-flex-algo

[Alexander Vainshtein]

Hi Zhibo Hu,
Welcome to the club - I have already asked the same question and got a response 
from Peter.
You can find the relevant email thread 
here.

My 2c,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: Lsr  On Behalf Of Huzhibo
Sent: Wednesday, June 3, 2020 3:07 PM
To: Peter Psenak (ppsenak) 
Cc: lsr@ietf.org; draft-ietf-lsr-flex-a...@ietf.org
Subject: [Lsr] A question about draft-ietf-lsr-flex-algo

Hi Peter:

I noticed that draft-ietf-lsr-flex-algo-07 adds exclude SRLG TLV. SRLG defines 
a group of risk-sharing link groups. It is generally used to prevent the 
primary and standby paths from passing the same risk-sharing link group .I 
don't know why a group of SRLG links should be excluded from the FlexAlgo 
calculation. What is its usecase?

Thanks

Zhibo Hu

___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
__
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] A question about draft-ietf-lsr-flex-algo

[Huzhibo]

Hi Peter:

I noticed that draft-ietf-lsr-flex-algo-07 adds exclude SRLG TLV. SRLG defines 
a group of risk-sharing link groups. It is generally used to prevent the 
primary and standby paths from passing the same risk-sharing link group .I 
don't know why a group of SRLG links should be excluded from the FlexAlgo 
calculation. What is its usecase?

Thanks

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

Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

[Peter Psenak]

Yali,


On 03/06/2020 13:35, wangyali wrote:

Hi authors,

After reading this draft, I am not clear with following points.

First,  as said " Even though ELC is a property of the node, in some cases it is advantageous 
to associate and advertise the ELC with a prefix.", what are "some cases" in which 
it is advantageous to associate and advertise the ELC with a prefix? And ELC is a property of the 
node, why don't extend the OSPF RI Opaque LSA to carry ELC?


this has been discussed on the WG alias endlessly, please go over the 
archives.




Second, as said " If a router has multiple interfaces, the router MUST NOT announce 
ELC unless all of its interfaces are capable of processing ELs. ", why do not 
consider ELC advertisement in link granularity?


and how do you as a remote router know over which interface, or better 
line card, the traffic that you are sending going to arrive on a remote 
node? Does not make much sense.





Third, as said " If the router supports ELs on all of its interfaces, it SHOULD advertise the 
ELC with every local host prefix it advertises in OSPF.", what is the "every local host 
prefix"?


it's a locally generated host prefix.



Last one, as defined that ERLD is advertised in a Node MSD TLV, why the ERLD-MSD type can 
be received in the OSPFv2 or OSPFv3 Link MSD sub-TLV? " When the ERLD-MSD type is 
received in the OSPFv2 or OSPFv3 Link MSD Sub-TLV [RFC8476], it MUST be ignored."


yes, what's wrong with that statement?

regards,
Peter




Best regards,
Yali

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Monday, June 1, 2020 4:42 PM
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt


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   : Signaling Entropy Label Capability and Entropy 
Readable Label Depth Using OSPF
 Authors : Xiaohu Xu
   Sriganesh Kini
   Peter Psenak
   Clarence Filsfils
   Stephane Litkowski
   Matthew Bocci
Filename: draft-ietf-ospf-mpls-elc-15.txt
Pages   : 9
Date: 2020-06-01

Abstract:
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.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-15
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-mpls-elc-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-mpls-elc-15


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




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

Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

[wangyali]

Hi authors,

After reading this draft, I am not clear with following points.

First,  as said " Even though ELC is a property of the node, in some cases it 
is advantageous to associate and advertise the ELC with a prefix.", what are 
"some cases" in which it is advantageous to associate and advertise the ELC 
with a prefix? And ELC is a property of the node, why don't extend the OSPF RI 
Opaque LSA to carry ELC?

Second, as said " If a router has multiple interfaces, the router MUST NOT 
announce ELC unless all of its interfaces are capable of processing ELs. ", why 
do not consider ELC advertisement in link granularity? 

Third, as said " If the router supports ELs on all of its interfaces, it SHOULD 
advertise the ELC with every local host prefix it advertises in OSPF.", what is 
the "every local host prefix"?

Last one, as defined that ERLD is advertised in a Node MSD TLV, why the 
ERLD-MSD type can be received in the OSPFv2 or OSPFv3 Link MSD sub-TLV? " When 
the ERLD-MSD type is received in the OSPFv2 or OSPFv3 Link MSD Sub-TLV 
[RFC8476], it MUST be ignored."

Best regards,
Yali

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, June 1, 2020 4:42 PM
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt


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   : Signaling Entropy Label Capability and Entropy 
Readable Label Depth Using OSPF
Authors : Xiaohu Xu
  Sriganesh Kini
  Peter Psenak
  Clarence Filsfils
  Stephane Litkowski
  Matthew Bocci
Filename: draft-ietf-ospf-mpls-elc-15.txt
Pages   : 9
Date: 2020-06-01

Abstract:
   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.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-15
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-mpls-elc-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-mpls-elc-15


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] Question on the early allocation - Re: [IANA #1171772] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04

[Loa Andersson]

Tony,

I guess that this shows that we should take care naming our registries.

In line please-

On 02/06/2020 23:24, tony...@tony.li wrote:


Hi Loa,


The code points are requested from "the IS-IS TLV Codepoints registry",
howver the "IS-IS TLV Codepoints" is a name space with 14 different
registries. I think the the registry you want to allocated code point
from the "TLV Codepoints registry”



I apologize for the confusion, you are certainly correct.

The confusion arises because the page is named “IS-IS TLV Codepoints” 
and the registry is the “TLV Codepoints Registry” so to be precise, we 
should request an allocation from the “IS-IS TLV Codepoints TLV 
Codepoints Registry”.  That does seem somewhat awkward and redundant 
redundant.


To reduce confusion in the future, perhaps the entire page should be 
renamed to “IS-IS Codepoints”?


In the party of the world there I'm active there is a tendency to call
"the page" the "name space", that stops us from repeating "registry" to
often, so we have name space, registry and sub-registry. This is as I
understand it a terminology IANA understands, even if there is no formal
acceptance of it.

Renaming the name space would require us to update a number of IS-IS
documents. I would advice against that, but if the wg decides to do it
try to help to get correct.

For the time being I'd say that we want to allocate the code points
from the "TLV Codepoints" reistry in the IS-IS TLV Codepoints"
namespace.

Doing that way it is also easier to find the correct registry.

>/Loa


Regards,
Tony



--

My mail server from time to time has come under DOS attacks,
we are working to fix it but it may take some time. If you
get denial of service sending to me plz try to use
loa.pi.nu@gmail


Loa Anderssonemail: l...@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting phone: +46 739 81 21 64

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