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 <ppse...@cisco.com <mailto:ppse...@cisco.com>> 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 <ppse...@cisco.com
    <mailto:ppse...@cisco.com>
     > <mailto:ppse...@cisco.com <mailto:ppse...@cisco.com>>> 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
    <huzh...@huawei.com <mailto:huzh...@huawei.com>
     >     <mailto:huzh...@huawei.com <mailto:huzh...@huawei.com>>
     >      > <mailto:huzh...@huawei.com <mailto:huzh...@huawei.com>
    <mailto:huzh...@huawei.com <mailto:huzh...@huawei.com>>>> 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:lsr-boun...@ietf.org
    <mailto:lsr-boun...@ietf.org>
     >     <mailto:lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>>
     >      >     <mailto:lsr-boun...@ietf.org
    <mailto:lsr-boun...@ietf.org> <mailto:lsr-boun...@ietf.org
    <mailto:lsr-boun...@ietf.org>>>]
     >     On Behalf Of Joel M. Halpern
     >      >     Sent: Wednesday, September 30, 2020 12:05 PM
     >      >     Cc: lsr@ietf.org <mailto:lsr@ietf.org>
    <mailto:lsr@ietf.org <mailto:lsr@ietf.org>> <mailto:lsr@ietf.org
    <mailto:lsr@ietf.org>
     >     <mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>
     >      >     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:lsr-boun...@ietf.org
    <mailto:lsr-boun...@ietf.org>
     >     <mailto:lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>>
     >      >     <mailto:lsr-boun...@ietf.org
    <mailto:lsr-boun...@ietf.org> <mailto:lsr-boun...@ietf.org
    <mailto:lsr-boun...@ietf.org>>>]
     >     On Behalf Of tony...@tony.li <mailto:tony...@tony.li>
    <mailto:tony...@tony.li <mailto:tony...@tony.li>>
     >      >     <mailto:tony...@tony.li <mailto:tony...@tony.li>
    <mailto:tony...@tony.li <mailto:tony...@tony.li>>>
     >      >      > Sent: Tuesday, September 29, 2020 10:05 PM
     >      >      > To: Ron Bonica
    <rbonica=40juniper....@dmarc.ietf.org
    <mailto:40juniper....@dmarc.ietf.org>
     >     <mailto:40juniper....@dmarc.ietf.org
    <mailto:40juniper....@dmarc.ietf.org>>
     >      >     <mailto:40juniper....@dmarc.ietf.org
    <mailto:40juniper....@dmarc.ietf.org>
     >     <mailto:40juniper....@dmarc.ietf.org
    <mailto:40juniper....@dmarc.ietf.org>>>>
     >      >      > Cc: lsr@ietf.org <mailto:lsr@ietf.org>
    <mailto:lsr@ietf.org <mailto:lsr@ietf.org>>
     >     <mailto:lsr@ietf.org <mailto:lsr@ietf.org>
    <mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>
     >      >      > 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=40juniper....@dmarc.ietf.org
    <mailto:40juniper....@dmarc.ietf.org>
     >     <mailto:40juniper....@dmarc.ietf.org
    <mailto:40juniper....@dmarc.ietf.org>>
     >      >     <mailto:40juniper....@dmarc.ietf.org
    <mailto:40juniper....@dmarc.ietf.org>
     >     <mailto:40juniper....@dmarc.ietf.org
    <mailto:40juniper....@dmarc.ietf.org>>>> wrote:
     >      >      >>
     >      >      >>
     >      >      >> Please review and comment
     >      >      >>
     >      >      >>                                        Ron
     >      >      >>
     >      >      >>
     >      >      >>
     >      >      >> Juniper Business Use Only
     >      >      >>
     >      >      >>> -----Original Message-----
     >      >      >>> From: internet-dra...@ietf.org
    <mailto:internet-dra...@ietf.org>
     >     <mailto:internet-dra...@ietf.org
    <mailto:internet-dra...@ietf.org>>
     >      >     <mailto:internet-dra...@ietf.org
    <mailto:internet-dra...@ietf.org>
     >     <mailto:internet-dra...@ietf.org
    <mailto:internet-dra...@ietf.org>>> <internet-dra...@ietf.org
    <mailto:internet-dra...@ietf.org>
     >     <mailto:internet-dra...@ietf.org
    <mailto:internet-dra...@ietf.org>>
     >      >     <mailto:internet-dra...@ietf.org
    <mailto:internet-dra...@ietf.org>
     >     <mailto:internet-dra...@ietf.org
    <mailto:internet-dra...@ietf.org>>>>
     >      >      >>> Sent: Tuesday, September 29, 2020 9:36 AM
     >      >      >>> To: Parag Kaneriya <pkane...@juniper.net
    <mailto:pkane...@juniper.net>
     >     <mailto:pkane...@juniper.net <mailto:pkane...@juniper.net>>
     >      >     <mailto:pkane...@juniper.net
    <mailto:pkane...@juniper.net> <mailto:pkane...@juniper.net
    <mailto:pkane...@juniper.net>>>>;
     >     Shraddha Hegde
     >      >      >>> <shrad...@juniper.net
    <mailto:shrad...@juniper.net> <mailto:shrad...@juniper.net
    <mailto:shrad...@juniper.net>>
     >     <mailto:shrad...@juniper.net <mailto:shrad...@juniper.net>
    <mailto:shrad...@juniper.net <mailto:shrad...@juniper.net>>>>; Ron
     >      >     Bonica <rbon...@juniper.net
    <mailto:rbon...@juniper.net> <mailto:rbon...@juniper.net
    <mailto:rbon...@juniper.net>>
     >     <mailto:rbon...@juniper.net <mailto:rbon...@juniper.net>
    <mailto:rbon...@juniper.net <mailto:rbon...@juniper.net>>>>; Rajesh M
     >      >      >>> <mraj...@juniper.net <mailto:mraj...@juniper.net>
    <mailto:mraj...@juniper.net <mailto:mraj...@juniper.net>>
     >     <mailto:mraj...@juniper.net <mailto:mraj...@juniper.net>
    <mailto:mraj...@juniper.net <mailto:mraj...@juniper.net>>>>; William
     >      >     Britto A J <bwill...@juniper.net
    <mailto:bwill...@juniper.net>
     >     <mailto:bwill...@juniper.net <mailto:bwill...@juniper.net>>
    <mailto:bwill...@juniper.net <mailto:bwill...@juniper.net>
     >     <mailto:bwill...@juniper.net <mailto:bwill...@juniper.net>>>>
     >      >      >>> 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
     >      >      >> Lsr@ietf.org <mailto:Lsr@ietf.org>
    <mailto:Lsr@ietf.org <mailto:Lsr@ietf.org>> <mailto:Lsr@ietf.org
    <mailto:Lsr@ietf.org>
     >     <mailto:Lsr@ietf.org <mailto:Lsr@ietf.org>>>
     >      >      >> https://www.ietf.org/mailman/listinfo/lsr
     >      >      >
     >      >      > _______________________________________________
     >      >      > Lsr mailing list
     >      >      > Lsr@ietf.org <mailto:Lsr@ietf.org>
    <mailto:Lsr@ietf.org <mailto:Lsr@ietf.org>> <mailto:Lsr@ietf.org
    <mailto:Lsr@ietf.org>
     >     <mailto:Lsr@ietf.org <mailto:Lsr@ietf.org>>>
     >      >      > https://www.ietf.org/mailman/listinfo/lsr
     >      >      > _______________________________________________
     >      >      > Lsr mailing list
     >      >      > Lsr@ietf.org <mailto:Lsr@ietf.org>
    <mailto:Lsr@ietf.org <mailto:Lsr@ietf.org>> <mailto:Lsr@ietf.org
    <mailto:Lsr@ietf.org>
     >     <mailto:Lsr@ietf.org <mailto:Lsr@ietf.org>>>
     >      >      > https://www.ietf.org/mailman/listinfo/lsr
     >      >      >
     >      >
     >      >     _______________________________________________
     >      >     Lsr mailing list
     >      > Lsr@ietf.org <mailto:Lsr@ietf.org> <mailto:Lsr@ietf.org
    <mailto:Lsr@ietf.org>> <mailto:Lsr@ietf.org <mailto:Lsr@ietf.org>
     >     <mailto:Lsr@ietf.org <mailto:Lsr@ietf.org>>>
     >      > https://www.ietf.org/mailman/listinfo/lsr
     >      >     _______________________________________________
     >      >     Lsr mailing list
     >      > Lsr@ietf.org <mailto:Lsr@ietf.org> <mailto:Lsr@ietf.org
    <mailto:Lsr@ietf.org>> <mailto:Lsr@ietf.org <mailto:Lsr@ietf.org>
     >     <mailto:Lsr@ietf.org <mailto:Lsr@ietf.org>>>
     >      > https://www.ietf.org/mailman/listinfo/lsr
     >      >
     >


_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to