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

Yali,

On 05/06/2020 06:25, wangyali wrote:
> Hi Peter,
> 
> Thanks. Please see inline <Yali3>.
> 
> -----Original Message-----
> From: Peter Psenak [mailto:ppsenak@cisco.com]
> Sent: Thursday, June 4, 2020 4:53 PM
> To: wangyali <wangyali11@huawei.com>; lsr@ietf.org
> Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt
> 
> Yali,
> 
> please see inline:
> 
> On 04/06/2020 05:09, wangyali wrote:
>> Hi Peter,
>>
>> Please see inline <Yali2>. Thanks.
>>
>> -----Original Message-----
>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>> Sent: Wednesday, June 3, 2020 11:04 PM
>> To: wangyali <wangyali11@huawei.com>; 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 <Yali>.
>>>
>>> -----Original Message-----
>>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>>> Sent: Wednesday, June 3, 2020 7:44 PM
>>> To: wangyali <wangyali11@huawei.com>; 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.
>>> <Yali> 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.
>> <Yali2> 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.
>>> <Yali> So can we say that ELC advertisement in node granularity is expressed by host prefix attributes advertisement?
>>
>> yes, pretty much that is the idea.
>> <Yali2> I am appreciate if you could summary the reason.
> 
> the reason is to support inter-area and inter-domain cases, where node attributes are not visible, but prefix attributes are.
> <Yali3>Appreciate. While AFAIK, OSPFv2 type-11 RI Opaque LSAs and OSPFv3 S1S2-01 RI Opaque LSAs are flooded  throughout the Autonomous System. For the Inter-Area flooding scope, I am not clear what is the difference?

it is certainly not flooded across multiple IGP domains.

thanks,
Peter

> 
>>
>>>
>>>>
>>>> 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?
>>> <Yali> 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.
>> <Yali2> 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?
> 
> correct.
> 
> thanks,
> Peter
> 
>>
>> regards,
>> Peter
>>
>>
>>
>>>
>>> regards,
>>> Peter
>>>
>>>
>>>>
>>>> Best regards,
>>>> Yali
>>>>
>>>> -----Original Message-----
>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>>>> Sent: Monday, June 1, 2020 4:42 PM
>>>> To: i-d-announce@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
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>>
> 
> 
> 