Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Aijun Wang <wangaijun@tsinghua.org.cn> Tue, 03 May 2022 22:10 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0831BC157B33; Tue, 3 May 2022 15:10:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.885
X-Spam-Level:
X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-R4XU40DIoP; Tue, 3 May 2022 15:10:22 -0700 (PDT)
Received: from mail-m17638.qiye.163.com (mail-m17638.qiye.163.com [59.111.176.38]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7644BC14F746; Tue, 3 May 2022 15:10:18 -0700 (PDT)
Received: from smtpclient.apple (unknown [106.121.162.95]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id 173651C159F; Wed, 4 May 2022 06:10:15 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-9075F70F-1D35-4678-9ECE-9348C3813050"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Wed, 04 May 2022 06:10:14 +0800
Message-Id: <60FEDA0A-4770-412B-96F7-31D4CE2F9AA3@tsinghua.org.cn>
References: <BY5PR11MB43373CB7CF718DDC08278914C1C09@BY5PR11MB4337.namprd11.prod.outlook.com>
Cc: Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, lsr@ietf.org, draft-ietf-lsr-ip-flexalgo@ietf.org
In-Reply-To: <BY5PR11MB43373CB7CF718DDC08278914C1C09@BY5PR11MB4337.namprd11.prod.outlook.com>
To: "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>
X-Mailer: iPhone Mail (19E258)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgPGg8OCBgUHx5ZQUlOS1dZCBgUCR5ZQVlLVUtZV1 kWDxoPAgseWUFZKDYvK1lXWShZQUpMS0tKN1dZLVlBSVdZDwkaFQgSH1lBWRoYSk5WT04fT09DSU lPSEweVRMBExYaEhckFA4PWVdZFhoPEhUdFFlBWU9LSFVKSktITUpVS1kG
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6NTY6Kio4FT0zFBQKNB08Ei0y Ey1PFAtVSlVKTU5KTUpOQ0pOTUtLVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKS01VSklKVUpNSVVCTllXWQgBWUFITktJQzcG
X-HM-Tid: 0a808bf955bad993kuws173651c159f
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/sae9wlDlGfqQR8Zj_osW54DW8dg>
Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 May 2022 22:10:26 -0000

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) <ginsberg=40cisco.com@dmarc.ietf.org> 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 <lsr-bounces@ietf.org> On Behalf Of Peter Psenak
> > Sent: Tuesday, May 3, 2022 7:14 AM
> > To: Aijun Wang <wangaijun@tsinghua.org.cn>; Peter Psenak
> > <ppsenak=40cisco.com@dmarc.ietf.org>
> > Cc: Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>; lsr@ietf.org;
> > draft-ietf-lsr-ip-flexalgo@ietf.org
> > 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
> > <ppsenak=40cisco.com@dmarc.ietf.org> 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
> > <ppsenak=40cisco.com@dmarc.ietf.org> 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
> > <ppsenak=40cisco.com@dmarc.ietf.org> 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)
> > <acee=40cisco.com@dmarc.ietf.org> 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 <lsr-bounces@ietf.org> on behalf of "Acee Lindem
> > (acee)" <acee=40cisco.com@dmarc.ietf.org>
> > >>>>>>>> *Date: *Thursday, April 7, 2022 at 3:07 PM
> > >>>>>>>> *To: *"lsr@ietf.org" <lsr@ietf.org>
> > >>>>>>>> *Cc: *"draft-ietf-lsr-ip-flexalgo@ietf.org" <draft-ietf-lsr-ip-
> > flexalgo@ietf.org>
> > >>>>>>>> *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
> > >>>>>>>> Lsr@ietf.org
> > >>>>>>>> https://www.ietf.org/mailman/listinfo/lsr
> > >>>>>>
> > >>>>
> > >>> _______________________________________________
> > >>> 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 mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr