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 <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>> 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>>> 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>>] > > 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>> > > > 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>>] > > On Behalf Of 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>>> > > > > Cc: 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>>> 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>> <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>>>; > > Shraddha Hegde > > > >>> <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>>>; Rajesh M > > > >>> <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>>> > > > >>> 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 > > > >> 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>> > > > > 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>> > > > > 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>> > > > 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>> > > > https://www.ietf.org/mailman/listinfo/lsr > > > > > > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
