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

[Robert Raszuk <[e-mail]>]

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 ?

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 <[e-mail]> 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 <[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
> >      >
> >
>
>