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

[Peter Psenak <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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 <[e-mail]
>     <mailto:[e-mail]>
>      > <mailto:[e-mail] <mailto:[e-mail]>>> 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:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>]
>     On Behalf Of Joel M. Halpern
>      >     Sent: Wednesday, September 30, 2020 12:05 PM
>      >     Cc: [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      >     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:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>]
>     On Behalf Of [e-mail] <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>
>      >      > Sent: Tuesday, September 29, 2020 10:05 PM
>      >      > To: Ron Bonica <rbonica=[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>      >      > Cc: [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      >      > 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=[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>> wrote:
>      >      >>
>      >      >>
>      >      >> Please review and comment
>      >      >>
>      >      >>                                        Ron
>      >      >>
>      >      >>
>      >      >>
>      >      >> Juniper Business Use Only
>      >      >>
>      >      >>> -----Original Message-----
>      >      >>> From: [e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>> <[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>      >      >>> Sent: Tuesday, September 29, 2020 9:36 AM
>      >      >>> To: Parag Kaneriya <[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>>;
>     Shraddha Hegde
>      >      >>> <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>; Ron
>      >     Bonica <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>; Rajesh M
>      >      >>> <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>; William
>      >     Britto A J <[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>      >      >>> 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>.
>      >      >>>
>      >      >>> The IETF Secretariat
>      >      >>>
>      >      >> _______________________________________________
>      >      >> Lsr mailing list
>      >      >> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      >      >> https://www.ietf.org/mailman/listinfo/lsr
>      >      >
>      >      > _______________________________________________
>      >      > Lsr mailing list
>      >      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      >      > https://www.ietf.org/mailman/listinfo/lsr
>      >      > _______________________________________________
>      >      > Lsr mailing list
>      >      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      >      > https://www.ietf.org/mailman/listinfo/lsr
>      >      >
>      >
>      >     _______________________________________________
>      >     Lsr mailing list
>      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      > https://www.ietf.org/mailman/listinfo/lsr
>      >     _______________________________________________
>      >     Lsr mailing list
>      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      > https://www.ietf.org/mailman/listinfo/lsr
>      >
>