Hi, Gyan: Aijun Wang China Telecom
> On May 5, 2022, at 02:48, Gyan Mishra <[email protected]> wrote: > > > > Hi Aijun > > Section 6 describes why as Les has mentioned that you need a new top level > TLV for OSPF and ISIS for IP Flex Algo Reachability advertisement to > disambiguate the data plane IP from existing SR-MPLS and SRV6 data planes. > > The problem is that IP Flex Algo cannot use the existing prefix reachability > advertisement because IGP Flex Algo advertise the prefix reachability in > default Algo 0. [WAJ] My question is, if the existing prefix reachability is associated with FAPM, then they can be used to advertise the prefix reachability in other Algo. No one can explain why such approaches can’t be achieved until now. They just said we cannot. > Thus the existing top level TLVs cannot be used and new Top Level TLVs are > being allocated with the IP Flex Algo draft, > . > > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-6 > > 6. Advertising IP Flex-Algorthm Reachability > > To be able to associate the prefix with the Flex-Algorithm, the > existing prefix reachability advertisements can not be used, because > they advertise the prefix reachability in default algorithm 0. > Instead, a new IP Flex-Algorithm reachability advertisements are > defined in ISIS and OSPF. > > The M-flag in FAD is not applicable to IP Algorithm Prefixes. Any IP > Algorithm Prefix advertisement includes the Algorithm and Metric > fields. When IP Algorithm Prefix is advertised between areas or > domains, the metric field in the IP Algorithm Prefix advertisement > MUST be used irrespective of the M-flag in the FAD advertisement. > > Two new top-level TLVs are defined in ISIS [ISO10589] to advertise > prefix reachability associated with a Flex-Algorithm. > > * The IPv4 Algorithm Prefix Reachability TLV > > * The IPv6 Algorithm Prefix Reachability TLV > > New top-level TLV of OSPFv2 Extended Prefix Opaque LSA [RFC7684] is > defined to advertise prefix reachability associated with a Flex- > Algorithm in OSPFv2. [WAJ] If the previous concerns has not addressed, the above newly defined top TLV is baseless and unnecessary then. > > > Section 14 LSR Flex Algo helps describe the association of Flex Algo to > SR-MPLS prefix SID and SRv6 Locator. > > This is most pertinent as LSR Flex Algo base draft is applicable to > SR data plane but as this is a base draft it is extensible to future > innovations such as IP Flex Algo and other future data planes. > > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-19#section-14 > [WAJ] Yes. If the FAPM associated with existing IP reachability advertisement is used to advertise the IP-Flex Algo, then the corresponding forwarding description part can be added here. All things will be well done. > > > Thanks > > Gyan > >> On Wed, May 4, 2022 at 7:07 AM Aijun Wang <[email protected]> wrote: >> 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 > -- > > > Gyan Mishra > Network Solutions Architect > Email [email protected] > M 301 502-1347 > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
