Hi Peter, Thanks. Please see inline <Yali3>.
-----Original Message----- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Thursday, June 4, 2020 4:53 PM To: wangyali <wangyal...@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:ppse...@cisco.com] > Sent: Wednesday, June 3, 2020 11:04 PM > To: wangyali <wangyal...@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:ppse...@cisco.com] >> Sent: Wednesday, June 3, 2020 7:44 PM >> To: wangyali <wangyal...@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? > >> >>> >>> 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-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
