Hi, Les: Aijun Wang China Telecom
> On May 4, 2022, at 07:12, Les Ginsberg (ginsberg) <[email protected]> wrote: > > > Aijun – > > I am not an author of the draft – and so cannot speak on behalf of the draft > authors. > But here is my response as WG member. > > You need to focus on the dataplane. > > Suppose a node advertises 1.1.1.1/32 in (IS-IS) TLV 135. > If a packet addressed to 1.1.1.1 arrives unlabeled, it can be forwarded using > the Algo 0 path(s) installed in forwarding. > If a packet addressed to 1.1.1.1 arrives with MPLS label encap, you can use > the algorithm specific SID to do a lookup and forward based on the flex-algo > specific paths. > > But if you do not have an SR encap, what about the packet will tell you to > forward via (for example) Flex-algo 130 paths rather than Algo 0 paths? And > how would you install such paths in the dataplane along with Algo 0 paths? [WAJ] For IP-Flexalgo, I think the only indicator for different flex-algo is the destination itself. That is to say, if you associated the prefixes with one flex-algo, then the forwarding path/nexthop is determined via this flex-algo. That is to say, one prefix must be only associated with one flex-algo. > > IP Flex-Algo addresses those issues by assigning a given address to > one-and-only-one algo. This is why new Reachability advertisements are > required. [WAJ] We can achieve the same effect via associated the FAPM within the existing TLVs. I haven’t seen the necessary to define the new top TLV. > So, for example, the same node could advertise 1.1.1.2/32 in the new IPv4 > Algorithm Prefix Reachability TLV, associate it with algorithm 130, and a > forwarding entry can be installed for that prefix that follows Algo 130 paths. > Since this address is not used by any other algorithm (and especially not by > Algo 0), there is no ambiguity in the dataplane. [WAJ] Can get the same effect via the FAPM within the existing TLVs > > This is also why the statement you quote below regarding the same prefix > advertised in both IPv4 Reachability and IPv4 Algorithm Prefix Reachability > is necessary. The dataplane cannot support both for the same prefix. [WAJ] I think the above considerations is related to the flex-algo priority, that is, algo 0 has the higher priority. Such considerations can also be achieved via the FAPM. It can’t convince the persons that you must define one new top TLV. > > HTH > > Les > > > From: Aijun Wang <[email protected]> > Sent: Tuesday, May 3, 2022 3:10 PM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: Peter Psenak (ppsenak) <[email protected]>; Acee Lindem (acee) > <[email protected]>; [email protected]; [email protected] > Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 > - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" > > Hi, Peter and Les: > Prefix Segment Identifier sub-TLV and FAPM sub-TLV are two independent > sub-TLVs for TLV135, 235,236 and 237. > They are not required to be exist at the same time. > FAPM just describes the metrics that associated with different Flex-Algo. > Isn’t it more straightforward to associate it with the intended prefixes to > achieve the same results as the newly defined top-TLV? > I want to know the technical reason why we can’t follow this direction? > Anyway, the router can use such information to calculate the different > forwarding path based on the algorithm and metric. > If there is any obstacles to achieve this, I think we should update the > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-19 to cover it. > > And, in the WGLC document, there is the following description: > > In cases where a prefix advertisement is received in both a IPv4 > Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability > TLV, the IPv4 Prefix Reachability advertisement MUST be preferred > when installing entries in the forwarding plane. > > It is obvious that any prefixes can be advertised in either TLVs, what’s the > necessary to define the new one? > > > Aijun Wang > China Telecom > > > On May 3, 2022, at 22:48, Les Ginsberg (ginsberg) > <[email protected]> wrote: > > > Peter - > > I am in agreement. > > However, the IANA section of the draft is missing some necessary information. > The new top level TLVs in IS-IS - I am assuming you want these to share the > sub-TLV space defined in > https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-advertising-prefix-reachability > In which case you need to provide a list of the existing sub-TLVs and an > indication (Y/N) as to whether they are allowed in the new TLVs. > > Here is my initial take: > > 1 32-bit Administrative Tag Sub-TLV Y > 2 64-bit Administrative Tag Sub-TLV y > 3 Prefix Segment Identifier n > 4 Prefix Attribute Flags y > 5 SRv6 End SID n > 6 Flex-Algorithm Prefix Metric n > 11 IPv4 Source Router ID y > 12 IPv6 Source Router ID y > 32 BIER Info n(??) > > Les > > > -----Original Message----- > > From: Lsr <[email protected]> On Behalf Of Peter Psenak > > Sent: Tuesday, May 3, 2022 7:14 AM > > To: Aijun Wang <[email protected]>; Peter Psenak > > <[email protected]> > > Cc: Acee Lindem (acee) <[email protected]>; [email protected]; > > [email protected] > > Subject: Re: [Lsr] Working Group Last Call for > > draft-ietf-lsr-ip-flexalgo-04 - > > "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" > > > > Aijun, > > > > On 03/05/2022 15:52, Aijun Wang wrote: > > > Hi, Peter: > > > I think the logic is the following: > > > FAPM is the sub-TLV of TLV 135,235,236 and 237, then it extends these TLVs > > for advertising prefixes in algorithm 0 to other Flexible Algorithm. > > > Then I see no reason to define the new top-TLV to encoding the similar > > information. > > > > FAPM is used in SR-MPLS case where algo 0 prefix has multiple flex-algo > > SIDs. So the algo 0 reachability is always advertised in legacy TLV and > > FAPM is used to advertise additional flex-algo metric for inter-area or > > external prefixes. > > > > We can not use it for IP flex-algo. > > > > thanks, > > Peter > > > > > > > > Aijun Wang > > > China Telecom > > > > > >> On May 3, 2022, at 19:16, Peter Psenak > > <[email protected]> wrote: > > >> > > >> Hi Aijun, > > >> > > >>> On 03/05/2022 11:57, Aijun Wang wrote: > > >>> Hi, Peter： > > >>> Different data planes use different Flex-Algorithm and associated > > metric, they can’t be mixed. > > >>> Or, would you like to point out why the following scenarios can’t be > > achieved via the FAPM? > > >>> 1) The PE router has three loopback addresses(Lo1-Lo3), each associated > > with different Flex-ALgorithhms, and also different metrics. They are > > advertised via the FAPM, no MPLS SIDs are associated with these loopack > > prefixes advertisements. > > >>> 2) The PE router has also another inter-area/inter-domain > > prefixes(IPextra), with the FAPM and MPLS SID advertised via the prefixes > > advertisements. > > >>> When the PE in other ends want to send the traffic to theses addresses: > > >>> 1) To the formers three destinations(Lo1-Lo3), the FIB that are formed > > by the associated FAPM will be used, that is, the IP-based forwarding will > > be > > selected. > > >>> 2) To the Inter-area/inter-domain prefixes the FIB that are formed via > > the FAPM and the associated SID, the MPLS-based forwarding will be > > selected. > > >>> Why can’t they coexist? > > >> > > >> FAPM Sub-TLV is a sub-TLV of TLVs 135, 235, 236, and 237. These TLVs > > advertise the reachability of the prefix in algorithm 0. > > >> > > >> For an IP algo prefix, which is associated with the flex-algorithm, the > > reachability in algorithm 0 must not be advertised. So we have to use a > > different top level TLV. > > >> > > >> > > >> thanks, > > >> Peter > > >> > > >> > > >> > > >>> Aijun Wang > > >>> China Telecom > > >>>>> On May 3, 2022, at 16:05, Peter Psenak > > <[email protected]> wrote: > > >>>> > > >>>> Aijun, > > >>>> > > >>>>> On 03/05/2022 09:59, Aijun Wang wrote: > > >>>>> Hi, Peter: > > >>>>> The definition of FAPM for IS-IS and OSPF doesn’t prevent from it is > > used for the intra-area prefixes. > > >>>>> If we advertise the different loopback addresses via the FAPM, > > associate them to different Flex-Algo and related metrics, and does not > > allocate the MPLS SID, we can achieve the IP-Flex effect then. > > >>>> > > >>>> as I said, we can not mix metrics for different data-planes. > > >>>> > > >>>>> So, what’s the additional value of the IP-Flexalgo draft then? > > >>>> > > >>>> please read the draft. It defines the flex-algo for IP data plane. > > >>>> > > >>>> thanks, > > >>>> Peter > > >>>> > > >>>> > > >>>> > > >>>>> Aijun Wang > > >>>>> China Telecom > > >>>>>>> On May 3, 2022, at 14:46, Peter Psenak > > <[email protected]> wrote: > > >>>>>> > > >>>>>> Aijun, > > >>>>>> > > >>>>>>> On 03/05/2022 00:47, Aijun Wang wrote: > > >>>>>>> Hi, Acee: > > >>>>>>> The questions raised at > > https://mailarchive.ietf.org/arch/msg/lsr/RlHphXCwxMbgGvcBV_m24xiDzS0 > > / > > <https://mailarchive.ietf.org/arch/msg/lsr/RlHphXCwxMbgGvcBV_m24xiDzS > > 0/> has not been answered. > > >>>>>> > > >>>>>> IS-IS Flexible Algorithm Prefix Metric Sub-TLV” and “OSPF Flexible > > Algorithm Prefix Metric Sub-TLV” are defined for advertisement of algorithm > > specific metric for inter-area inter-AS prefixes for SR-MPLS data-plane. > > >>>>>> > > >>>>>> SR MPLS and IP are independent data-planes used for flex-algo. We > > can not mix their metric. > > >>>>>> > > >>>>>> thanks, > > >>>>>> Peter > > >>>>>> > > >>>>>>> Aijun Wang > > >>>>>>> China Telecom > > >>>>>>>>> On May 2, 2022, at 23:00, Acee Lindem (acee) > > <[email protected]> wrote: > > >>>>>>>> > > >>>>>>>> The WG last call has completed. We will submit an updated > > version of the document for publication with the terminology changes based > > on the discussion amongst the authors, Ketan, Robert, Gyan, and others. > > >>>>>>>> > > >>>>>>>> Thanks, > > >>>>>>>> Acee > > >>>>>>>> > > >>>>>>>> *From: *Lsr <[email protected]> on behalf of "Acee Lindem > > (acee)" <[email protected]> > > >>>>>>>> *Date: *Thursday, April 7, 2022 at 3:07 PM > > >>>>>>>> *To: *"[email protected]" <[email protected]> > > >>>>>>>> *Cc: *"[email protected]" <draft-ietf-lsr-ip- > > [email protected]> > > >>>>>>>> *Subject: *[Lsr] Working Group Last Call for draft-ietf-lsr-ip- > > flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" > > >>>>>>>> > > >>>>>>>> This begins a WG last call for draft-ietf-lsr-ip-flexalgo-04. The > > >>>>>>>> draft > > had a lot of support and discussion initially and has been stable for some > > time. Please review and send your comments, support, or objection to this > > list before 12 AM UTC on April 22^nd , 2022. > > >>>>>>>> > > >>>>>>>> Thanks, > > >>>>>>>> Acee > > >>>>>>>> > > >>>>>>>> _______________________________________________ > > >>>>>>>> Lsr mailing list > > >>>>>>>> [email protected] > > >>>>>>>> https://www.ietf.org/mailman/listinfo/lsr > > >>>>>> > > >>>> > > >>> _______________________________________________ > > >>> Lsr mailing list > > >>> [email protected] > > >>> https://www.ietf.org/mailman/listinfo/lsr > > >> > > > > > > > > > > _______________________________________________ > > Lsr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
