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>> 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>] On Behalf Of Joel M. Halpern
    Sent: Wednesday, September 30, 2020 12:05 PM
    Cc: 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>] On Behalf Of 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>>
     > Cc: 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>> wrote:
     >>
     >>
     >> Please review and comment
     >>
     >>                                        Ron
     >>
     >>
     >>
     >> Juniper Business Use Only
     >>
     >>> -----Original Message-----
     >>> From: internet-dra...@ietf.org
    <mailto:internet-dra...@ietf.org> <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>>; Shraddha Hegde
     >>> <shrad...@juniper.net <mailto:shrad...@juniper.net>>; Ron
    Bonica <rbon...@juniper.net <mailto:rbon...@juniper.net>>; Rajesh M
     >>> <mraj...@juniper.net <mailto:mraj...@juniper.net>>; William
    Britto A J <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>.
     >>>
     >>> The IETF Secretariat
     >>>
     >> _______________________________________________
     >> Lsr mailing list
     >> Lsr@ietf.org <mailto:Lsr@ietf.org>
     >> https://www.ietf.org/mailman/listinfo/lsr
     >
     > _______________________________________________
     > Lsr mailing list
     > Lsr@ietf.org <mailto:Lsr@ietf.org>
     > https://www.ietf.org/mailman/listinfo/lsr
     > _______________________________________________
     > Lsr mailing list
     > Lsr@ietf.org <mailto:Lsr@ietf.org>
     > https://www.ietf.org/mailman/listinfo/lsr
     >

    _______________________________________________
    Lsr mailing list
    Lsr@ietf.org <mailto:Lsr@ietf.org>
    https://www.ietf.org/mailman/listinfo/lsr
    _______________________________________________
    Lsr mailing list
    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