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

["Acee Lindem (acee)" <[e-mail]>]

Or possibly the prospect of Flex Algo flavors made you hungry ;^0. 

Acee

On 10/11/20, 1:39 PM, "Lsr on behalf of Jeff Tantsura" <[e-mail] on behalf of [e-mail]> wrote:

    Thanks Ron, indeed!  Autocorrect works in mysterious ways  ;-)

    Regards,
    Jeff

    > On Oct 11, 2020, at 09:41, Ron Bonica <[e-mail]> wrote:
    > 
    > Jeff,
    > 
    > I think that you mean the scope is different..... 
    > 
    >                                     Ron
    > 
    > 
    > 
    > Juniper Business Use Only
    > 
    > -----Original Message-----
    > From: Jeff Tantsura <[e-mail]> 
    > Sent: Saturday, October 10, 2020 3:14 PM
    > To: Ron Bonica <[e-mail]>
    > Cc: Dongjie (Jimmy) <[e-mail]>; Peter Psenak <[e-mail]>; Yingzhen Qu <[e-mail]>; Gyan Mishra <[e-mail]>; [e-mail]
    > Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
    > 
    > [External Email. Be cautious of content]
    > 
    > 
    > Jie,
    > 
    > The scoop is different, for SR data plane entry uniqueness is in context of SR domain (SID = value + context), while for IP it is global to the routing domain, FIB entry is a destination, nothing more.
    > 
    > Regards,
    > Jeff
    > 
    >> On Oct 10, 2020, at 05:47, Ron Bonica <[e-mail]> wrote:
    >> 
    >> Hi Jimmie,
    >> 
    >> Inline.....
    >> 
    >>                   Ron
    >> 
    >> 
    >> Juniper Business Use Only
    >> 
    >> -----Original Message-----
    >> From: Dongjie (Jimmy) <[e-mail]>
    >> Sent: Friday, October 9, 2020 11:06 PM
    >> To: Peter Psenak <[e-mail]>; Ron Bonica
    >> <[e-mail]>; Yingzhen Qu <[e-mail]>; Gyan 
    >> Mishra <[e-mail]>
    >> Cc: [e-mail]; Jeff Tantsura <[e-mail]>
    >> Subject: RE: [Lsr] FW: New Version Notification for 
    >> draft-bonica-lsr-ip-flexalgo-00.txt
    >> 
    >> [External Email. Be cautious of content]
    >> 
    >> 
    >> Hi Peter,
    >> 
    >> Thanks for your reply. It aligns with my understanding of FAD, which is just a set of constraints for path computation. Thus one Flex-Algo ID could be used with multiple different data planes. Is this understanding correct?
    >> 
    >> [RB] I never thought about this. Is there a use-case? I think that it will work, but I would have to try it before saying for sure.
    >> 
    >> If so, my question is about the scenario below:
    >> 
    >> A group of nodes in a network support FA-128, a sub-group of them bind FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address. When one node compute an SR path to a destination, can it compute the path to only pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes which bind FA-128 to IP address?
    >> 
    >> [RB] I don't think so. However, you could achieve the same outcome using link colors.
    >> 
    >> If so, how could this node know the binding of FA to different data planes on other nodes?
    >> 
    >> Best regards,
    >> Jie
    >> 
    >>> -----Original Message-----
    >>> From: Lsr [mailto:[e-mail]] On Behalf Of Peter Psenak
    >>> Sent: Friday, October 9, 2020 11:58 PM
    >>> To: Dongjie (Jimmy) <[e-mail]>; Ron Bonica 
    >>> <rbonica=[e-mail]>; Yingzhen Qu 
    >>> <[e-mail]>; Gyan Mishra <[e-mail]>
    >>> Cc: [e-mail]; Jeff Tantsura <[e-mail]>
    >>> Subject: Re: [Lsr] FW: New Version Notification for 
    >>> draft-bonica-lsr-ip-flexalgo-00.txt
    >>> 
    >>> Hi Jimmy,
    >>> 
    >>> 
    >>>>> On 09/10/2020 04:59, Dongjie (Jimmy) wrote:
    >>>>> Hi Ron,
    >>>>> 
    >>>>> Thanks for explaining the difference between IP Flex-Algo and SR 
    >>>>> Flex-algo. As
    >>> you said, the major difference is the data plane.
    >>>> 
    >>>> If my understanding is correct, for one Flex-Algo to be used 
    >>>> correctly, the set
    >>> of nodes need to apply consistent constraints in computation, and 
    >>> bind the FAD to the same data plane.
    >>>> 
    >>>> Is it possible that different nodes may use the same Flex-Algo with 
    >>>> different
    >>> data plane, e.g. some with SR-MPLS, some with SRv6, and some with 
    >>> pure IP etc., or each Flex-Algo is always associated with only one 
    >>> data plane? In the former case, should the flex-algo definition also 
    >>> indicate the data plane(s) to be used with the flex-algo?
    >>> 
    >>> let me respond to this query, as this is not specific to Ron's draft.
    >>> 
    >>> FAD is data plane agnostic and is used by all of them.
    >>> 
    >>> thanks,
    >>> Peter
    >>> 
    >>>> 
    >>>> Best regards,
    >>>> Jie
    >>>> 
    >>>>> -----Original Message-----
    >>>>> From: Lsr [mailto:[e-mail]] On Behalf Of Ron Bonica
    >>>>> Sent: Sunday, October 4, 2020 4:34 AM
    >>>>> To: Yingzhen Qu <[e-mail]>; Peter Psenak 
    >>>>> <[e-mail]>; Gyan Mishra <[e-mail]>
    >>>>> Cc: [e-mail]; Jeff Tantsura <[e-mail]>
    >>>>> Subject: Re: [Lsr] FW: New Version Notification for 
    >>>>> draft-bonica-lsr-ip-flexalgo-00.txt
    >>>>> 
    >>>>> Hi Yingzhen,
    >>>>> 
    >>>>> IP Flexible Algorithms are like SR Flexible Algorithms in the 
    >>>>> following
    >>> respects:
    >>>>> 
    >>>>> - Links have IGP metrics, TE metrics, delay metrics and 
    >>>>> administrative colors
    >>>>> - FADs define Flexible Algorithms
    >>>>> 
    >>>>> More specifically, the FAD:
    >>>>> 
    >>>>> - Indicates which metric type the Flexible Algorithm uses
    >>>>> - Specifies constraints in terms of link colors that are included 
    >>>>> or excluded from the Flexible Algorithm.
    >>>>> 
    >>>>> The significant difference between IP Flexible Algorithms and SR 
    >>>>> Flexible Algorithms is:
    >>>>> 
    >>>>> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators
    >>>>> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses.
    >>>>> 
    >>>>> So, IP Flexible Algorithms can be deployed in any IP network, even 
    >>>>> in the absence of SR.
    >>>>> 
    >>>>>                                        Ron
    >>>>> 
    >>>>> 
    >>>>> Juniper Business Use Only
    >>>>> 
    >>>>> -----Original Message-----
    >>>>> From: Yingzhen Qu <[e-mail]>
    >>>>> Sent: Saturday, October 3, 2020 2:08 PM
    >>>>> To: Peter Psenak <[e-mail]>; Gyan Mishra 
    >>>>> <[e-mail]>; Ron Bonica <[e-mail]>
    >>>>> Cc: [e-mail]; Jeff Tantsura <[e-mail]>
    >>>>> Subject: Re: [Lsr] FW: New Version Notification for 
    >>>>> draft-bonica-lsr-ip-flexalgo-00.txt
    >>>>> 
    >>>>> [External Email. Be cautious of content]
    >>>>> 
    >>>>> 
    >>>>> Hi Peter,
    >>>>> 
    >>>>> Using flex-algo, a SRv6 locator can be associated with a single 
    >>>>> algo, which means an IPv6 or IPv4 address can also be associated 
    >>>>> with a single algo. So my understanding is Ron's proposal is making 
    >>>>> the
    >>> configuration of flex-algo easier?
    >>>>> Instead of using the exclude or include list you can configure a 
    >>>>> loopback address to a flex-algo directly?
    >>>>> 
    >>>>> Thanks,
    >>>>> Yingzhen
    >>>>> 
    >>>>> On 10/3/20, 2:47 AM, "Peter Psenak" <[e-mail]> wrote:
    >>>>> 
    >>>>>    Hi Yingzhen,
    >>>>> 
    >>>>>    On 02/10/2020 22:15, Yingzhen Qu wrote:
    >>>>>> Hi Peter,
    >>>>>> 
    >>>>>> My understanding of flex-algo is that for traffic destined
    >>>>> to a prefix on a particular algo, it can only be routed on routers 
    >>>>> belong to that algo, which also means only routers in that algo 
    >>>>> calculates how to reach that prefix and install it into the routing 
    >>>>> table. It seems to me that using flex-algo (section 12 of the
    >>>>> draft) it's possible to have a loopback address associated with
    >>>>> only one algo, please correct me if I'm missing or misunderstood something.
    >>>>> 
    >>>>>    you are right. That is exactly what is being done for flex-algo with
    >>>>>    SRv6 - locator is associated with a single algo only. The proposal uses
    >>>>>    the same concept.
    >>>>> 
    >>>>>    thanks,
    >>>>>    Peter
    >>>>> 
    >>>>>> 
    >>>>>> Thanks,
    >>>>>> Yingzhen
    >>>>>> 
    >>>>>> On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak"
    >>>>> <[e-mail] on behalf of
    >>>>> ppsenak=[e-mail]>
    >>>>> wrote:
    >>>>>> 
    >>>>>>    Gyan,
    >>>>>> 
    >>>>>>    On 02/10/2020 18:30, Gyan Mishra wrote:
    >>>>>>> All,
    >>>>>>> 
    >>>>>>> With SRv6 and IP based flex algo a generic question as it
    >>> applies
    >>>>> to
    >>>>>>> both. Is it possible to have within a single IGP domain
    >>> different
    >>>>> sets
    >>>>>>> of nodes or segments of the network running different
    >>>>> algorithms.
    >>>>>> 
    >>>>>>    absolutely.
    >>>>>> 
    >>>>>>> From
    >>>>>>> both drafts it sounds like all nodes have to agree on same
    >>>>> algorithm
    >>>>>>> similar to concept of metric and reference bandwidth all
    >>> have to
    >>>>> have
    >>>>>>> the same style metric and play to the same sheet of music.
    >>>>>> 
    >>>>>>    all participating nodes need to agree on the definition of the
    >>>>> flex-algo
    >>>>>>    and advertise the participation. That's it.
    >>>>>> 
    >>>>>>> If there was
    >>>>>>> a way to use multiple algorithms simultaneously based on
    >>> SFC
    >>>>> or services
    >>>>>>> and instantiation of specific algorithm based on service to
    >>> be
    >>>>>>> rendered.  Doing so without causing a routing loop or sub
    >>>>> optimal
    >>>>>>> routing.
    >>>>>> 
    >>>>>>    you can certainly use multiple algorithms simultaneously and
    >>> use
    >>>>> algo
    >>>>>>    specific paths to forward specific traffic over it. How that 
    >>>>>> is
    >>> done
    >>>>>>    from the forwarding perspective depends in which
    >>> forwarding
    >>>>> plane you
    >>>>>>    use. Flex-algo control plane is independent of the forwarding
    >>>>> plane.
    >>>>>> 
    >>>>>> 
    >>>>>>> I thought with flex algo that there exists a feature that on each 
    >>>>>>> hop there is a way to specify which algo to use hop by
    >>> hop
    >>>>> similar
    >>>>>>> to a hop by hop policy based routing.
    >>>>>> 
    >>>>>>    no, there is no hop-by-hop classification, that is problematic
    >>> and
    >>>>> does
    >>>>>>    not scale for high speeds. Classification is done at the
    >>> ingress only.
    >>>>>> 
    >>>>>>    thanks,
    >>>>>>    Peter
    >>>>>> 
    >>>>>>> 
    >>>>>> 
    >>>>>>    _______________________________________________
    >>>>>>    Lsr mailing list
    >>>>>>    [e-mail]
    >>>>>> 
    >>>>> https://urldefense.com/v3/__https://nam11.safelinks.protection.outl
    >>>>> oo
    >>>>> k.com/
    >>>>> ?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&amp;data
    >>>>> =
    >>> 0
    >>>>> 2
    >>>>> 
    >>> *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d86781
    >>>>> 
    >>> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986
    >>>>> 
    >>> 5126&amp;sdata=WI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D
    >>>>> 
    >>> &amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9MjimeJcR
    >>>>> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$
    >>>>>> 
    >>>>>> 
    >>>>>> 
    >>>>> 
    >>>>> _______________________________________________
    >>>>> Lsr mailing list
    >>>>> [e-mail]
    >>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l
    >>>>> sr__;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_H
    >>>>> z218CE8S8XzlIxAA$
    >>>> 
    >>>> 
    >>> 
    >>> _______________________________________________
    >>> Lsr mailing list
    >>> [e-mail]
    >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr
    >>> _ 
    >>> _;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_Hz218C
    >>> E
    >>> 8S8XzlIxAA$

    _______________________________________________
    Lsr mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/lsr