Subject: Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

From: Peter Psenak <[email-masked]>
Date: Thu, 1 Oct 2020 09:40:36 +0200

Robert,

On 30/09/2020 19:30, Robert Raszuk wrote:
> Peter,
> 
> Granted - you can do this with MPLS encapsulation.
> 
> But if you are doing native IP forwarding or SRv6 I am still unclear.
> 
> Imagine you get allocated by RIR say IPv4 /16 or IPv6  /32.
> 
> So you take some part of that block and use it for flex algo next hops 
> .. flood it via IGP and have flex algo F1 running/enabled on some nodes. 
> So far so good.
> 
> But what prevents the non enabled nodes to still use for those next hops 
> less specific say /8 from someone else in the Internet ?

we are talking IGPs here. A node send FA(X) route and inside the area 
all routers see it and can only route to it via nodes that are 
participating in FA(X). The only place where routes can get modified is 
at the inter-area or inter-domain boundary. That needs to be FA(X) aware 
if you want end-to-end FA(X) path.

The case you are describing is that a BGP speaker that is not FA(X) 
aware outside of the originating AS will pick the NH that is advertised 
in a summary that is not associated with any FA. Traffic will get 
directed to the right AS, and inside that AS, the first FA(X) aware 
router will switch to FA(X) aware path.

thanks,
Peter

> 
> Sure in some implementations (we both are a bit familiar with) we have a 
> way to track that next hop is declared unreachable if it was learned 
> from prefix shorter then /X. But this constrain seems to be not 
> documented anywhere in respect to flex algo. At min I think IP flex algo 
> use should make it clear and make it also a MUST.
> 
> So my point is that for SRv6 or Ron's proposal next hop MUST be only 
> learned via local IGP or be of no less then /X to be used for BGP next 
> hop resolution.
> 
> Many thx,
> R,
> 
> 
> 
> 
> 
> 
> 
> On Wed, Sep 30, 2020 at 5:18 PM Peter Psenak <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Robert,
> 
>     On 30/09/2020 16:28, Robert Raszuk wrote:
>      > Peter,
>      >
>      > Let's see if we are talking about the same thing ...
>      >
>      > Take SRv6 as example ... You can run flex algorithm only on selected
>      > segment endpoints as you do encap and dst rewrite. So rest of the
>      > network (P/transit routers) do not need to have a clue about any
>      > flex-algo other then plain old SPF.
> 
>     if all transit nodes do not participate/understand flex-algo, you will
>     not be able to route the traffic between the segment endpoints based on
>     the flex-algo, in other words algo specific locators will not be
>     reachable.
> 
>      >
>      > Now in Ron's case where there is no encap and you are applying
>     flex-algo
>      > to naked packets don't you think there is a difference and a bit of
>      > deployment difficulty to make it work ?
> 
>     it is the same as with SRv6 locator - prefix associated with algorithm,
>     with some additional SRv6 data. From the flex-algo calculation and
>     forwarding perspective there is no difference.
> 
>      >
>      > So assume one P node will not support it. This is native IP
>     switching so
>      > BGP advertises routes with new flex-algo next hop. If that next
>     hop is
>      > unreachable as signalling to that flex algo loopback was not
>     understood
>      > by P (new signalling extension) packets will be dropped.
> 
>     such P node would never ever be in the flex-algo forwarding path for
>     prefix associated with flex-algo. We are talking underlay here, not
>     BGP.
>     BGP service allocates the SRV6 SID from the algo specific locator in
>     case of SRv6. It can pick the NH as algo specific prefix I assume and
>     the rest is the same.
> 
>      >
>      > But what if that next hop would happen to be covered by some
>     aggregate
>      > route not subject perhaps to intended IP TE ?
> 
>     aggregation needs to be algo aware for it to work.
> 
>     thanks,
>     Peter
> 
> 
>      >
>      > Cheers,
>      > R.
>      >
>      >
>      >
>      > On Wed, Sep 30, 2020 at 2:11 PM Peter Psenak <[email-masked]
>     <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     Hi Robert,
>      >
>      >     On 30/09/2020 09:28, Robert Raszuk wrote:
>      >      > Hi,
>      >      >
>      >      >  > It uses the HBH option
>      >      >
>      >      > Currently Ron's proposal seems to work well for both IPv4
>     and IPv6
>      >      > addresses. I hope this discussion will not try to derail it to
>      >     IPv6 only
>      >      > track.
>      >      >
>      >      > I see no issue with loopback to flexible algorithm mapping
>     in 1:1
>      >     fashion.
>      >      >
>      >      > I do however see some issues in deploying such technology
>     as it will
>      >      > only work well if *all* nodes in the network support this new
>      >      > functionality. In contrast in SR world or control plane
>     based TE I
>      >      > proposed or any encapsulation based proposal only anchor nodes
>      >     need to
>      >      > support the new functionality while rest of the network
>     does not
>      >     need to
>      >      > be even aware about it.
>      >
>      >     above is not really true.
>      >
>      >     Algo participation needs to be signaled, one way or the
>     other. It's
>      >     done
>      >     for SR as well. There is no need for all routers to understand
>      >     flex-algo, as only those that participate (and as a result also
>      >     understand it) will be used during the flex-algo path
>     computation and
>      >     consequently flex-algo specific forwarding. This applies to
>      >     flex-algo in
>      >     general, regardless of the data plane being used.
>      >
>      >     thanks,
>      >     Peter
>      >
>      >
>      >      >
>      >      > Many thx,
>      >      > R.
>      >      >
>      >      >
>      >      > On Wed, Sep 30, 2020 at 6:10 AM Huzhibo
>     <[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      > <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>      >      >
>      >      >     Hi Joel:
>      >      >
>      >      >          For details about the method defined in RFC 6550. It
>      >     uses the
>      >      >     HBH option to carry the RPLInstaceID. The RPLInstaceID and
>      >      >     FlexAlgoID are similar.
>      >      >
>      >      >     Thanks
>      >      >
>      >      >     Zhibo
>      >      >
>      >      >     -----Original Message-----
>      >      >     From: Lsr [mailto:[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>]
>      >     On Behalf Of Joel M. Halpern
>      >      >     Sent: Wednesday, September 30, 2020 12:05 PM
>      >      >     Cc: [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >     Subject: Re: [Lsr] New Version Notification for
>      >      >     draft-bonica-lsr-ip-flexalgo-00.txt
>      >      >
>      >      >     I am missing something in this discussion of multiple
>     algorithms.
>      >      >
>      >      >     My understanding of flex-algo whether for MPLS, SRv6,
>     SRH, or
>      >     IPv6,
>      >      >     is that you need to associated a forwarding label
>     (e.g. MPLS
>      >     label
>      >      >     or IPv6
>      >      >     address) with a specific algorithm so that you can compute
>      >     the next
>      >      >     hope for the forwarding label using the proper algorithm.
>      >     Then when
>      >      >     a packet arrives, it is simply forwarded according to the
>      >     forwarding
>      >      >     table (e.g.
>      >      >     FIB, LIB, ..)
>      >      >
>      >      >     If that is so, then I do not understand how a given
>     prefix can be
>      >      >     safely associated with more than one algorithm.  I
>     could imagine
>      >      >     doing several calculations according to different
>      >     algorithms.  But
>      >      >     how do you decide which one applies to the packet?  As
>     far as I
>      >      >     know, flex-algo does not look at the QoS/CoS/ToS bits.
>      >      >
>      >      >     Yours,
>      >      >     Joel
>      >      >
>      >      >     PS: I will admit that it took until  an operator
>     described some
>      >      >     "interesting" constraints before I understood why one
>     would
>      >     even do
>      >      >     this.
>      >      >
>      >      >     On 9/29/2020 11:50 PM, Huzhibo wrote:
>      >      >      > Hi.
>      >      >      >
>      >      >      > Associating multiple algorithms with a given prefix
>     is an
>      >      >     interesting topic, and I think this can simplify the
>      >     complexity of
>      >      >     FlexAlgo. I wonder if the author would consider using
>     cases with
>      >      >     multiple algorithms with a given prefix.
>      >      >      >
>      >      >      > Thanks
>      >      >      >
>      >      >      > ZHibo
>      >      >      >
>      >      >      > -----Original Message-----
>      >      >      > From: Lsr [mailto:[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>]
>      >     On Behalf Of [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >      > Sent: Tuesday, September 29, 2020 10:05 PM
>      >      >      > To: Ron Bonica
>     <rbonica=[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>>
>      >      >      > Cc: [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >      > Subject: Re: [Lsr] New Version Notification for
>      >      >      > draft-bonica-lsr-ip-flexalgo-00.txt
>      >      >      >
>      >      >      >
>      >      >      > Ron,
>      >      >      >
>      >      >      > This is nice. It makes it clear that constraint
>     based path
>      >      >     computation need not have MPLS overhead for those that
>     don’t
>      >     want it.
>      >      >      >
>      >      >      > One thing that you don’t talk about is how this
>     gets used, tho
>      >      >     that may be blindingly obvious: you’ll need all nodes
>     placing
>      >     their
>      >      >     prefixes in the RIB/FIB, where it will need to be
>     selected over
>      >      >     other path computation for the same prefixes.  This
>     somewhat
>      >      >     precludes the possibility of a given prefix being
>     useful in
>      >     multiple
>      >      >     flex-algos.
>      >      >      >
>      >      >      > More text on application would be most welcome,
>     just to ensure
>      >      >     that we’re on the same page.
>      >      >      >
>      >      >      > Tony
>      >      >      >
>      >      >      >
>      >      >      >> On Sep 29, 2020, at 6:37 AM, Ron Bonica
>      >      >     <rbonica=[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>> wrote:
>      >      >      >>
>      >      >      >>
>      >      >      >> Please review and comment
>      >      >      >>
>      >      >      >>                                        Ron
>      >      >      >>
>      >      >      >>
>      >      >      >>
>      >      >      >> Juniper Business Use Only
>      >      >      >>
>      >      >      >>> -----Original Message-----
>      >      >      >>> From: [email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>> <[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>>
>      >      >      >>> Sent: Tuesday, September 29, 2020 9:36 AM
>      >      >      >>> To: Parag Kaneriya <[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>>;
>      >     Shraddha Hegde
>      >      >      >>> <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>; Ron
>      >      >     Bonica <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>; Rajesh M
>      >      >      >>> <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>; William
>      >      >     Britto A J <[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>>
>      >      >      >>> Subject: New Version Notification for
>      >      >      >>> draft-bonica-lsr-ip-flexalgo-00.txt
>      >      >      >>>
>      >      >      >>> [External Email. Be cautious of content]
>      >      >      >>>
>      >      >      >>>
>      >      >      >>> A new version of I-D,
>     draft-bonica-lsr-ip-flexalgo-00.txt
>      >      >      >>> has been successfully submitted by Ron Bonica and
>     posted
>      >     to the
>      >      >     IETF
>      >      >      >>> repository.
>      >      >      >>>
>      >      >      >>> Name:           draft-bonica-lsr-ip-flexalgo
>      >      >      >>> Revision:       00
>      >      >      >>> Title:          IGP Flexible Algorithms
>     (Flexalgo) In IP
>      >     Networks
>      >      >      >>> Document date:  2020-09-29
>      >      >      >>> Group:          Individual Submission
>      >      >      >>> Pages:          14
>      >      >      >>> URL:
>      >      >
>     https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica-
>      >      >      >>> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
>      >      >      >>>
>     FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$
>      >      >      >>> Status:
>      >      >      >>>
>      >      >
>     https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-b
>      >      >      >>> o
>      >      >      >>> nica-lsr-
>      >      >      >>> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
>      >      >      >>>
>     FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
>      >      >      >>> Htmlized:
>      >      >      >>>
>      >      >
>     https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dr
>      >      >      >>> a
>      >      >      >>> ft-
>      >      >      >>> bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP-
>      >      >      >>>
>     FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$
>      >      >      >>> Htmlized:
>      >      > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-
>      >      >      >>> bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP-
>      >      >      >>>
>     FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$
>      >      >      >>>
>      >      >      >>>
>      >      >      >>> Abstract:
>      >      >      >>>    An IGP Flexible Algorithm computes a
>     constraint-based
>      >     path
>      >      >     and maps
>      >      >      >>>    that path to an identifier.  As currently defined,
>      >     Flexalgo
>      >      >     can only
>      >      >      >>>    map the paths that it computes to Segment
>     Routing (SR)
>      >      >     identifiers.
>      >      >      >>>    Therefore, Flexalgo cannot be deployed in the
>     absence
>      >     of SR.
>      >      >      >>>
>      >      >      >>>    This document extends Flexalgo, so that it can map
>      >     the paths
>      >      >     that it
>      >      >      >>>    computes to IP addresses.  This allows
>     Flexalgo to be
>      >      >     deployed in any
>      >      >      >>>    IP network, even in the absence of SR.
>      >      >      >>>
>      >      >      >>>
>      >      >      >>>
>      >      >      >>>
>      >      >      >>> 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 <http://tools.ietf.org>
>     <http://tools.ietf.org> <http://tools.ietf.org>.
>      >      >      >>>
>      >      >      >>> The IETF Secretariat
>      >      >      >>>
>      >      >      >> _______________________________________________
>      >      >      >> Lsr mailing list
>      >      >      >> [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >      >> https://www.ietf.org/mailman/listinfo/lsr
>      >      >      >
>      >      >      > _______________________________________________
>      >      >      > Lsr mailing list
>      >      >      > [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >      > https://www.ietf.org/mailman/listinfo/lsr
>      >      >      > _______________________________________________
>      >      >      > Lsr mailing list
>      >      >      > [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >      > https://www.ietf.org/mailman/listinfo/lsr
>      >      >      >
>      >      >
>      >      >     _______________________________________________
>      >      >     Lsr mailing list
>      >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      > https://www.ietf.org/mailman/listinfo/lsr
>      >      >     _______________________________________________
>      >      >     Lsr mailing list
>      >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      > https://www.ietf.org/mailman/listinfo/lsr
>      >      >
>      >
>

---

From: Peter Psenak <[email-masked]>
Date: Thu, 1 Oct 2020 10:07:26 +0200

Hi Ron,

I can only guess the use-case, but it may be worth of documenting it in 
the draft.

Your proposal is basically mimicking SRv6 Locator behavior for regular 
IPv6 and IPv4 prefixes. One can even argue that for IPv6 you can use a 
Locator advertisement with no SIDs, but I agree that would be a hack and 
separate encoding is cleaner.

One thing that needs further work is the algo participation part. Given 
that we have a separate participation for SR and IP flex-algo, one would 
have to run a separate calculation each in the context of the same 
flex-algo. Even though in most cases one would expect the set of 
participating routers to be the same for both. I don't see an easy way 
out, actually this is what the base FA draft requires it in section 
10.2. What I would suggest is to clearly document the fact that the 
computation for the IP flex-algo is independent of the other flex-algo 
computations (e.g. SR) and that IP flex-algo is an application of its 
own from the flex-algo perspective.

Les has commented on ISIS encoding, I have a question on OSPF one - have 
you considered using the OSPFv2 Extended Prefix Opaque LSA with OSPFv2 
Extended Prefix TLV (rfc7684) and define a new "IP Felex-algo" metric 
sub-TLV?

thanks,
Peter

On 29/09/2020 15:37, Ron Bonica wrote:
> 
> Please review and comment
> 
>                                         Ron
> 
> 
> 
> Juniper Business Use Only
> 
>> -----Original Message-----
>> From: [email-masked] <[email-masked]>
>> Sent: Tuesday, September 29, 2020 9:36 AM
>> To: Parag Kaneriya <[email-masked]>; Shraddha Hegde
>> <[email-masked]>; Ron Bonica <[email-masked]>; Rajesh M
>> <[email-masked]>; William Britto A J <[email-masked]>
>> Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
>>
>> [External Email. Be cautious of content]
>>
>>
>> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt
>> has been successfully submitted by Ron Bonica and posted to the IETF
>> repository.
>>
>> Name:           draft-bonica-lsr-ip-flexalgo
>> Revision:       00
>> Title:          IGP Flexible Algorithms (Flexalgo) In IP Networks
>> Document date:  2020-09-29
>> Group:          Individual Submission
>> Pages:          14
>> URL:            https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica-
>> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
>> Status:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-lsr-
>> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
>> Htmlized:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-
>> bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP-
>> Htmlized:       https://urldefense.com/v3/__https://tools.ietf.org/html/draft-
>> bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP-
>> Abstract:
>>     An IGP Flexible Algorithm computes a constraint-based path and maps
>>     that path to an identifier.  As currently defined, Flexalgo can only
>>     map the paths that it computes to Segment Routing (SR) identifiers.
>>     Therefore, Flexalgo cannot be deployed in the absence of SR.
>>
>>     This document extends Flexalgo, so that it can map the paths that it
>>     computes to IP addresses.  This allows Flexalgo to be deployed in any
>>     IP network, even in the absence of SR.
>>
>>
>>
>>
>> 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.
>>
>> The IETF Secretariat
>>
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
> 
>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 1 Oct 2020 15:33:30 +0000

Les,

Thanks for the review. All good catches.

We will address them all in the next draft version.

                            Ron

-----Original Message-----
From: Les Ginsberg (ginsberg) <ginsberg=[email-masked]> 
Sent: Wednesday, September 30, 2020 3:39 PM
To: Ron Bonica <[email-masked]>; [email-masked]
Subject: RE: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

Ron -

Interesting proposal.

A few mundane - but I think still important - comments.

New IS-IS TLVs
--------------------

There is no need to have two TLVs for each address-family - one for MTID #0 and one for all non-zero MTIDs. One TLV/AF will suffice.
The reason we have separate TLVs today is because MT (RFC 5120)  came along after TLV 135/236 had been defined/deployed.
Since you have a greenfield here you can simply have one TLV/AF and allow all MTIDs (including 0).

MTID is a 16 bit field with 4 reserved bits and 12 bits used for MTID value.  (I believe someone else pointed this out as well.) See RFC 5120.

You should specify that the new TLVs inherit the sub-TLV space defined in https://urldefense.com/v3/__https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml*isis-tlv-codepoints-135-235-236-237__;Iw!!NEt6yMaO-gk!Rh_KQ_Gqclv8ar4yhZ4nGijt5s9AbhGufBcPVYsk5iEHCP_lp_nRG_C8qZvvh30w$

The U-bit
-------------

I appreciate that there is precedence for calling this the U-bit based on RFC 5308 - but I would prefer that you call it the D-bit.
Regardless of name, it MUST be consistent with existing usage - meaning it is set when the prefix is leaked downwards. Currently your text says:

"U (1 bit): Set indicates up.  Clear indicates down."

This needs to be reversed.

Constraints
---------------

I think you need to speak to various constraints including (but not limited to):

1)Algorithm is limited to flex-algo values (128-255)

I don't understand why Section 6 (main part - not the sub-sections) is there. What relevance do non-flex-algos have to this draft??

I also think the new sub-TLV would be better named "Native Flex-Algo Algorithm Sub-TLV".
Unless you are proposing to use this sub-TLV in ways not related to flex-algo - in which case I think you need to provide some explanation of the use case for this.

2)How to handle advertisement of same algo both in the new Algorithm sub-TLV and the existing SR Algorithm sub-TLV (prefer SR??) Note that legacy routers may understand SR Algorithm Sub-TLV but not the new one.

   Les

> From: Lsr <[email-masked]> On Behalf Of Ron Bonica
> Sent: Tuesday, September 29, 2020 6:38 AM
> To: [email-masked]
> Subject: [Lsr] FW: New Version Notification for 
> draft-bonica-lsr-ip-flexalgo- 00.txt
>
>
> > aft-
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> _;!!NEt6yMaO-gk!Rh_KQ_Gqclv8ar4yhZ4nGijt5s9AbhGufBcPVYsk5iEHCP_lp_nRG_
> C8qYrcbkbN$

---

From: Ron Bonica <[email-masked]>
Date: Thu, 1 Oct 2020 15:37:46 +0000

Hi Tony,

You are correct in that a prefix can only be associated with one Flexalgo.

I will add some text about applications in the next version.

                       Ron

-----Original Message-----
From: Tony Li <[email-masked]> On Behalf Of [email-masked]
Sent: Tuesday, September 29, 2020 10:05 AM
To: Ron Bonica <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

Ron,

This is nice. It makes it clear that constraint based path computation need not have MPLS overhead for those that don’t want it.

One thing that you don’t talk about is how this gets used, tho that may be blindingly obvious: you’ll need all nodes placing their prefixes in the RIB/FIB, where it will need to be selected over other path computation for the same prefixes.  This somewhat precludes the possibility of a given prefix being useful in multiple flex-algos.

More text on application would be most welcome, just to ensure that we’re on the same page.

Tony

> On Sep 29, 2020, at 6:37 AM, Ron Bonica <rbonica=[email-masked]> wrote:
>
>
>> 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.
>>
>> The IETF Secretariat
>>
> _;!!NEt6yMaO-gk!RnM-z-O3leH_IIH06LxRzZKbRMQuuQcRs4g4RCiTbE0PleY70Sm2h3
> pFo42w7jA8$

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 1 Oct 2020 16:51:25 +0000

Speaking as WG member... 

I agree that an independent calculation is required for IP Flex Algorithm and SR Flex Algorithm and this should be documented. However, it doesn't seem to me a normal use case would be to deploy them in the same IGP area. 

Thanks,
Acee

On 10/1/20, 4:07 AM, "Lsr on behalf of Peter Psenak" <[email-masked] on behalf of ppsenak=[email-masked]> wrote:

    Hi Ron,

    thanks,
    Peter

---

From: Ron Bonica <[email-masked]>
Date: Thu, 1 Oct 2020 18:45:00 +0000

Good point!!

Juniper Business Use Only
From: Jeff Tantsura <[email-masked]>
Sent: Thursday, October 1, 2020 2:08 AM
To: Ron Bonica <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

Hi Ron,

the readers would benefit if the draft would state that in order for the technology to work properly, there must be a contiguous set of connected routers that support it between the S/D, since lookup (route installed in context of the algo it is associated with) is done per hop.

Cheers,
Jeff
On Sep 30, 2020, 9:03 AM -0700, Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>, wrote:
Hi Muthu,

Thanks for the review.

An interface can be associated with, at most, one Flexible Algorithm. Likewise, an IP address can be associated with, at most, one Flexible Algorithm.

I tried to express this in the text below, but probably didn't do a very good job. If you can think of a better way to say it, I would appreciate suggestions.

                                                  Ron

Text from draft
============

Network operators configure multiple loopback interfaces on an egress
   node.  They can associate each loopback interface with:

   o  Zero or more IP addresses.

   o  Zero or one Flexible Algorithms.

   If an IP address and a Flexible Algorithm are associated with the
   same interface, they are also associated with one another.  An IP
   address MAY be associated with, at most, one interface.

Juniper Business Use Only
From: Muthu Arul Mozhi Perumal <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, September 30, 2020 9:59 AM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

A quick question:

   If an IP address and a Flexible Algorithm are associated with the

   same interface, they are also associated with one another.  An IP

   address MAY be associated with, at most, one interface.

If multiple IP addresses and multiple flexible algorithms are associated with a loopback interface, is each IP address associated with all flexible algorithms? What matters is the association b/w an IP address and a flexalgo, so the relationship should be defined in a direct way rather than each being associated with an interface, right?

Regards,
Muthu

On Tue, Sep 29, 2020 at 7:07 PM Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:

                                       Ron

> From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
> To: Parag Kaneriya <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde
> <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; Rajesh M
> <[email-masked]<mailto:[email-masked]>>; William Britto A J <[email-masked]<mailto:[email-masked]>>
> URL:            https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica-<https://urldefense.com/v3/__https:/www.ietf.org/id/draft-bonica->
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-lsr-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-bonica-lsr->
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft->
> Htmlized:       https://urldefense.com/v3/__https://tools.ietf.org/html/draft-<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft->
> until the htmlized version and diff are available at tools.ietf.org<https://urldefense.com/v3/__http:/tools.ietf.org__;!!NEt6yMaO-gk!VQoAwwHICHoY23KWJbKL7SpeHYGiY6hT9pSpTh7Mfn5lQyaC9E5JcOlvhG1kuR-O$>.
>
> The IETF Secretariat
>
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!VQoAwwHICHoY23KWJbKL7SpeHYGiY6hT9pSpTh7Mfn5lQyaC9E5JcOlvhOxbdTsH$>
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 2 Oct 2020 12:30:29 -0400

Hi Ron

I really like the idea of being able to use flex algo over native IPv4 or
IPv6.  I had asked that very question early on with flex algo and wondered
if there was a way to support it with native IP.

Great concept and idea!!

As mentioned in the thread as you are using loopbacks associated with the
flex algorithm the concept is very similar to SRv6 locator and only one
algorithm per IP, interface or prefix and uses the same IGP longest prefix
match routing.

A lot of the basic concepts TLV and nomenclature from the SR flex algo
draft seems to be adopted with this draft.  Main difference is IP data
plane forwarding instead of SR Segment based forwarding plane.

Had a question related to the data plane forwarding and building of the
explicit paths loose or strict similar to constraint based prefix sid loose
path or adjacency sid based strict path done in SR paradigm.  As you are
using a native IP forwarding plane, how do we accomplish the same building
of the explicit path as done with Segment Routing SRv6 using SRH SID list
or SR-MPLS label stack from a data plane forwarding standpoint?

Would you use a similar RSVP TE style ERO lose or strict record route
option used for FRR n:1 facility protection in IP world use ip source route
record route IP option to record the path.

For IPv6 would you use EH routing header to record the path.

In this section maybe having some examples or graphical depiction of the
forwarding plane both loose and strict path instantiation and how that
would work.

8 <https://tools.ietf.org/html/draft-bonica-lsr-ip-flexalgo-00#section-8>.
Calculating Constraint-Based Paths

   Nodes calculate constraint-based paths as described in Section 12 of
   [I-D.ietf-lsr-flex-algo
<https://tools.ietf.org/html/draft-bonica-lsr-ip-flexalgo-00#ref-I-D.ietf-lsr-flex-algo>].

Maybe recording of the path is not needed if we are doing hop by hop
routing just with different constraint algorithms and not the instantiation
of a source routed path as with SR.

With SR flex algo since the data plane is SR based its a source routed path
that is instantiated so this would be different as it would be a IGP
control plane based hop by hop routed path.  If that’s the case.

As flex algo in SR framework can be used in conjunction with SR-TE can this
IP based flex algo be used with RSVP TE maybe adding in future IGP opaque
LSA or TLV extension to flex algo.

As IP based flex algo is very similar to SRv6-BE w/o SRH it seems they both
would interoperate nicely as both use native IPv6 forwarding plane.

Maybe down the road a separate draft on interoperability of IP flex algo
with SR and RSVP-TE if you think that is feasible.

All,

With SRv6 and IP based flex algo a generic question as it applies to both.
Is it possible to have within a single IGP domain different sets of nodes
or segments of the network running different algorithms.  From both drafts
it sounds like all nodes have to agree on same algorithm similar to concept
of metric and reference bandwidth all have to have the same style metric
and play to the same sheet of music.  If there was a way to use multiple
algorithms simultaneously based on SFC or services and instantiation of
specific algorithm based on service to be rendered.  Doing so without
causing a routing loop or sub optimal routing.  I thought with flex algo
that there exists a feature that on each hop there is a way to specify
which algo to use hop by hop similar to a hop by hop policy based routing.

Kind Regards

Gyan

On Thu, Oct 1, 2020 at 2:45 PM Ron Bonica <rbonica=
[email-masked]> wrote:

> *From:* Jeff Tantsura <[email-masked]>
>
>
> *Sent:* Thursday, October 1, 2020 2:08 AM
>
>
> *To:* Ron Bonica <[email-masked]>
>
>
> *Cc:* [email-masked]
>
>
> *Subject:* Re: [Lsr] FW: New Version Notification for
> *[External Email. Be cautious of content]*
>
>
>
>
>
>
>
>
>
>
>
> Hi Ron,
>
>
>
>
>
> the readers would benefit if the draft would state that in order for the
> technology to work properly, there must be a contiguous set of connected
> routers that support it between the S/D, since lookup (route installed in
> context of the algo it is associated
>
> with) is done per hop.
>
>
>
>
>
>
>
>
>
>
>
>
>
> Cheers,
>
>
>
>
> Jeff
>
>
>
>
>
>
>
>
>
>
> On Sep 30, 2020, 9:03 AM -0700, Ron Bonica <
> rbonica=[email-masked]>, wrote:
>
>
>
>
>
>
> Hi Muthu,
>
>
>
>
>
> Thanks for the review.
>
>
>
>
>
> An interface can be associated with, at most, one Flexible Algorithm.
> Likewise, an IP address can be associated with, at most, one Flexible
> Algorithm.
>
>
>
>
>
> I tried to express this in the text below, but probably didn’t do a very
> good job. If you can think of a better way to say it, I would appreciate
> suggestions.
>
>
>
>
>
>                                                   Ron
>
>
>
>
>
> Text from draft
>
>
> ============
>
>
>
>
>
> *From:* Muthu Arul Mozhi Perumal <[email-masked]>
>
>
> *Sent:* Wednesday, September 30, 2020 9:59 AM
>
>
> *To:* Ron Bonica <[email-masked]>
>
>
> *Cc:* [email-masked]
>
>
> *Subject:* Re: [Lsr] FW: New Version Notification for
> *[External Email. Be cautious of content]*
>
>
>
>
>
>
>
>
>
> A quick question:
>
>
>
>
>
>
> If multiple IP addresses and multiple flexible algorithms are associated
> with a loopback interface, is each IP address associated
>
> with all flexible algorithms? What matters is the association b/w an IP
> address and a flexalgo, so the relationship should be defined in a direct
> way rather than each being associated with an interface, right?
>
>
>
>
>
>
>
>
>
>
>
>
>
> Regards,
>
>
>
>
>
>
> Muthu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Sep 29, 2020 at 7:07 PM Ron Bonica <rbonica=
> [email-masked]> wrote:
>
>
>
>
>
>
>
> > URL:
> <https://urldefense.com/v3/__https:/www.ietf.org/id/draft-bonica->
>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-bonica-lsr->
>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft->
>
>
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft->
>
>
> submission
> > until the htmlized version and diff are available at
>
> tools.ietf.org
> <https://urldefense.com/v3/__http:/tools.ietf.org__;!!NEt6yMaO-gk!VQoAwwHICHoY23KWJbKL7SpeHYGiY6hT9pSpTh7Mfn5lQyaC9E5JcOlvhG1kuR-O$>
> .
>
>
> >
>
>
> > The IETF Secretariat
>
>
> >
>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!VQoAwwHICHoY23KWJbKL7SpeHYGiY6hT9pSpTh7Mfn5lQyaC9E5JcOlvhOxbdTsH$>
>
>
>
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Peter Psenak <[email-masked]>
Date: Fri, 2 Oct 2020 18:42:05 +0200

Gyan,

On 02/10/2020 18:30, Gyan Mishra wrote:
> All,
> 
> With SRv6 and IP based flex algo a generic question as it applies to 
> both. Is it possible to have within a single IGP domain different sets 
> of nodes or segments of the network running different algorithms.  

absolutely.

> From 
> both drafts it sounds like all nodes have to agree on same algorithm 
> similar to concept of metric and reference bandwidth all have to have 
> the same style metric and play to the same sheet of music.

all participating nodes need to agree on the definition of the flex-algo 
and advertise the participation. That's it.

> If there was 
> a way to use multiple algorithms simultaneously based on SFC or services 
> and instantiation of specific algorithm based on service to be 
> rendered.  Doing so without causing a routing loop or sub optimal 
> routing.  

you can certainly use multiple algorithms simultaneously and use algo 
specific paths to forward specific traffic over it. How that is done 
from the forwarding perspective depends in which forwarding plane you 
use. Flex-algo control plane is independent of the forwarding plane.

>I thought with flex algo that there exists a feature that on 
> each hop there is a way to specify which algo to use hop by hop similar 
> to a hop by hop policy based routing.

no, there is no hop-by-hop classification, that is problematic and does 
not scale for high speeds. Classification is done at the ingress only.

thanks,
Peter

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 2 Oct 2020 13:41:41 -0400

Thanks Peter!

> > of nodes or segments of the network running different algorithms.

   Gyan> Great.  As was noted on the thread that with SR-MPLS you can have
multiple labels and each label bound to a different algorithm for a service
prefix, however that is not possible with SRv6 as it’s a 1-1 binding
destination prefix to SRv6 sid.  With SRv6 standard longest prefix matching
 can you  also have different sets of nodes running different algorithms
within the same domain.  SRv6 has the advantage of LPM but SR-MPLS does
seem to have an advantage of being able to have multiple algorithms tied to
a label bound to the same FEC.  That does seem to be an advantageous
feature with SR-MPLS - MPLS data plane use of flex algo as compare to SRv6.

> and advertise the participation. That's it.

    Gyan> Trying to picture how it would work if you had let’s say all
nodes in a single IGP domain or MT instance running let’s say 2 different
algorithms simultaneously.  Would it be like 2 different routing overlay
IGP instances or ISIS MT instance or ospf process.  Also would that work
with just SR-MPLS or would that also work with SRv6?  In the case where you
have groups of nodes running a different algorithm the adjacent border
nodes between the groupings would end up running multiple  algorithms.  So
it can work and not issue with routing loops or sub optimal routing.

> Gyan> Is there a flex algo use case draft?
>
>
>
> Gyan>  Is the classification of interesting traffic base on QOS marking on
> ingress to map to a specific flex algo for a particular service?
>
> thanks,
>
> Peter
>
>
>
> >
>
>
>
> --

*Gyan Mishra*

---

From: Yingzhen Qu <[email-masked]>
Date: Fri, 2 Oct 2020 20:15:44 +0000

Hi Peter,

My understanding of flex-algo is that for traffic destined to a prefix on a particular algo, it can only be routed on routers belong to that algo, which also means only routers in that algo calculates how to reach that prefix and install it into the routing table. It seems to me that using flex-algo (section 12 of the draft) it's possible to have a loopback address associated with only one algo, please correct me if I'm missing or misunderstood something.

Thanks,
Yingzhen

On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" <[email-masked] on behalf of ppsenak=[email-masked]> wrote:

    Gyan,

    absolutely.

    thanks,
    Peter

    _______________________________________________
    Lsr mailing list
    [email-masked]
    https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=02%7C01%7Cyingzhen.qu%40futurewei.com%7C51dd940ab25d4ea19b1b08d866f23b6a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637372537869296887&amp;sdata=R%2FI%2BAUkcw12FmgDtsh%2FBOL7zLjPF%2BwwRpqwnE2Ndv%2Fg%3D&amp;reserved=0

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 2 Oct 2020 15:25:31 -0700

Hi Yingzhen,

Yes, that’s the case.  The most important property of an algo computed path is that is has to be consecutive, as either SID or IP address associated with a particular topology is only known within that topology.
Looking specifically at Ron’s draft (MPLS could be more complex due to potential hierarchy) - the prefix itself defines the context(topology) and must be globally unique, since IPv4 header can’t have any additional meta-data attached.

Cheers,
Jeff

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 2 Oct 2020 20:14:00 -0400

Hi  Jeff

>From a domain perspective where you have a group of nodes and associated IP
addressed and SID are part of a discrete underlay instance flex algo
topology.  On those same set of nodes you could have another topology and
associated address and SIDs for a different flex algo.  How this would work
is that the topologies would have to be segregated from each other as
different MT instances or routing process instances.  Is that correct?

Can two nodes that run two different flex algo become ospf or isis
neighbors?

Kind Regards

Gyan

On Fri, Oct 2, 2020 at 6:25 PM Jeff Tantsura <[email-masked]>
wrote:

>
>
>
>
>
>
>
>
>
>
>
>
> Hi Yingzhen,
>
>
>
>
>
> Yes, that’s the case.  The most important property of an algo computed
> path is that is has to be consecutive, as either SID or IP address
> associated with a particular topology is only known within that topology.
>
>
> Looking specifically at Ron’s draft (MPLS could be more complex due to
> potential hierarchy) - the prefix itself defines the context(topology) and
> must be globally unique, since IPv4 header can’t have any additional
> meta-data attached.
>
>
>
>
>
>
>
> Cheers,
>
> Jeff
>
>
>
>
>
>
> My understanding of flex-algo is that for traffic destined to a prefix on
> a particular algo, it can only be routed on routers belong to that algo,
> which also means only routers in that algo calculates how to reach that
> prefix and install it into the routing table. It seems to me that using
> flex-algo (section 12 of the draft) it's possible to have a loopback
> address associated with only one algo, please correct me if I'm missing or
> misunderstood something.
>
>
>
>
>
> Thanks,
>
>
> Yingzhen
>
>
>
>
>
> On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" <
> [email-masked] on behalf of ppsenak=[email-masked]>
> wrote:
>
>
>
>
>
> Gyan,
>
>
>
>
>

*Gyan Mishra*

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 3 Oct 2020 10:20:06 +0200

neighbors?

It is my understanding that those nodes always will become ospf neighbours
as you still run default topology on all of them. I have not seen a case
where flex algo topology can be enabled without default topology.

Thx,
R.

On Sat, Oct 3, 2020 at 2:14 AM Gyan Mishra <[email-masked]> wrote:

>
> Hi  Jeff
>
> From a domain perspective where you have a group of nodes and associated
> IP addressed and SID are part of a discrete underlay instance flex algo

---

From: Peter Psenak <[email-masked]>
Date: Sat, 3 Oct 2020 11:45:39 +0200

Gyan,

On 03/10/2020 02:14, Gyan Mishra wrote:
> 
> Hi  Jeff
> 
>  From a domain perspective where you have a group of nodes and 
> associated IP addressed and SID are part of a discrete underlay instance 
> flex algo topology.  On those same set of nodes you could have another 
> topology and associated address and SIDs for a different flex algo.  

above is right.

> How 
> this would work is that the topologies would have to be segregated from 
> each other as different MT instances or routing process instances.  Is 
> that correct?

no MT at all. You can think of each flex-algo as a set of constraints 
that is used to calculate the path over the common topology. You can 
have many such felx-algos running on a common topology.

absolutely.

Peter

> 
> Kind Regards
> 
> Gyan
> 
> On Fri, Oct 2, 2020 at 6:25 PM Jeff Tantsura <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>     Hi Yingzhen,
> 
> 
> 
> 
> 
>     Yes, that’s the case.  The most important property of an algo
>     computed path is that is has to be consecutive, as either SID or IP
>     address associated with a particular topology is only known within
>     that topology.
> 
> 
>     Looking specifically at Ron’s draft (MPLS could be more complex due
>     to potential hierarchy) - the prefix itself defines the
>     context(topology) and must be globally unique, since IPv4 header
>     can’t have any additional meta-data attached.
> 
> 
> 
> 
> 
> 
> 
>     Cheers,
> 
>     Jeff
> 
> 
> 
> 
> 
> 
>     On Oct 2, 2020, 1:15 PM -0700, Yingzhen Qu
>     <[email-masked] <mailto:[email-masked]>>, wrote:
> 
> 
>>     Hi Peter,
>>
>>
>>
>>
>>
>>     My understanding of flex-algo is that for traffic destined to a
>>     prefix on a particular algo, it can only be routed on routers
>>     belong to that algo, which also means only routers in that algo
>>     calculates how to reach that prefix and install it into the
>>     routing table. It seems to me that using flex-algo (section 12 of
>>     the draft) it's possible to have a loopback address associated
>>     with only one algo, please correct me if I'm missing or
>>     misunderstood something.
>>
>>
>>
>>
>>
>>     Thanks,
>>
>>
>>     Yingzhen
>>
>>
>>
>>
>>
>>     On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak"
>>     <[email-masked] <mailto:[email-masked]> on behalf of
>>     ppsenak=[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>
>>
>>
>>
>>     Gyan,
>>
>>
>>
>>
>>
>>     [email-masked] <mailto:[email-masked]>
>>
>>
> /Network Solutions A//rchitect /
> 
> /M 301 502-1347
> 13101 Columbia Pike
> /Silver Spring, MD
> 
>

---

From: Peter Psenak <[email-masked]>
Date: Sat, 3 Oct 2020 11:47:46 +0200

Hi Yingzhen,

> My understanding of flex-algo is that for traffic destined to a prefix on a particular algo, it can only be routed on routers belong to that algo, which also means only routers in that algo calcula…

you are right. That is exactly what is being done for flex-algo with 
SRv6 - locator is associated with a single algo only. The proposal uses 
the same concept.

thanks,
Peter

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 3 Oct 2020 12:41:18 -0400

> where flex algo topology can be enabled without default topology.

    Gyan>. That is what I was thinking as the algo 0 strict spf as the base
algo to provide reachability to all nodes within the domain and all
neighbors are formed between all nodes in the domain to populate IGP rib
providing base connectivity reachability.  So then underneath of that you
can have any subset of nodes out of the superset all top layer domain nodes
level  that can run any other algo desired. Basically creating algo layers
under the top domain wide layer.

I think I am getting it now! 😀

>>> My understanding of flex-algo is that for traffic destined to a prefix
>>> on a particular algo, it can only be routed on routers belong to that algo,
>> *M 301 502-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver
>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>
>>
>>
>>

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 3 Oct 2020 12:54:35 -0400

Thanks Peter for the responses to help clear up my flex algo understanding!!

> > topology and associated address and SIDs for a different flex algo.

   Gyan>  So per my response to Robert, what  I was thinking is that as the
algo 0 strict spf would be used as the base algo to provide reachability to
all nodes within the domain and all neighbors are formed between all nodes
in the domain to populate IGP rib providing base connectivity
reachability.  So then underneath of that you can have any subset of nodes
out of the superset all top layer domain nodes level  that can run any
other algo desired. Basically creating algo layers under the top domain
wide layer.

> have many such felx-algos running on a common topology.
    Gyan> Is it safe to say that we can think of it as RSVP TE “like” cSPF
constraints that we are build via traffic engineering PCALC algorithms to
run for dynamic LSP dyamic ERO that is built based on IGP constraints from
TEDs database of TE link attributes and TE or IGP weights metric
constraints to create the dynamic LSP path.  So we could think of in TE
framework analogy to flex algo In the per VRF TE next hop vpn coloring use
case with different loopback next hop rewrite per VRF that normal IGP non
TE BAU VPNs traffic would be like the flex algo base strict algo 0 and the
non zero discrete algo would be like the per VRF next hop loopback rewrite
where each per VRF te loopback rewrite would be a different steering non
zero discrete flex algo all running in parallel as ships in the night with
the base algo 0.   Sorry for the complex analogy but I think I am getting
it!!😃

Does a flex algo use case draft exist and if not I would not mind using the
analogy I said above and build out a use case draft.  Cheers! 😊

> >>>     both. Is it possible to have within a single IGP domain different
>
> >>>     sets
>
> >>>
>
> >>>
>
> >>     all participating nodes need to agree on the definition of the
>
> >>     flex-algo
>
> >>
>
> >>
>
> >>>     a way to use multiple algorithms simultaneously based on SFC or
>
> >>>     services
>
> >>>
>
> >>>
>
> >>>     each hop there is a way to specify which algo to use hop by hop
>
> >>>     similar
>
> >>>
>
> >>>
>
> >>     no, there is no hop-by-hop classification, that is problematic and
>
> >>     does
>
> >>
>
> >>
>

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 3 Oct 2020 13:25:51 -0400

I would think Ron’s IP data plane based flex algo would work identical to
SR data plane based flex algo with the base Strict  algo 0 providing top
layer all node reachability and would contain let’s say loopback0.  The
algo would have algo and algo # definition on the loopback so the nodes are
reachability the discrete non zero algo loopback  for the corresponding
loopbacks that correlate with algo xyz for the xyz topology.  In both IP
based algo and the SR based algo would the SR locator or IP based algo be
in the BAU base to layer topology SRv6-BE let’s say and SRv6-TE SLA SRH
steered would map to non zero algorithms per VRF VPN coloring and  would IP
based algo do the same.

The advent of SR came about filling a much needed gap for operators to
provide RSVP TE style per VRF coloring without the added badge of loopback
xyz rewrite for the static route coloring issue that you need a separate
loopback and static route to RSVP tunnel to steer each per VRF per vpn
colored TE tunnel - as you can see with RSVP coloring you have a 1-1
mapping discrete loopback per per VRF steered TE tunnel.

So then along came SR to save the day ..end of story..

Back to flex algo ..so SR has the per VRF coloring capability with SR data
plane to provide the coloring.

I think I maybe confusing to topics as the per VRF TE coloring is using
underlay to steer overlay so flex algo is in the underlay so you could do
the same SR-TE flex algo steering of underlay thereby steering vpn overlay
under pinning of underlay to overlay.

How would that be done with IP based flex algo.

So with IP based flex algo as well you would be global table routing with
no VPN framework.

Thanks

Gyan

On Sat, Oct 3, 2020 at 12:54 PM Gyan Mishra <[email-masked]> wrote:

>    Gyan>  So per my response to Robert, what  I was thinking is that as
> the algo 0 strict spf would be used as the base algo to provide
> reachability to all nodes within the domain and all neighbors are formed
> between all nodes in the domain to populate IGP rib providing base
> connectivity reachability.  So then underneath of that you can have any
> subset of nodes out of the superset all top layer domain nodes level  that
> can run any other algo desired. Basically creating algo layers under the
> top domain wide layer.
>
>>
>>
>>
>> > How
>>
> Does a flex algo use case draft exist and if not I would not mind using
> the analogy I said above and build out a use case draft.  Cheers! 😊
>
>>
>>
>>
>> >
>>

*Gyan Mishra*

---

From: Yingzhen Qu <[email-masked]>
Date: Sat, 3 Oct 2020 18:08:01 +0000

Hi Peter,

Using flex-algo, a SRv6 locator can be associated with a single algo, which means an IPv6 or IPv4 address can also be associated with a single algo. So my understanding is Ron's proposal is making the configuration of flex-algo easier? Instead of using the exclude or include list you can configure a loopback address to a flex-algo directly?

Thanks,
Yingzhen

On 10/3/20, 2:47 AM, "Peter Psenak" <[email-masked]> wrote:

    Hi Yingzhen,

    thanks,
    Peter

    >      https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=02%7C01%7Cyingzhen.qu%40futurewei.com%7Cfe03124c6e414e067c2008d867816541%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637373152739865126&amp;sdata=WI48cEAan%2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g%3D&amp;reserved=0
    > 
    > 
    >

---

From: Ron Bonica <[email-masked]>
Date: Sat, 3 Oct 2020 20:33:30 +0000

Hi Yingzhen,

IP Flexible Algorithms are like SR Flexible Algorithms in the following respects:

- Links have IGP metrics, TE metrics, delay metrics and administrative colors
- FADs define Flexible Algorithms

More specifically, the FAD:

- Indicates which metric type the Flexible Algorithm uses
- Specifies constraints in terms of link colors that are included or excluded from the Flexible Algorithm.

The significant difference between IP Flexible Algorithms and SR Flexible Algorithms is:

- SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators
- IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses.

So, IP Flexible Algorithms can be deployed in any IP network, even in the absence of SR.

                                        Ron

-----Original Message-----
From: Yingzhen Qu <[email-masked]> 
Sent: Saturday, October 3, 2020 2:08 PM
To: Peter Psenak <[email-masked]>; Gyan Mishra <[email-masked]>; Ron Bonica <[email-masked]>
Cc: [email-masked]; Jeff Tantsura <[email-masked]>
Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

Hi Peter,

Thanks,
Yingzhen

    Hi Yingzhen,

    thanks,
    Peter

    >      https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&amp;data=02*7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d867816541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637373152739865126&amp;sdata=WI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9MjimeJcREUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$
    >
    >
    >

---

From: Peter Psenak <[email-masked]>
Date: Sun, 4 Oct 2020 11:51:41 +0200

Hi Gyan,

On 03/10/2020 18:54, Gyan Mishra wrote:
> On Sat, Oct 3, 2020 at 5:45 AM Peter Psenak <[email-masked] 
> subset of nodes out of the superset all top layer domain nodes level 
>   that can run any other algo desired. Basically creating algo layers 

pretty much.

>      Gyan> Is it safe to say that we can think of it as RSVP TE “like” 
> cSPF constraints that we are build via traffic engineering PCALC 
> algorithms to run for dynamic LSP dyamic ERO that is built based on IGP 
> constraints from TEDs database of TE link attributes and TE or IGP 
> weights metric constraints to create the dynamic LSP path.  

you can think of a flex-algo as a TE like solution, but there are some 
major differences to RSVP-TE:

- automatic calculation of flex-algo constrained based paths from any 
source to any destination. This is in contrast to p2p nature of RSVP-TE.

- there is no TED, all information is stored in IGP LSDB.

> So we could 
> think of in TE framework analogy to flex algo In the per VRF TE next hop 
> vpn coloring use case with different loopback next hop rewrite per VRF 
> that normal IGP non TE BAU VPNs traffic would be like the flex algo base 
> strict algo 0 and the non zero discrete algo would be like the per VRF 
> next hop loopback rewrite where each per VRF te loopback rewrite would 
> be a different steering non zero discrete flex algo all running in 
> parallel as ships in the night with the base algo 0.   Sorry for the 
> complex analogy but I think I am getting it!!😃

steering the traffic to flex-algo paths can be done using different 
methods - per-destination, per flow, etc. Various coloring mechanism can 
be used as well, if needed.

> the analogy I said above and build out a use case draft.  Cheers! 😊

I'm not a fan of use case drafts. These should be vendor specific 
documents, no need to make them standards.

thanks,
Peter
>      > On Fri, Oct 2, 2020 at 6:25 PM Jeff Tantsura
>     <[email-masked] <mailto:[email-masked]>
> 
>      > <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >     Hi Yingzhen,
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>>, wrote:
> 
>      >
> 
>      >
> 
>      >>     Hi Peter,
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>> on behalf of
> 
>     <mailto:[email-masked]>
> 
>      >>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>     Gyan,
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
> 
>      >>
> 
>      >>
> 
>      >>

---

From: Peter Psenak <[email-masked]>
Date: Sun, 4 Oct 2020 11:54:49 +0200

Yingzhen,

On 03/10/2020 20:08, Yingzhen Qu wrote:
> Hi Peter,
> 
> Using flex-algo, a SRv6 locator can be associated with a single algo, which means an IPv6 or IPv4 address can also be associated with a single algo. So my understanding is Ron's proposal is making the configuration of flex-algo easier? 

no.

> Instead of using the exclude or include list you can configure a loopback address to a flex-algo directly?

above has been done for SRv6 locators already. Now you can make that 
association for regular ipv4 and ipv6 prefixes.

thanks,
Peter

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 4 Oct 2020 09:48:26 -0400

Thanks Peter!

On Sun, Oct 4, 2020 at 5:51 AM Peter Psenak <[email-masked]> wrote:

> >      > associated IP addressed and SID are part of a discrete underlay
>
> >     instance
>
> >
>
> >      > flex algo topology.  On those same set of nodes you could have
>
> >     another
>
> >
>
> >      > this would work is that the topologies would have to be
>
> >     segregated from
>
> >
>
> >      > each other as different MT instances or routing process
>
> >     instances.  Is
>
> >
>
> >      > that correct?
>
> >
>
> >
>
> >
>
> >      >     computed path is that is has to be consecutive, as either SID
>
> >     or IP
>
> >
>
> >      >     address associated with a particular topology is only known
>
> >     within
>
> >
>
> >      >     that topology.
>
> >
>
> >      >
>
> >
>
> >      >
>
> >
>
> >      >     Looking specifically at Ron’s draft (MPLS could be more
>
> >     complex due
>
> >
>
> >      >>     routing table. It seems to me that using flex-algo (section
>
> >     12 of
>
> >
>
> >      >>>     With SRv6 and IP based flex algo a generic question as it
>
> >     applies to
>
> >
>
> >      >>>
>
> >
>
> >      >>>
>
> >
>
> >      >>>     both. Is it possible to have within a single IGP domain
>
> >     different
>
> >
>
> >      >>>     sets
>
> >
>
> >      >>>
>
> >
>
> >      >>>
>
> >
>
> >      >>>     of nodes or segments of the network running different
>
> >     algorithms.
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>     absolutely.
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>>     From
>
> >
>
> >      >>>
>
> >
>
> >      >>>
>
> >
>
> >      >>>     both drafts it sounds like all nodes have to agree on same
>
> >     algorithm
>
> >
>
> >      >>>
>
> >
>
> >      >>>
>
> >
>
> >      >>>     similar to concept of metric and reference bandwidth all
>
> >     have to have
>
> >
>
> >      >>>
>
> >
>
> >      >>>
>
> >
>
> >      >>>     rendered. Doing so without causing a routing loop or sub
>
> >     optimal
>
> >
>
> >      >>>
>
> >
>
> >      >>>
>
> >
>
> >      >>>     routing.
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>     you can certainly use multiple algorithms simultaneously and
>
> >     use algo
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>     specific paths to forward specific traffic over it. How that
>
> >     is done
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>     from the forwarding perspective depends in which forwarding
>
> >     plane you
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>     use. Flex-algo control plane is independent of the
>
> >     forwarding plane.
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>     no, there is no hop-by-hop classification, that is
>
> >     problematic and
>
> >
>
> >      >>     does
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>     not scale for high speeds. Classification is done at the
>
> >     ingress only.
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>     thanks,
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>     Peter
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>
> >      >>
>
> >
>

*Gyan Mishra*

---

From: Huaimo Chen <[email-masked]>
Date: Tue, 6 Oct 2020 21:57:06 +0000

Hi Authors,

    I have the following comments/questions on the draft.

    In section 2 "Advertisement of SR VTN Topology Attribute",
for the last sentence "..., the Flex-Algo identifier could be reused
as the identifier of the VTN in control plane.",

    How do you reuse the Flex-Algo identifier?
    Does every VTN have a Flex-Algo identifier?
    If so, where does the Flex-Algo identifier of every VTN come from?

    In section 3 "Advertisement of SR VTN Resource Attribute",
    is new flag "V" (Virtual) defined in this draft as an extension to RFC 8668?

    If so, should an IANA request/action in section "IANA Considerations"
be added for this extension?

    If not (i.e., it is defined in another draft),
it is better to remove the definition of flag "V" from
this draft and add a reference to another draft.
    In this case, it seems that there is no IANA request from this draft.
It would be better to change the intended status of the draft from
the standards track to informational.

Some nits:
In section 2, the second sentence of the last paragraph,
should "to used" be changed to "to use"?

In section 3, the first sentence of the second paragraph,
should "was defined to advertise" be changed to
"defines the advertisement of"?

Best Regards,
Huaimo

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 9 Oct 2020 02:59:03 +0000

Hi Ron, 

Thanks for explaining the difference between IP Flex-Algo and SR Flex-algo. As you said, the major difference is the data plane.

If my understanding is correct, for one Flex-Algo to be used correctly, the set of nodes need to apply consistent constraints in computation, and bind the FAD to the same data plane.

Is it possible that different nodes may use the same Flex-Algo with different data plane, e.g. some with SR-MPLS, some with SRv6, and some with pure IP etc., or each Flex-Algo is always associated with only one data plane? In the former case, should the flex-algo definition also indicate the data plane(s) to be used with the flex-algo?

Best regards,
Jie

> From: Lsr [mailto:[email-masked]] On Behalf Of Ron Bonica
> Sent: Sunday, October 4, 2020 4:34 AM
> To: Yingzhen Qu <[email-masked]>; Peter Psenak
> <[email-masked]>; Gyan Mishra <[email-masked]>
> To: Peter Psenak <[email-masked]>; Gyan Mishra
> <[email-masked]>; Ron Bonica <[email-masked]>
> Using flex-algo, a SRv6 locator can be associated with a single algo, which
> means an IPv6 or IPv4 address can also be associated with a single algo. So my
> understanding is Ron's proposal is making the configuration of flex-algo easier?
>     > My understanding of flex-algo is that for traffic destined to a prefix on a
> particular algo, it can only be routed on routers belong to that algo, which also
> means only routers in that algo calculates how to reach that prefix and install
> it into the routing table. It seems to me that using flex-algo (section 12 of the
> draft) it's possible to have a loopback address associated with only one algo,
> please correct me if I'm missing or misunderstood something.
> 
> <[email-masked] on behalf of ppsenak=[email-masked]>
> wrote:
>     >
>     >      Gyan,
>     >
> https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/
> ?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&amp;data=02
> *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d86781
> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986
> 5126&amp;sdata=WI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D
> &amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9MjimeJcR
> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$
>     >
>     >
>     >
>

---

From: <[email-masked]>
Date: Fri, 9 Oct 2020 14:32:44 +0800

Hi Huaimo, 

Thanks for your review comments, please see some replies inline with [YQ]:

发件人: Lsr <[email-masked]> 代表 Huaimo Chen
发送时间: 2020年10月7日 5:57
收件人: [email-masked]
主题: [Lsr] draft-zhu-lsr-isis-sr-vtn-flexalgo-01

Hi Authors,

[YQ] The “reuse” here means to make use of the existing Flex-Algo
identifier to represent VTN, rather than defining a new identifier. 

[YQ] Yes, every VTN needs to be represented with a unique Flex-Algo
identifier. The Flex-Algo identifier comes from network planning. 

    is new flag "V" (Virtual) defined in this draft as an extension to RFC
8668?

[YQ] Yes, this is an extension to RFC 8668. 

[YQ] Currently there is no IANA registry for the flags of L2 Bundle Member
Attributes TLV defined in RFC 8668, thus this new flag is described in the
text only. While a new registry may be created if the WG believe it is
helpful. 

[YQ] As explained above, a new flag is proposed in this document, thus it is
appropriate to make it standard track.

Some nits: 

  [YQ] Thanks for catching the nits, we will fix them in next revision. 

Best regards,

Yongqing Zhu

Best Regards,

Huaimo

---

From: Peter Psenak <[email-masked]>
Date: Fri, 9 Oct 2020 17:57:39 +0200

Hi Jimmy,

> Is it possible that different nodes may use the same Flex-Algo with different data plane, e.g. some with SR-MPLS, some with SRv6, and some with pure IP etc., or each Flex-Algo is always associated…

let me respond to this query, as this is not specific to Ron's draft.

FAD is data plane agnostic and is used by all of them.

thanks,
Peter

---

From: Ron Bonica <[email-masked]>
Date: Fri, 9 Oct 2020 17:12:41 +0000

+1

-----Original Message-----
From: Peter Psenak <ppsenak=[email-masked]> 
Sent: Friday, October 9, 2020 11:58 AM
To: Dongjie (Jimmy) <[email-masked]>; Ron Bonica <[email-masked]>; Yingzhen Qu <[email-masked]>; Gyan Mishra <[email-masked]>
Cc: [email-masked]; Jeff Tantsura <[email-masked]>
Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

Hi Jimmy,

thanks,
Peter

>> Using flex-algo, a SRv6 locator can be associated with a single algo, 
>> which means an IPv6 or IPv4 address can also be associated with a 
>> single algo. So my understanding is Ron's proposal is making the configuration of flex-algo easier?
>> Instead of using the exclude or include list you can configure a 
>> loopback address to a flex-algo directly?
>>
>> Thanks,
>> Yingzhen
>>
>>      > My understanding of flex-algo is that for traffic destined to 
>> a prefix on a particular algo, it can only be routed on routers 
>> calculates how to reach that prefix and install it into the routing 
>> table. It seems to me that using flex-algo (section 12 of the
>> draft) it's possible to have a loopback address associated with only 
>> one algo, please correct me if I'm missing or misunderstood something.
>>
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr
>> __;!!NEt6yMaO-gk!S3DZGr_DbCQIRsnq2hAgAtb2RlxErvd8T0WG7VHv21jDFU_ZFDhw
>> h7qVM_VUOLgJ$
>
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sat, 10 Oct 2020 03:05:34 +0000

Hi Peter, 

Thanks for your reply. It aligns with my understanding of FAD, which is just a set of constraints for path computation. Thus one Flex-Algo ID could be used with multiple different data planes. Is this understanding correct?

If so, my question is about the scenario below: 

A group of nodes in a network support FA-128, a sub-group of them bind FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address. When one node compute an SR path to a destination, can it compute the path to only pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes which bind FA-128 to IP address? If so, how could this node know the binding of FA to different data planes on other nodes?

Best regards,
Jie

> From: Lsr [mailto:[email-masked]] On Behalf Of Peter Psenak
> Sent: Friday, October 9, 2020 11:58 PM
> To: Dongjie (Jimmy) <[email-masked]>; Ron Bonica
> <rbonica=[email-masked]>; Yingzhen Qu
> <[email-masked]>; Gyan Mishra <[email-masked]>
> > Thanks for explaining the difference between IP Flex-Algo and SR Flex-algo. As
> you said, the major difference is the data plane.
> >
> > If my understanding is correct, for one Flex-Algo to be used correctly, the set
> of nodes need to apply consistent constraints in computation, and bind the FAD
> to the same data plane.
> >
> > Is it possible that different nodes may use the same Flex-Algo with different
> data plane, e.g. some with SR-MPLS, some with SRv6, and some with pure IP
> etc., or each Flex-Algo is always associated with only one data plane? In the
> former case, should the flex-algo definition also indicate the data plane(s) to be
> used with the flex-algo?
> 
> applies
> >> to
> have to
> >> have
> >>      >      > a way to use multiple algorithms simultaneously based on
> SFC
> >> or services
> use
> >> algo
> >> ?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&amp;data=
> 0
> >> 2
> >>

---

From: Ron Bonica <[email-masked]>
Date: Sat, 10 Oct 2020 12:47:49 +0000

Hi Jimmie,

Inline.....

                    Ron

-----Original Message-----
From: Dongjie (Jimmy) <[email-masked]> 
Sent: Friday, October 9, 2020 11:06 PM
To: Peter Psenak <[email-masked]>; Ron Bonica <[email-masked]>; Yingzhen Qu <[email-masked]>; Gyan Mishra <[email-masked]>
Cc: [email-masked]; Jeff Tantsura <[email-masked]>
Subject: RE: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

Hi Peter,

[RB] I never thought about this. Is there a use-case? I think that it will work, but I would have to try it before saying for sure.

A group of nodes in a network support FA-128, a sub-group of them bind FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address. When one node compute an SR path to a destination, can it compute the path to only pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes which bind FA-128 to IP address? 

[RB] I don't think so. However, you could achieve the same outcome using link colors.

If so, how could this node know the binding of FA to different data planes on other nodes?

Best regards,
Jie

> of nodes need to apply consistent constraints in computation, and bind 
> the FAD to the same data plane.
> >
> data plane, e.g. some with SR-MPLS, some with SRv6, and some with pure 
> IP etc., or each Flex-Algo is always associated with only one data 
> plane? In the former case, should the flex-algo definition also 
> indicate the data plane(s) to be used with the flex-algo?
>
> >> IP Flexible Algorithms are like SR Flexible Algorithms in the 
> >> following
> respects:
> >>
> >> Using flex-algo, a SRv6 locator can be associated with a single 
> >> algo, which means an IPv6 or IPv4 address can also be associated 
> >> with a single algo. So my understanding is Ron's proposal is making 
> >> the
> configuration of flex-algo easier?
> >>      > My understanding of flex-algo is that for traffic destined 
> >> to a prefix on a particular algo, it can only be routed on routers 
> >> draft) it's possible to have a loopback address associated with 
> >> only one algo, please correct me if I'm missing or misunderstood something.
> >>
> >> https://urldefense.com/v3/__https://nam11.safelinks.protection.outl
> >> oo
> >> k.com/
> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l
> >> sr__;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_H
> >> z218CE8S8XzlIxAA$
> >
> >
>
> _;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_Hz218CE
> 8S8XzlIxAA$

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 10 Oct 2020 12:13:38 -0700

Jie,

The scoop is different, for SR data plane entry uniqueness is in context of SR domain (SID = value + context),
while for IP it is global to the routing domain, FIB entry is a destination, nothing more.

Regards,
Jeff

> On Oct 10, 2020, at 05:47, Ron Bonica <[email-masked]> wrote:
> 
> Hi Jimmie,
> 
> Inline.....
> 
>                    Ron
> 
>

---

From: Ron Bonica <[email-masked]>
Date: Sun, 11 Oct 2020 16:41:47 +0000

Jeff,

I think that you mean the scope is different..... 

                                     Ron

-----Original Message-----
From: Jeff Tantsura <[email-masked]> 
Sent: Saturday, October 10, 2020 3:14 PM
To: Ron Bonica <[email-masked]>
Cc: Dongjie (Jimmy) <[email-masked]>; Peter Psenak <[email-masked]>; Yingzhen Qu <[email-masked]>; Gyan Mishra <[email-masked]>; [email-masked]
Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

Jie,

The scoop is different, for SR data plane entry uniqueness is in context of SR domain (SID = value + context), while for IP it is global to the routing domain, FIB entry is a destination, nothing more.

Regards,
Jeff

> To: Peter Psenak <[email-masked]>; Ron Bonica 
> <[email-masked]>; Yingzhen Qu <[email-masked]>; Gyan 
> Mishra <[email-masked]>
>> of nodes need to apply consistent constraints in computation, and 
>> bind the FAD to the same data plane.
>>>
>> data plane, e.g. some with SR-MPLS, some with SRv6, and some with 
>> pure IP etc., or each Flex-Algo is always associated with only one 
>> data plane? In the former case, should the flex-algo definition also 
>>>>> is
>>>>>> I thought with flex algo that there exists a feature that on each 
>>>>>> hop there is a way to specify which algo to use hop by
>> hop
>>>> similar
>> _

---

From: Jeff Tantsura <[email-masked]>
Date: Sun, 11 Oct 2020 10:38:37 -0700

Thanks Ron, indeed!  Autocorrect works in mysterious ways  ;-)

Regards,
Jeff

> On Oct 11, 2020, at 09:41, Ron Bonica <[email-masked]> wrote:
> 
> Jeff,
>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 11 Oct 2020 14:21:27 -0400

Jeff

So basically as SR Flex Algo uses SR data plane (SID ,context) uniqueness
for SR-MPLS label uniqueness and SRv6 Locator uniqueness as compare to IP
Flex Algo IP Data plane is destination prefix based.

So you could literally have both IP flex algo and SR flex also data plane
as mutually exclusive data plane work in parallel as two ships in the
night.

SRv6 uses Longest prefix match and in SRv6-BE w/o SRH which would be
destination based IP and SRv6-BE in parallel to IP Flex algo would not work
as they would collide on the IPv6 data plane.

Kind Regards

Gyan

On Sun, Oct 11, 2020 at 1:38 PM Jeff Tantsura <[email-masked]>
wrote:

> > Cc: Dongjie (Jimmy) <[email-masked]>; Peter Psenak <
> [email-masked]>; Yingzhen Qu <[email-masked]>; Gyan Mishra <
> [email-masked]>; [email-masked]
> > The scoop is different, for SR data plane entry uniqueness is in context
> of SR domain (SID = value + context), while for IP it is global to the
> routing domain, FIB entry is a destination, nothing more.
> >
> > Regards,
> > Jeff
> >
> >> Thanks for your reply. It aligns with my understanding of FAD, which is
> just a set of constraints for path computation. Thus one Flex-Algo ID could
> be used with multiple different data planes. Is this understanding correct?
> >>
> >> [RB] I never thought about this. Is there a use-case? I think that it
> will work, but I would have to try it before saying for sure.
> >>
> >> A group of nodes in a network support FA-128, a sub-group of them bind
> FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address.
> When one node compute an SR path to a destination, can it compute the path
> to only pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes
> which bind FA-128 to IP address?
> >>
-- 

*Gyan Mishra*

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 11 Oct 2020 18:23:23 +0000

Or possibly the prospect of Flex Algo flavors made you hungry ;^0. 

Acee

On 10/11/20, 1:39 PM, "Lsr on behalf of Jeff Tantsura" <[email-masked] on behalf of [email-masked]> wrote:

    Regards,
    Jeff

---

From: Jeff Tantsura <[email-masked]>
Date: Sun, 11 Oct 2020 14:05:54 -0700

Gyan,

In simple terms - destination lookup would yield a SID (stack) for SR or next-hop/adj for IP. For SR, no transport device in between should try to derive/evaluate context (source based routing - once you are in the tunnel), in IP case - every device will evaluate (per hop routing) the destination. As long as the destination lookup result is unambiguous, any combination of algo's could be used.

In SR easy days we (large radio vendor :)) were considering using a set of loopbacks per virtual topology as a poor-man’s slicing in MBH, where PCE would perform “slicing” and FEC2tunnel mapping over flat routing domain, perceived too complex ended up with some other ways of mapping.
Flex algo provides an easier (because distributed + additional meta-data, algo = context) way of light virtualization as compared to MT and/or fully centralized solutions.

Wrt SRv6 vs IPv6 (algo is irrelevant here), I’d assume there’s no conflict, however would leave to the implementors to comment.

Cheers,
Jeff

P.S. Acee - nothing gets me more excited than algo 201 with chocolate over it ;-)
On Oct 11, 2020, 11:21 AM -0700, Gyan Mishra <[email-masked]>, wrote:
>
> Jeff
>
> So basically as SR Flex Algo uses SR data plane (SID ,context) uniqueness for SR-MPLS label uniqueness and SRv6 Locator uniqueness as compare to IP Flex Algo IP Data plane is destination prefix based.
>
> So you could literally have both IP flex algo and SR flex also data plane as mutually exclusive data plane work in parallel as two ships in the night.
>
> SRv6 uses Longest prefix match and in SRv6-BE w/o SRH which would be destination based IP and SRv6-BE in parallel to IP Flex algo would not work as they would collide on the IPv6 data plane.
>
> Kind Regards
>
> Gyan
>
> > On Sun, Oct 11, 2020 at 1:38 PM Jeff Tantsura <[email-masked]> wrote:
> Gyan Mishra
> Network Solutions Architect
> M 301 502-1347
> 13101 Columbia Pike
> Silver Spring, MD
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 12 Oct 2020 06:53:22 +0000

Hi Ron, 

Please see inline:

> From: Ron Bonica [mailto:[email-masked]]
> Sent: Saturday, October 10, 2020 8:48 PM
> To: Dongjie (Jimmy) <[email-masked]>; Peter Psenak
> <[email-masked]>; Yingzhen Qu <[email-masked]>; Gyan
> To: Peter Psenak <[email-masked]>; Ron Bonica <[email-masked]>;
> Yingzhen Qu <[email-masked]>; Gyan Mishra
> <[email-masked]>
> Thanks for your reply. It aligns with my understanding of FAD, which is just a set
> of constraints for path computation. Thus one Flex-Algo ID could be used with
> multiple different data planes. Is this understanding correct?
> 
> [RB] I never thought about this. Is there a use-case? I think that it will work,
> but I would have to try it before saying for sure.

One possible case is to define one Flex-Algo (say FA-128) with delay metric and no admin-group (color) constraints. Then as Flex-Algo is data plane agnostic, FA-128 could be used to bind to prefix-SIDs, SRv6 locators or IP addresses.

> A group of nodes in a network support FA-128, a sub-group of them bind FA-128
> to SR SIDs, another sub-group of them bind FA-128 to IP address. When one
> node compute an SR path to a destination, can it compute the path to only pass
> the nodes which bind FA-128 to SR SIDs, and avoid the nodes which bind FA-128
> to IP address?
> 

Do you mean to use different link colors to identify links with different data plane enabled? I believe it would work, while actually this is using different Flex-Algos (with different color constraints) for different data plane. 

Best regards,
Jie

> > >>      >      > and instantiation of specific algorithm based on service
> to
> > be
> > >> plane.
> > >>      >      > each hop there is a way to specify which algo to use hop
> by
> > hop
> > >> similar
> problematic
> > and

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 12 Oct 2020 07:12:30 +0000

Hi Jeff,

Thanks for your explanation. I understand that for different data plane the SIDs or IP addresses have different scope, and will not conflict in normal cases.

My question is more about whether a computation node needs to know and check which data plane is used by the intermediate nodes to bind to the Flex-Algo? In another word, can an SR path computed using Flex-Algo 128 go through an intermediate node which bind Flex-Algo 128 to IP data plane?

Best regards,
Jie

> From: Jeff Tantsura [mailto:[email-masked]]
> Sent: Sunday, October 11, 2020 3:14 AM
> Cc: Dongjie (Jimmy) <[email-masked]>; Peter Psenak
> Mishra <[email-masked]>; [email-masked]
> The scoop is different, for SR data plane entry uniqueness is in context of SR
> domain (SID = value + context), while for IP it is global to the routing domain,
> FIB entry is a destination, nothing more.
> 
> Regards,
> Jeff
> 
> > Thanks for your reply. It aligns with my understanding of FAD, which is just a
> set of constraints for path computation. Thus one Flex-Algo ID could be used
> with multiple different data planes. Is this understanding correct?
> >
> FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address. When
> one node compute an SR path to a destination, can it compute the path to only
> pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes which bind
> FA-128 to IP address?
> >
> _;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_Hz2
> 18C
> >> E
> >> 8S8XzlIxAA$

---

From: Peter Psenak <[email-masked]>
Date: Mon, 12 Oct 2020 10:39:13 +0200

Hi Jimmy,

> Thanks for your reply. It aligns with my understanding of FAD, which is just a set of constraints for path computation. Thus one Flex-Algo ID could be used with multiple different data planes. Is t…

correct.

> A group of nodes in a network support FA-128, a sub-group of them bind FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address. 

just to use the correct terminology, we should use "participate" instead 
of "support".

>When one node compute an SR path to a destination, can it compute the path to only pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes >which bind FA-128 to IP address? If so, how could this node know the binding of FA to different data planes on other nodes?

again, it is the participation problem.

Nodes that participate in the SR Flex-algo 128 will advertise the 
participation using the SR-Algorithm Sub-TLV. Only these nodes will be 
used during the SR flex-algo computation for algo 128.

Nodes that participate in IP flex-algo 128 will advertise the 
participation using the IGP Algorithm Sub-TLV. Only these nodes will be 
used during the IP flex-algo computation for algo 128.

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Mon, 12 Oct 2020 10:41:08 +0200

Ho Ron,

> [RB] I never thought about this. Is there a use-case? I think that it will work, but I would have to try it before saying for sure.

yes, this works fine.

> [RB] I don't think so. However, you could achieve the same outcome using link colors.

please see my response to the Jimmy.

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Mon, 12 Oct 2020 10:47:28 +0200

Hi Jimmy.

> My question is more about whether a computation node needs to know and check which data plane is used by the intermediate nodes to bind to the Flex-Algo? In another word, can an SR path computed us…

computation node MUST check the application specific participation in 
flex-algo and participation advertisement is application specific. SR 
and IP are different applications from flex-algo perspective.

draft-ietf-lsr-flex-algo-12, section 10.2:

    Application-specific advertisement for Flex-Algorithm participation
    MUST be defined for each application

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 12 Oct 2020 13:50:10 +0200

Hey Peter,

To me the application here is "avoid red links" regardless of choice of
encap in the data plane.

Does it really make sense to separate advertisements of SR flex-algo vs IP
flex-algo into separate TLVs ?

Along the same linkes even for SR data plane can be SR-MPLS or SRv6. So in
the network running all three data planes you will need to compute SPT for
each flex-algo three times which may or may not be desired especially if
each algorithm would be as simple as to avoid certain link color.

That goes to the point can dataplanes interwork in flex algo and it seems
that currently they can not if section 10.2 is interpreted as application
to be a tuple of data plane + topological constraints (instead of only
topological constraints).

Thx,
R.

On Mon, Oct 12, 2020 at 10:47 AM Peter Psenak <ppsenak=
[email-masked]> wrote:

> > Thanks for your explanation. I understand that for different data plane
> the SIDs or IP addresses have different scope, and will not conflict in
> normal cases.
> >
> > My question is more about whether a computation node needs to know and
> check which data plane is used by the intermediate nodes to bind to the
> Flex-Algo? In another word, can an SR path computed using Flex-Algo 128 go
> through an intermediate node which bind Flex-Algo 128 to IP data plane?
>
> will work,
> When
> >>> [RB] I don't think so. However, you could achieve the same outcome
> using link
> >> colors.
> >>>
> >>> If so, how could this node know the binding of FA to different data
> planes on
> >> other nodes?
> >>>
> >>> Best regards,
> >>> Jie
> >>>
> >>>>>>      SRv6 - locator is associated with a single algo only. The
> proposal
> >> uses
> >>>>>>      the same concept.
> >>>>>>
> >>>>>>      thanks,
> >>>>>>      Peter
> >>>>>>
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Yingzhen
> >>>>>>>

---

From: Peter Psenak <[email-masked]>
Date: Mon, 12 Oct 2020 14:02:20 +0200

Robert,

On 12/10/2020 13:50, Robert Raszuk wrote:
> Does it really make sense to separate advertisements of SR flex-algo vs 
> IP flex-algo into separate TLVs ?

yes, please look at the base flex-algo spec. Each app must signal 
participation independently, as it may use a completely different data 
plane and one can not assume that all data planes are supported on any 
particular node. Think of BIER, etc. They may want to use flex-algo. I 
can not assume that a node running SR is capable of forwarding BIER packets.

> 
> Along the same linkes even for SR data plane can be SR-MPLS or SRv6. So 
> in the network running all three data planes you will need to compute 
> SPT for each flex-algo three times which may or may not be desired 
> especially if each algorithm would be as simple as to avoid certain link 
> color.
> 
> That goes to the point can dataplanes interwork in flex algo and it 
> seems that currently they can not if section 10.2 is interpreted as 
> application to be a tuple of data plane + topological constraints 
> (instead of only topological constraints).

application is orthogonal to constraints, constraints (e.g. FAD) is app 
independent.

Participation in flex-algo is app specific.

thanks,
Peter

> 
> Thx,
> R.
> 
> 
> 
> 
> 
> 
> 
> On Mon, Oct 12, 2020 at 10:47 AM Peter Psenak 
> <ppsenak=[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
>     Hi Jimmy.
> 
>      > Thanks for your explanation. I understand that for different data
>     plane the SIDs or IP addresses have different scope, and will not
>     conflict in normal cases.
>      >
>      > My question is more about whether a computation node needs to
>     know and check which data plane is used by the intermediate nodes to
>     bind to the Flex-Algo? In another word, can an SR path computed
>     using Flex-Algo 128 go through an intermediate node which bind
>     Flex-Algo 128 to IP data plane?
> 
>      >> From: Jeff Tantsura [mailto:[email-masked]
>     <mailto:[email-masked]>]
>      >> To: Ron Bonica <[email-masked] <mailto:[email-masked]>>
>      >> Cc: Dongjie (Jimmy) <[email-masked]
>     <mailto:[email-masked]>>; Peter Psenak
>      >> <[email-masked] <mailto:[email-masked]>>; Yingzhen Qu
>     <[email-masked] <mailto:[email-masked]>>; Gyan
>      >> Mishra <[email-masked] <mailto:[email-masked]>>;
>     [email-masked] <mailto:[email-masked]>
>      >>> On Oct 10, 2020, at 05:47, Ron Bonica <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >>>
>      >>> Hi Jimmie,
>      >>>
>      >>> Inline.....
>      >>>
>      >>>                     Ron
>      >>>
>      >>>
>      >>> From: Dongjie (Jimmy) <[email-masked]
>     <mailto:[email-masked]>>
>      >>> To: Peter Psenak <[email-masked]
>     <mailto:[email-masked]>>; Ron Bonica
>      >>> <[email-masked] <mailto:[email-masked]>>; Yingzhen Qu
>     <[email-masked] <mailto:[email-masked]>>; Gyan
>      >>> Mishra <[email-masked] <mailto:[email-masked]>>
>      >>> Cc: [email-masked] <mailto:[email-masked]>; Jeff Tantsura
>     <[email-masked] <mailto:[email-masked]>>
>      >>> [RB] I don't think so. However, you could achieve the same
>     outcome using link
>      >> colors.
>      >>>
>      >>> If so, how could this node know the binding of FA to different
>     data planes on
>      >> other nodes?
>      >>>
>      >>> Best regards,
>      >>> Jie
>      >>>
>      >>>> From: Lsr [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Peter Psenak
>      >>>> To: Dongjie (Jimmy) <[email-masked]
>     <mailto:[email-masked]>>; Ron Bonica
>     <mailto:[email-masked]>>; Yingzhen Qu
>      >>>> <[email-masked]
>     <mailto:[email-masked]>>; Gyan Mishra
>     <[email-masked] <mailto:[email-masked]>>
>      >>>> Cc: [email-masked] <mailto:[email-masked]>; Jeff Tantsura
>     <[email-masked] <mailto:[email-masked]>>
>      >>>>> Is it possible that different nodes may use the same
>     Flex-Algo with
>      >>>>> different
>      >>>>>> From: Lsr [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Ron Bonica
>      >>>>>> To: Yingzhen Qu <[email-masked]
>     <mailto:[email-masked]>>; Peter Psenak
>      >>>>>> <[email-masked] <mailto:[email-masked]>>; Gyan Mishra
>     <[email-masked] <mailto:[email-masked]>>
>      >>>>>> Cc: [email-masked] <mailto:[email-masked]>; Jeff Tantsura
>     <[email-masked] <mailto:[email-masked]>>
>      >>>>>> - Specifies constraints in terms of link colors that are
>     included
>      >>>>>> or excluded from the Flexible Algorithm.
>      >>>>>>
>      >>>>>> So, IP Flexible Algorithms can be deployed in any IP
>     network, even
>      >>>>>> in the absence of SR.
>      >>>>>>
>      >>>>>>                                          Ron
>      >>>>>>
>      >>>>>>
>      >>>>>> From: Yingzhen Qu <[email-masked]
>     <mailto:[email-masked]>>
>      >>>>>> To: Peter Psenak <[email-masked]
>     <mailto:[email-masked]>>; Gyan Mishra
>      >>>>>> <[email-masked] <mailto:[email-masked]>>; Ron
>     Bonica <[email-masked] <mailto:[email-masked]>>
>      >>>>>> Cc: [email-masked] <mailto:[email-masked]>; Jeff Tantsura
>     <[email-masked] <mailto:[email-masked]>>
>      >>>>>> On 10/3/20, 2:47 AM, "Peter Psenak" <[email-masked]
>     routing
>      >>>>>>      SRv6 - locator is associated with a single algo only.
>     The proposal
>      >> uses
>      >>>>>>      the same concept.
>      >>>>>>
>      >>>>>>      thanks,
>      >>>>>>      Peter
>      >>>>>>
>      >>>>>>>
>      >>>>>>> Thanks,
>      >>>>>>> Yingzhen
>      >>>>>>>
>      >>>>>> k.com/ <http://k.com/>
>      >>>>>> ?url=https*3A*2F*2Fwww.ietf.org
>     <http://2Fwww.ietf.org>*2Fmailman*2Flistinfo*2Flsr&amp;data
>      >>>>>> =
>      >>>> 0
>      >>>>>> 2
>      >>>>>>
>      >>>>
>      >> *7C01*7Cyingzhen.qu*40futurewei.com
>     <http://40futurewei.com>*7Cfe03124c6e414e067c2008d86781
>      >>>>>>
>      >>>>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 12 Oct 2020 23:38:29 -0400

Hi Jeff

Thanks for the detailed analysis and explanation comparison of SR & IP Flex
Algo.

Please see in-line

Me like Flex Algo covered in Chocolate. 😂
On Sun, Oct 11, 2020 at 5:06 PM Jeff Tantsura <[email-masked]>
wrote:

> Gyan,
>
> In simple terms - destination lookup would yield a SID (stack) for SR or
> next-hop/adj for IP. For SR, no transport device in between should try to
> derive/evaluate context (source based routing - once you are in the
> tunnel), in IP case - every device will evaluate (per hop routing) the
> destination. As long as the destination lookup result is unambiguous, any
> combination of algo's could be used.
>

   Gyan> So with SR-MPLS as long as there is a
SR-TE binding sid policy and you are in the tunnel the middle transport
routers will evaluate flex algo context, Unless flex algo is called out on
a candidate path.  IP based can really fully take advantage hop by hop as
compared to SR-MPLS.

>
>
> In SR easy days we (large radio vendor :)) were considering using a set of
> loopbacks per virtual topology as a poor-man’s slicing in MBH, where PCE
> would perform “slicing” and FEC2tunnel mapping over flat routing domain,
> perceived too complex ended up with some other ways of mapping.
> Flex algo provides an easier (because distributed + additional meta-data,
> algo = context) way of light virtualization as compared to MT and/or fully
> centralized solutions.
>

    Gyan> I think the poor mans slicing pre advent of SR paradigm was
complex with the FEC2Tunnel mapping “Per VRF TE”coloring which required a
discrete FEC loopback for next hop rewrite with static route with tunnel
next hop crude rudimentary way of transport slicing.

Good point that the issues with the complexity and painful FEC to tunnel
mapping lead to development of both SR stateless intent based FEC to tunnel
coloring along with as you mentioned how gap was as well filled with Flex
Algo.

I really like the light weight simple aspects of flex algo, however has the
requirement of SR data plane until Ron’s much needed draft came out.

Did MT ever really take off in providing a means of network slicing?

Kind Regards

Gyan

>
>
> Wrt SRv6 vs IPv6 (algo is irrelevant here), I’d assume there’s no
> conflict, however would leave to the implementors to comment.
>
> Cheers,
> Jeff
>
>> [email-masked]>; Yingzhen Qu <[email-masked]>; Gyan Mishra
>> <[email-masked]>; [email-masked]
>> > The scoop is different, for SR data plane entry uniqueness is in
>> context of SR domain (SID = value + context), while for IP it is global to
>> the routing domain, FIB entry is a destination, nothing more.
>> >
>> > Regards,
>> > Jeff
>> >
>> >> Thanks for your reply. It aligns with my understanding of FAD, which
>> is just a set of constraints for path computation. Thus one Flex-Algo ID
>> could be used with multiple different data planes. Is this understanding
>> correct?
>> >>
>> using link colors.
>> planes on other nodes?
>> proposal uses
> *M 301 502-1347 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g> *Silver
> Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g>
>
> --

*Gyan Mishra*

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 13 Oct 2020 08:02:40 +0000

Hi Peter, 

Thanks for your reply. Please see further inline:

> Sent: Monday, October 12, 2020 4:39 PM
> just to use the correct terminology, we should use "participate" instead of
> "support".

Agree.

> to only pass the nodes which bind FA-128 to SR SIDs, and avoid the
> nodes >which bind FA-128 to IP address? If so, how could this node know the
> binding of FA to different data planes on other nodes?
> 
> Nodes that participate in the SR Flex-algo 128 will advertise the participation
> using the SR-Algorithm Sub-TLV. Only these nodes will be used during the SR
> flex-algo computation for algo 128.
> 
> Nodes that participate in IP flex-algo 128 will advertise the participation using
> the IGP Algorithm Sub-TLV. Only these nodes will be used during the IP flex-algo
> computation for algo 128.

Agree that if participation to Flex-Algo is advertised in a data plane specific manner, then path computation with Flex-Algo constraints could be done only using nodes which bind the Flex-Algo to the same data plane. 

As Robert asked and you confirmed, this implies each data plane needs to be treated as an independent application of Flex-Algo. We have SR-Algorithm sub-TLV and IP Algorithm sub-TLV, while there are actually more data planes to be considered: SR-MPLS, SRv6, IPv4, IPv6, etc., does this mean that Flex-Algo participation needs to be advertised for SR-MPLS, SRv6, IPv4, IPv6, etc. separately?

Best regards,
Jie

> >>>>       >      > each hop there is a way to specify which algo to use
> hop by
> >> hop
> >>>> similar

---

From: Peter Psenak <[email-masked]>
Date: Tue, 13 Oct 2020 10:52:43 +0200

Hi Jimmy,

> Agree that if participation to Flex-Algo is advertised in a data plane specific manner, then path computation with Flex-Algo constraints could be done only using nodes which bind the Flex-Algo to t…

it's per app, not per data plane, but yes, that is what the base 
flex-algo spec mandates.

> As Robert asked and you confirmed, this implies each data plane needs to be treated as an independent application of Flex-Algo. We have SR-Algorithm sub-TLV and IP Algorithm sub-TLV, while there ar…

yes, it needs to be advertised per app. We have SR specific algo 
participation, we need one for IP as proposed in Ron's draft.

Regarding IPv4 vs IPv6, it's up to the authors whether they want to make 
the participation for IP flex-algo topology specific or topology 
independent, both could work.

Here's the text from the base flerx-algo draft:

10.2.  Advertisement of Node Participation for Other Applications

    This section describes considerations related to how other
    applications can advertise their participation in a specific Flex-
    Algorithm.

    Application-specific Flex-Algorithm participation advertisements MAY
    be topology specific or MAY be topology independent, depending on the
    application itself.

    Application-specific advertisement for Flex-Algorithm participation
    MUST be defined for each application and is outside of the scope of
    this document.

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 13 Oct 2020 13:38:05 +0200

Peter,

If this is per app how are the constraints shared across apps ?

See we have single physical resources (for example links) and single
interface outbound queues. If I use per app flex-algo and do not have
central controller how is this going to work in practice for any network
which attempts to use more then one forwarding schema with dynamic
constraints ?

Many thx,
R.

On Tue, Oct 13, 2020 at 10:52 AM Peter Psenak <ppsenak=
[email-masked]> wrote:

> is just a
> participation
> participation using
> > Agree that if participation to Flex-Algo is advertised in a data plane
> specific manner, then path computation with Flex-Algo constraints could be
> done only using nodes which bind the Flex-Algo to the same data plane.
>
> > As Robert asked and you confirmed, this implies each data plane needs to
> be treated as an independent application of Flex-Algo. We have SR-Algorithm
> sub-TLV and IP Algorithm sub-TLV, while there are actually more data planes
> to be considered: SR-MPLS, SRv6, IPv4, IPv6, etc., does this mean that
> Flex-Algo participation needs to be advertised for SR-MPLS, SRv6, IPv4,
> IPv6, etc. separately?
>
> >>>>>>        >      > both drafts it sounds like all nodes have to agree
> on
> >> same
> >>>>>> algorithm
> >>>>>>        >      all participating nodes need to agree on the
> definition of
> >> the
> >>>>>> flex-algo
> >>>>>>        >      > a way to use multiple algorithms simultaneously
> based
> >> on
> >>>> SFC
> >>>>>> or services
> >>>>>>        >      > rendered.  Doing so without causing a routing loop
> or
> >> sub
> >>>>>> optimal
> >>>>>>        >      > routing.
> >>>>>>        >
> >>>>>>        >      you can certainly use multiple algorithms
> simultaneously
> >> and
> >>>> use
> >>>>>> algo
> >>>>>>        >      >I thought with flex algo that there exists a feature
> that
> >> on

---

From: Peter Psenak <[email-masked]>
Date: Tue, 13 Oct 2020 13:54:54 +0200

Robert,

> If this is per app how are the constraints shared across apps ?

FAD constraints are only used for calculating the flex-algo path.

> which attempts to use more then one forwarding schema with dynamic 

flex-algo defines the way to calculate constraint based paths in a 
distributed manner and guarantees the loop free forwarding over such path.

Possible per app and/or per algo resource allocation at each hop is not 
something that flex-algo spec attempts to solve. That does not mean it 
is not possible. I don't see anything in the flex-algo spec that would 
prevent one to do that.

thanks,
Peter

> 
> Many thx,
> R.
> 
> 
> 
> On Tue, Oct 13, 2020 at 10:52 AM Peter Psenak 
>      > Agree that if participation to Flex-Algo is advertised in a data
>     plane specific manner, then path computation with Flex-Algo
>     constraints could be done only using nodes which bind the Flex-Algo
>     to the same data plane.
> 
>      > As Robert asked and you confirmed, this implies each data plane
>     needs to be treated as an independent application of Flex-Algo. We
>     have SR-Algorithm sub-TLV and IP Algorithm sub-TLV, while there are
>     actually more data planes to be considered: SR-MPLS, SRv6, IPv4,
>     IPv6, etc., does this mean that Flex-Algo participation needs to be
>     advertised for SR-MPLS, SRv6, IPv4, IPv6, etc. separately?
> 
>      >>>>>>        > Hi Peter,
>      >>>>>>        > My understanding of flex-algo is that for traffic
>     destined
>      >>>>>>        > Thanks,
>      >>>>>>        > Yingzhen
>      >>>>>>        > On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak"
>      >>>>>>        >      Gyan,
>      >>>>>>        >      On 02/10/2020 18:30, Gyan Mishra wrote:
>      >>>>>>        >      > All,
>      >>>>>>        >      >
>      >>>>>>        >      > With SRv6 and IP based flex algo a generic
>     question as it
>      >>>> applies
>      >>>>>> to
>      >>>>>>        >      > both. Is it possible to have within a single
>     IGP domain
>      >>>> different
>      >>>>>> sets
>      >>>>>>        >      > of nodes or segments of the network running
>     different
>      >>>>>> algorithms.
>      >>>>>>        >
>      >>>>>>        >      absolutely.
>      >>>>>>        >
>      >>>>>>        >      > From
>      >>>>>>        >      > both drafts it sounds like all nodes have to
>     agree on
>      >> same
>      >>>>>> algorithm
>      >>>>>>        >      > similar to concept of metric and reference
>     bandwidth
>      >> all
>      >>>> have to
>      >>>>>> have
>      >>>>>>        >      > the same style metric and play to the same
>     sheet of
>      >> music.
>      >>>>>>        >
>      >>>>>>        >      all participating nodes need to agree on the
>     definition of
>      >> the
>      >>>>>> flex-algo
>      >>>>>>        >      and advertise the participation. That's it.
>      >>>>>>        >
>      >>>>>>        >      > If there was
>      >>>>>>        >      > a way to use multiple algorithms
>     simultaneously based
>      >> on
>      >>>> SFC
>      >>>>>> or services
>      >>>>>>        >      > and instantiation of specific algorithm
>     based on service
>      >> to
>      >>>> be
>      >>>>>>        >      > rendered.  Doing so without causing a
>     routing loop or
>      >> sub
>      >>>>>> optimal
>      >>>>>>        >      > routing.
>      >>>>>>        >
>      >>>>>>        >      you can certainly use multiple algorithms
>     simultaneously
>      >> and
>      >>>> use
>      >>>>>> algo
>      >>>>>>        >      specific paths to forward specific traffic
>     over it. How that
>      >> is
>      >>>> done
>      >>>>>>        >      from the forwarding perspective depends in which
>      >>>> forwarding
>      >>>>>> plane you
>      >>>>>>        >      use. Flex-algo control plane is independent of the
>      >> forwarding
>      >>>>>> plane.
>      >>>>>>        >
>      >>>>>>        >
>      >>>>>>        >      >I thought with flex algo that there exists a
>     feature that
>      >> on
>      >>>>>>        >      > each hop there is a way to specify which
>     algo to use
>      >> hop by
>      >>>> hop
>      >>>>>> similar
>      >>>>>>        >      > to a hop by hop policy based routing.
>      >>>>>>        >
>      >>>>>>        >      no, there is no hop-by-hop classification, that is
>      >> problematic
>      >>>> and
>      >>>>>> does
>      >>>>>>        >      not scale for high speeds. Classification is
>     done at the
>      >>>> ingress only.
>      >>>>>>        >
>      >>>>>>        >      thanks,
>      >>>>>>        >      Peter
>      >>>>>>        >
>      >>>>>>        >      >
>      >>>>>>        >
>      >>>>>>        >
>      >>>>>>        > [email-masked] <mailto:[email-masked]>
>      >>>>>>        >
>      >>>>>>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 14 Oct 2020 08:38:47 +0000

Hi Peter, 

> From: Peter Psenak [mailto:[email-masked]]
> Sent: Tuesday, October 13, 2020 4:53 PM
> >> nodes >which bind FA-128 to IP address? If so, how could this node
> >> know the binding of FA to different data planes on other nodes?
> >>
> >> participation using the SR-Algorithm Sub-TLV. Only these nodes will
> >> be used during the SR flex-algo computation for algo 128.
> >>
> >> participation using the IGP Algorithm Sub-TLV. Only these nodes will
> >> be used during the IP flex-algo computation for algo 128.
> >
> > Agree that if participation to Flex-Algo is advertised in a data plane specific
> manner, then path computation with Flex-Algo constraints could be done only
> using nodes which bind the Flex-Algo to the same data plane.
> 
> it's per app, not per data plane, but yes, that is what the base flex-algo spec
> mandates.
>
> > As Robert asked and you confirmed, this implies each data plane needs to be
> treated as an independent application of Flex-Algo. We have SR-Algorithm
> sub-TLV and IP Algorithm sub-TLV, while there are actually more data planes to
> be considered: SR-MPLS, SRv6, IPv4, IPv6, etc., does this mean that Flex-Algo
> participation needs to be advertised for SR-MPLS, SRv6, IPv4, IPv6, etc.
> separately?
> 
> yes, it needs to be advertised per app. We have SR specific algo participation,
> we need one for IP as proposed in Ron's draft.

OK. While the meaning of "app" here maybe a little vague, are SR-MPLS and SRv6 considered the same or different apps? 

> Regarding IPv4 vs IPv6, it's up to the authors whether they want to make the
> participation for IP flex-algo topology specific or topology independent, both
> could work.

If the participation is topology specific, do you mean IPv4 and IPv6 could be distinguished by advertising Flex-Algo participation with different Topology IDs (MT-ID)? This way, is the topology ID actually used as the address family distinguisher?

Best regards,
Jie

> >>>> data plane? In the former case, should the flex-algo definition
> >>>> also indicate the data plane(s) to be used with the flex-algo?
> >>>>
> >>>>>> with a single algo. So my understanding is Ron's proposal is
> >>>>>> making the
> >>>>>>        > My understanding of flex-algo is that for traffic
> >>>>>> destined to a prefix on a particular algo, it can only be routed
> >>>>>> on routers belong to that algo, which also means only routers in
> >>>>>> that algo calculates how to reach that prefix and install it into
> >>>>>> the routing table. It seems to me that using flex-algo (section
> >>>>>> 12 of the
> >>>>>>        >      > similar to concept of metric and reference
> bandwidth
> >> all
> >>>> have to
> >>>>>> have
> >>>>>>        >      all participating nodes need to agree on the definition
> of
> >> the
> >>>>>> flex-algo
> >>>>>> ?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&amp;da
> >>>>>> ta
> >>>>>> =
> >>>> 0
> >>>>>> 2
> >>>>>>
> >>>>
> >>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 14 Oct 2020 08:57:27 +0000

Hi Robert and Peter,

> Sent: Tuesday, October 13, 2020 7:55 PM
> To: Robert Raszuk <[email-masked]>
> Cc: Dongjie (Jimmy) <[email-masked]>; Gyan Mishra
> <[email-masked]>; Ron Bonica <[email-masked]>; [email-masked];
> Jeff Tantsura <[email-masked]>; Yingzhen Qu
> <[email-masked]>

Agree that FAD just defines the constraints for path computation, and as discussed computation with Flex-Algo constraints needs to be done using nodes which bind the Flex-Algo to the same app/data plane.

> > central controller how is this going to work in practice for any
> > network which attempts to use more then one forwarding schema with
> > dynamic constraints ?
> 
> flex-algo defines the way to calculate constraint based paths in a distributed
> manner and guarantees the loop free forwarding over such path.
> 
> something that flex-algo spec attempts to solve. That does not mean it is not
> possible. I don't see anything in the flex-algo spec that would prevent one to do
> that.

Yes for that purpose some extensions based on Flex-Algo would be needed.

For per-Algo resource allocation, please refer to draft-zhu-lsr-isis-sr-vtn-flexalgo-01. For per app resource allocation and identification , you may refer to draft-dong-lsr-sr-enhanced-vpn-04. 

Best regards,
Jie

> >      >>>>> Thanks for explaining the difference between IP Flex-Algo and
> SR
> >      >>>>> Flex-algo. As
> >      >>>>>> The significant difference between IP Flexible Algorithms and
> SR
> >      >>>>>> Flexible Algorithms is:
> >      >>>>>>
> >      >>>>>>                                            Ro
> n
> >     making
> >      >>>>>> only one algo, please correct me if I'm missing or
> misunderstood
> >      >> something.
> >      >>>>>>

---

From: Peter Psenak <[email-masked]>
Date: Wed, 14 Oct 2020 11:06:46 +0200

Hi Jimmy,

> OK. While the meaning of "app" here maybe a little vague, are SR-MPLS and SRv6 considered the same or different apps?

these are considered as single app, and share the same participation 
signaling. Please note that SRv6 support is signaled independently of FA 
participation.

> If the participation is topology specific, do you mean IPv4 and IPv6 could be distinguished by advertising Flex-Algo participation with different Topology IDs (MT-ID)? This way, is the topology ID…

Yes, one can signal participation for each topology and each MT topology 
is associated with one or AF. But let not speculate here and let authors 
decide.

thanks,
Peter

---

From: <[email-masked]>
Date: Mon, 19 Oct 2020 16:52:29 +0000

Ron, all,

>From a use case standpoint, I have a use case for having both SR-MPLS and IP flexalgo in the same network.

>From a protocol standpoint, I think that the functionality could be equally met by advertising SR-MPLS SID as per RFC 8667 but using a label 3 (implicit null) to instruct the LER/LSR to not use a label in the forwarding plane. (while still advertising a label in the control plane because we have to).
I feel that this would be less change in the protocol (no new tlv), a good fit for network requiring both MPLS and IP flex algo, and would not require implementations/network operator to duplicate the "prefix sub-TLV" [1] on both advertisements (IP based and SR-MPLS based).

That would still requires a protocol extension/STD track RFC as RFC 8667 does not allow for this. That would still require change to implementations as only the signalling is different while the feature/behavior is the same (i.e. no magic).

Regards,
--Bruno

[1] aka "Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability, MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)"

> Sent: Tuesday, September 29, 2020 3:38 PM
> To: [email-masked]
> Subject: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-
> 00.txt
> 
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Peter Psenak <[email-masked]>
Date: Mon, 19 Oct 2020 19:55:13 +0200

Bruno,

>>From a protocol standpoint, I think that the functionality could be equally met by advertising SR-MPLS SID as per RFC 8667 but using a label 3 (implicit null) to instruct the LER/LSR to not use a l…

does not work, as it does not allow you to associate the prefix with
Flex-algo without advertising the reachability in algo 0. Making the 
prefix reachability in default algo conditional based on the presence of 
the Prefix SID Sub-TLV with Imnplicit Null would be a nasty hack.

Not to mention that advertising a Prefix SID in pure IP network would be 
ugly.

thanks,
Peter

---

From: <[email-masked]>
Date: Tue, 20 Oct 2020 09:43:56 +0000

Peter,

> >>From a protocol standpoint, I think that the functionality could be equally
> met by advertising SR-MPLS SID as per RFC 8667 but using a label 3 (implicit
> null) to instruct the LER/LSR to not use a label in the forwarding plane. (while
> still advertising a label in the control plane because we have to).
> 
> does not work,

I could provide more explanations, but reading your email, it seems to me that you understood the proposal.
So it seems to me that the opinion that you really meant is: it works but it would be an nasty hack.

Regarding "nasty hack" it could be interesting to have a normative definition. This could prove useful in some other contexts. 
BTW, is "max metric" a hack (vs creating a new tlv if you don't want the link in the IGP SPF), is "implicit null label" a hack. And for BGP, encoding the label in the NLRI...

Coming back to technical comments, note that creating yet another TLV to carry IP prefix also brings questions that the draft does not answer or even raise.
- What about the sub-TLVs? Are they shared with the existing registry for prefix TLV [1] ? Do we want to exclude some? E.g., Prefix Segment Identifier (we would have two algo fields, two ways to signal SIDs...)
- for IPv6, the content and meaning of  "ISIS MT IPv6 Flexalgo Prefix Reachability TLV" is essentially the same than the "SRv6 Locator TLV".
	- Only the naming and the ordering of the fields are different.
	- Why do we need two TLVs to advertise the same thing (essentially a Routing Algo)? Duplication means more spec, more code, more features to implement, more error and bugs. (and it did not took long: the draft defines the MTID field as 8 bits while RFC 5120 defines it a 12 bits.
	- What is the functional different between FlexAlgo for SRv6 and FlexAlgo for IPv6? Both use the IPv6 destination address in the packet and the IPv6 FIB in the router.

Thanks,
Bruno

> as it does not allow you to associate the prefix with
> > I feel that this would be less change in the protocol (no new tlv), a good fit
> for network requiring both MPLS and IP flex algo, and would not require
> implementations/network operator to duplicate the "prefix sub-TLV" [1] on
> both advertisements (IP based and SR-MPLS based).
> >
> > That would still requires a protocol extension/STD track RFC as RFC 8667
> does not allow for this. That would still require change to implementations as
> only the signalling is different while the feature/behavior is the same (i.e. no
> magic).
> >
> > Regards,
> > --Bruno
> >
> > [1] aka "Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability,
> MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)"
> >
> >
> __________________________________________________________
> __________________________________________________________
> _____
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> > This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: Peter Psenak <[email-masked]>
Date: Tue, 20 Oct 2020 13:03:58 +0200

Bruno,

please see inline:

> BTW, is "max metric" a hack (vs creating a new tlv if you don't want the link in the IGP SPF), is "implicit null label" a hack. And for BGP, encoding the label in the NLRI...

max-metric does not solve the problem, as you would need a prefix metric 
for non 0 algo anyway.
> - What about the sub-TLVs? Are they shared with the existing registry for prefix TLV [1] ? Do we want to exclude some? E.g., Prefix Segment Identifier (we would have two algo fields, two ways to si…

yes, these are details that needs to be addressed, but should not be a 
problem. Look at locator TLV in SRv6, very similar concept here.

> 	- Why do we need two TLVs to advertise the same thing (essentially a Routing Algo)? Duplication means more spec, more code, more features to implement, more error and bugs. (and it did not took lo…

well, locator is a construct that is specific to SRv6. Sure you can 
advertise the prefix in a locator TLV without any SRv6 specific Sub-TLVs 
and achieve the same thing - I have already mentioned that in one of my 
responses, but that is again ugly.

> 	- What is the functional different between FlexAlgo for SRv6 and FlexAlgo for IPv6? Both use the IPv6 destination address in the packet and the IPv6 FIB in the router.

they are functionally the same.

I believe that having a clean encoding is preferable in a long run. One 
can not advertise a prefix as SRv6 locator as well as IP flex-algo 
prefix (that would be an error), so duplication of data is not an 
issues. And having a dedicated TLV for each is better from both 
deployment and implementation perspective.

thanks,
Peter

---

From: <[email-masked]>
Date: Tue, 20 Oct 2020 12:47:56 +0000

Peter,

> >>> >From a use case standpoint, I have a use case for having both SR-MPLS
> and
> >> IP flexalgo in the same network.
> >>>
> > Regarding "nasty hack" it could be interesting to have a normative
> definition. This could prove useful in some other contexts.
> > BTW, is "max metric" a hack (vs creating a new tlv if you don't want the link
> in the IGP SPF), is "implicit null label" a hack. And for BGP, encoding the label
> in the NLRI...
> 

To clarify, my text was not a technical proposal related to that draft. It was referring to your email and questioning what exactly was a hack using some examples from the past.
But let's forget about this point, at least for the moment.

> > Coming back to technical comments, note that creating yet another TLV to
> carry IP prefix also brings questions that the draft does not answer or even
> raise.
> > - What about the sub-TLVs? Are they shared with the existing registry for
> prefix TLV [1] ? Do we want to exclude some? E.g., Prefix Segment Identifier
> (we would have two algo fields, two ways to signal SIDs...)
> 
> > - for IPv6, the content and meaning of  "ISIS MT IPv6 Flexalgo Prefix
> Reachability TLV" is essentially the same than the "SRv6 Locator TLV".
> > 	- Why do we need two TLVs to advertise the same thing (essentially a
> Routing Algo)? Duplication means more spec, more code, more features to
> implement, more error and bugs. (and it did not took long: the draft defines
> the MTID field as 8 bits while RFC 5120 defines it a 12 bits.
> 

So we agree that reusing the SRv6 locator TLV would work and provide the functionality. Good.
Now here comes again the "ugly" argument. If it's now becoming a technical argument, in my opinion, it's ugly to define two TLVs in order to advertise the same information and to provide the same functionality.

> > 	- What is the functional different between FlexAlgo for SRv6 and
> FlexAlgo for IPv6? Both use the IPv6 destination address in the packet and
> the IPv6 FIB in the router.
> 

Good to agree on this.
 
> I believe that having a clean encoding is preferable in a long run.

What do you mean by "clean encoding"? The only differences between both TLVs are the naming and the ordering of the fields.

> One
> issues.

So one should not advertise both TLVs? If so this becomes an error/issue? This feels like my point. There is no such issue with a single TLV.

> And having a dedicated TLV for each is better from both

I can't see how implementing the same functionality twice would be better from an implementation perspective, but I leave this to you. I would suspect that you may consider only implementing one, not both.
I disagree on the deployment perspective. We would have two TLVs to advertise the same information and provide the exactly same functionality.  I can only see that this would bring deployment issues. e.g. one vendor implementing TLV A while another vendor implementing TLV B; hence no interoperability or a large delay to have both vendors implement both TLVs (or at least one vendor implementing both, presumably the smaller vendor).

Thanks,
--Bruno
 
> >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce
> >> message par erreur, veuillez le signaler
> >>> Orange decline toute responsabilite si ce message a ete altere, deforme
> ou
> >> falsifie. Merci.
> >>>
> >>> If you have received this email in error, please notify the sender and
> delete
> >> this message and its attachments.
> >>> As emails may be altered, Orange is not liable for messages that have
> been
> >> modified, changed or falsified.
> >>> Thank you.
> >>>

---

From: Peter Psenak <[email-masked]>
Date: Tue, 20 Oct 2020 15:32:35 +0200

Bruno,

> So one should not advertise both TLVs? If so this becomes an error/issue? This feels like my point. There is no such issue with a single TLV.

I don't see that error an issue.

> I can't see how implementing the same functionality twice would be better from an implementation perspective, but I leave this to you. I would suspect that you may consider only implementing one, n…

not really, I prefer clean encoding rather the overloading things as we 
extend protocol.

> I disagree on the deployment perspective. We would have two TLVs to advertise the same information and provide the exactly same functionality.  I can only see that this would bring deployment issue…

I don't agree. If we keep things clean we would not allow "vendor 
implementing TLV A while another vendor implementing TLV B".

Anyway, it's for the WG to decide what encoding to use.

thanks,
Peter