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

From: Ron Bonica <[email-masked]>
Date: Tue, 29 Sep 2020 13:37:32 +0000

Please review and comment

                                       Ron

Juniper Business Use Only

> -----Original Message-----
> From: [email-masked] <[email-masked]>
> Sent: Tuesday, September 29, 2020 9:36 AM
> To: Parag Kaneriya <[email-masked]>; Shraddha Hegde
> <[email-masked]>; Ron Bonica <[email-masked]>; Rajesh M
> <[email-masked]>; William Britto A J <[email-masked]>
> 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-bonica-lsr-
> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
> Htmlized:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-
> 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.
> 
> The IETF Secretariat
>

---

From: [email-masked]
Date: Tue, 29 Sep 2020 07:04:43 -0700

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=[email-masked]> wrote:
> 
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: Jia Chen <[email-masked]>
Date: Tue, 29 Sep 2020 09:11:34 -0700

Not sure whether the use case that the underlay network and the overlay
network that belong to two different administrations is within this scope
?  or has it already been covered by some  other draft or RFCs? Assuming
there are multiple underlay paths from A to B. Overlay would like to
influence underlay path selections. How the best route can be selected, how
the traffic can be forwarded (for example, overlay is IPSec traffic) ?

Jay

On Tue, Sep 29, 2020 at 7:05 AM <[email-masked]> wrote:

> >> URL:
> https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica-
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_lsr&d=DwIGaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=yetdj-aXQpuqTCJGs-93hOpK3740MIRXowfUNLByeos&m=cCA4pT7B_XmVlm12wpR4lB8ideM42mfE4yk5tEwjlK4&s=lJXEm1gLCAl2E5l2C-XXRX4qbO_RC3OFJ4yfYj1xPKY&e=
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_lsr&d=DwIGaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=yetdj-aXQpuqTCJGs-93hOpK3740MIRXowfUNLByeos&m=cCA4pT7B_XmVlm12wpR4lB8ideM42mfE4yk5tEwjlK4&s=lJXEm1gLCAl2E5l2C-XXRX4qbO_RC3OFJ4yfYj1xPKY&e=
>

---

From: Huzhibo <[email-masked]>
Date: Wed, 30 Sep 2020 03:50:39 +0000

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:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, September 29, 2020 10:05 PM
To: Ron Bonica <rbonica=[email-masked]>
Cc: [email-masked]
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.

Tony

>> 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.
>> 
>> The IETF Secretariat
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 30 Sep 2020 00:04:52 -0400

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.

---

From: Huzhibo <[email-masked]>
Date: Wed, 30 Sep 2020 04:10:18 +0000

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:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, September 30, 2020 12:05 PM
Cc: [email-masked]
Subject: Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

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:
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-b
>>> o
>>> nica-lsr-
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dr
>>> a
>>> ft-

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 30 Sep 2020 09:28:15 +0200

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.

Many thx,
R.

On Wed, Sep 30, 2020 at 6:10 AM Huzhibo <[email-masked]> 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
>
> which one applies to the packet?  As far as I know, flex-algo does not look
> at the QoS/CoS/ToS bits.
>
> Yours,
> Joel
>
> > 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
> >
> > 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.
> >

---

From: Peter Psenak <[email-masked]>
Date: Wed, 30 Sep 2020 14:05:22 +0200

Hi Joel,

> I am missing something in this discussion of multiple algorithms.

not really.

> arrives, it is simply forwarded according to the forwarding table (e.g.

right.

For SR MPLS, the flex-algo forwarding is associated with the algo 
specific label that is derived from the algo specific SID. That unique 
algo specific label allows the traffic for the same prefix to be 
forwarded using many algorithms by simply using the right MPLS label.

For SRv6, the SRv6 Locator is associated with a single Algorithm.

The proposal here is to associate the prefix with the unique flex-algo 
only and use that association on all routers. This is similar to SRv6 
locators.

> look at the QoS/CoS/ToS bits.

absolutely not. Doing classification of the data traffic at each hop 
does not work. It has been attempted in the past, but without much success.

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Wed, 30 Sep 2020 14:11:11 +0200

Hi Robert,

On 30/09/2020 09:28, Robert Raszuk wrote:
> 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 <[email-masked] 
> <mailto:[email-masked]>> 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
> 
>     From: Lsr [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Joel M. Halpern
>     Cc: [email-masked] <mailto:[email-masked]>
>     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
> 
>      > 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
>      >
>      > From: Lsr [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of [email-masked]
>     <mailto:[email-masked]>
>      > To: Ron Bonica <rbonica=[email-masked]
>     <mailto:[email-masked]>>
>      > Cc: [email-masked] <mailto:[email-masked]>
>      > 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.
>      >
>      >> On Sep 29, 2020, at 6:37 AM, Ron Bonica
>     <rbonica=[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >>
>      >>
>      >>> From: [email-masked]
>     <mailto:[email-masked]> <[email-masked]
>     <mailto:[email-masked]>>
>      >>> To: Parag Kaneriya <[email-masked]
>     <mailto:[email-masked]>>; Shraddha Hegde
>      >>> <[email-masked] <mailto:[email-masked]>>; Ron
>     Bonica <[email-masked] <mailto:[email-masked]>>; Rajesh M
>      >>> <[email-masked] <mailto:[email-masked]>>; William
>     Britto A J <[email-masked] <mailto:[email-masked]>>
>      >>> submission until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>.
>      >>>
>      >>> The IETF Secretariat
>      >>>
>      >> [email-masked] <mailto:[email-masked]>
>      > [email-masked] <mailto:[email-masked]>
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Wed, 30 Sep 2020 19:29:05 +0530

A quick question:

   If an IP address and a Flexible Algorithm are associated with the
   same interface, they are also associated with one another.  An IP
   address MAY be associated with, at most, one interface.

If multiple IP addresses and multiple flexible algorithms are associated
with a loopback interface, is each IP address associated with all flexible
algorithms? What matters is the association b/w an IP address and a
flexalgo, so the relationship should be defined in a direct way rather than
each being associated with an interface, right?

Regards,
Muthu

On Tue, Sep 29, 2020 at 7:07 PM Ron Bonica <rbonica=
[email-masked]> wrote:

> submission

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 30 Sep 2020 16:28:56 +0200

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.

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 ?

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.

But what if that next hop would happen to be covered by some aggregate
route not subject perhaps to intended IP TE ?

Cheers,
R.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 30 Sep 2020 14:55:29 +0000

Hi,

While it is possible to define algorithm-specific IP reachability TLVs to advertise IP Prefixes associated with different algorithms, this would introduce several new IS-IS top TLVs. One quick question is: can similar function be provided with extensions to existing IP reachability TLVs and MT IP reachability TLVs, instead of defining top TLVs for MT, Flex-Algo, and the combination of Flex-Algo and MT respectively?

And one nit in the encoding: the length of MT-ID in IS-IS should be 12 bits.

Best regards,
Jie

From: Lsr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, September 30, 2020 3:28 PM
To: Huzhibo <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

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 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.

Many thx,
R.

On Wed, Sep 30, 2020 at 6:10 AM Huzhibo <[email-masked]<mailto:[email-masked]>> wrote:
Hi Joel:

Thanks

Zhibo

-----Original Message-----
From: Lsr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Joel M. Halpern
Sent: Wednesday, September 30, 2020 12:05 PM
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

Yours,
Joel

On 9/29/2020 11:50 PM, Huzhibo wrote:
> From: Lsr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
> To: Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>
>> On Sep 29, 2020, at 6:37 AM, Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
>>
>>
>>> From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
>>> To: Parag Kaneriya <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde
>>> <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; Rajesh M
>>> <[email-masked]<mailto:[email-masked]>>; William Britto A J <[email-masked]<mailto:[email-masked]>>
>>> URL:            https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica-<https://urldefense.com/v3/__https:/www.ietf.org/id/draft-bonica->
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-b<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-b>
>>> o
>>> nica-lsr-
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dr<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/dr>
>>> a
>>> ft-
>>> Htmlized:       https://urldefense.com/v3/__https://tools.ietf.org/html/draft-<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft->
>>> submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>>>
>>> The IETF Secretariat
>>>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: Peter Psenak <[email-masked]>
Date: Wed, 30 Sep 2020 17:18:02 +0200

Robert,

On 30/09/2020 16:28, Robert Raszuk wrote:
> 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.

> 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.

> 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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Robert,
> 
>      >  > It uses the HBH option
>     <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     Hi Joel:
>      >
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>]
>     On Behalf Of Joel M. Halpern
>      >     Cc: [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >     "interesting" constraints before I understood why one would
>     even do
>      >     this.
>      >
>      >      > Hi.
>      >      >
>      >      > Associating multiple algorithms with a given prefix is an
>      >      >
>      >      > Thanks
>      >      >
>      >      > ZHibo
>      >      >
>      >      > -----Original Message-----
>      >      > From: Lsr [mailto:[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>]
>     On Behalf Of [email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      > Sent: Tuesday, September 29, 2020 10:05 PM
>      >      > To: Ron Bonica <rbonica=[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >      > Cc: [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      > 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
>      >      >
>      >      > One thing that you don’t talk about is how this gets used, tho
>      >      >
>      >      > 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
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >      >>
>      >      >>
>      >      >> Please review and comment
>      >      >>
>      >      >>                                        Ron
>      >      >>
>      >      >>
>      >      >>
>      >      >> Juniper Business Use Only
>      >      >>
>      >      >>> -----Original Message-----
>      >      >>> From: [email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>> <[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >      >>> Sent: Tuesday, September 29, 2020 9:36 AM
>      >      >>> To: Parag Kaneriya <[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>;
>     Shraddha Hegde
>      >      >>> <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>; Ron
>      >     Bonica <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>; Rajesh M
>      >      >>> <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>; William
>      >     Britto A J <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >      >>> 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:
>      >      >>> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
>      >      >>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$
>      >      >>> Status:
>      >      >>>
>      >      >>> o
>      >      >>> nica-lsr-
>      >      >>> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
>      >      >>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
>      >      >>> Htmlized:
>      >      >>>
>      >      >>> a
>      >      >>> ft-
>      >      >>> bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP-
>      >      >>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$
>      >      >>> Htmlized:
>      >      >>> 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
>      >      >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >      >> https://www.ietf.org/mailman/listinfo/lsr
>      >      >
>      >      > _______________________________________________
>      >      > Lsr mailing list
>      >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >      > https://www.ietf.org/mailman/listinfo/lsr
>      >      > _______________________________________________
>      >      > Lsr mailing list
>      >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >      > https://www.ietf.org/mailman/listinfo/lsr
>      >      >
>      >
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: Ron Bonica <[email-masked]>
Date: Wed, 30 Sep 2020 16:02:40 +0000

Hi Muthu,

Thanks for the review.

An interface can be associated with, at most, one Flexible Algorithm. Likewise, an IP address can be associated with, at most, one Flexible Algorithm.

I tried to express this in the text below, but probably didn't do a very good job. If you can think of a better way to say it, I would appreciate suggestions.

                                                  Ron

Text from draft
============

Network operators configure multiple loopback interfaces on an egress
   node.  They can associate each loopback interface with:

   o  Zero or more IP addresses.

   o  Zero or one Flexible Algorithms.

Juniper Business Use Only
From: Muthu Arul Mozhi Perumal <[email-masked]>
Sent: Wednesday, September 30, 2020 9:59 AM
To: Ron Bonica <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

A quick question:

If multiple IP addresses and multiple flexible algorithms are associated with a loopback interface, is each IP address associated with all flexible algorithms? What matters is the association b/w an IP address and a flexalgo, so the relationship should be defined in a direct way rather than each being associated with an interface, right?

Regards,
Muthu

On Tue, Sep 29, 2020 at 7:07 PM Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:

                                       Ron

> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-lsr-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-bonica-lsr->
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft->
> until the htmlized version and diff are available at tools.ietf.org<https://urldefense.com/v3/__http:/tools.ietf.org__;!!NEt6yMaO-gk!VQoAwwHICHoY23KWJbKL7SpeHYGiY6hT9pSpTh7Mfn5lQyaC9E5JcOlvhG1kuR-O$>.
>
> The IETF Secretariat
>
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!VQoAwwHICHoY23KWJbKL7SpeHYGiY6hT9pSpTh7Mfn5lQyaC9E5JcOlvhOxbdTsH$>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 30 Sep 2020 19:30:40 +0200

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 <[email-masked]> wrote:

> >      >      > More text on application would be most welcome, just to
> ensure
> >      >      >>> <[email-masked] <mailto:[email-masked]>
> >      >      >>> <[email-masked] <mailto:[email-masked]>
> >      >      >>> has been successfully submitted by Ron Bonica and posted
> >     to the
> >      >     IETF
> >      >      >>> repository.
> >      >      >>>
> >      >      >>>    An IGP Flexible Algorithm computes a constraint-based
> >     path
> >      >     and maps
> >      >      >>>    that path to an identifier.  As currently defined,
> >     Flexalgo
> >      >     can only
> >      >      >>>    This document extends Flexalgo, so that it can map
> >     the paths
> >      >     that it

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 30 Sep 2020 19:39:28 +0000

Ron -

Interesting proposal.

A few mundane - but I think still important - comments.

New IS-IS TLVs
--------------------

There is no need to have two TLVs for each address-family - one for MTID #0 and one for all non-zero MTIDs. One TLV/AF will suffice.
The reason we have separate TLVs today is because MT (RFC 5120)  came along after TLV 135/236 had been defined/deployed.
Since you have a greenfield here you can simply have one TLV/AF and allow all MTIDs (including 0).

MTID is a 16 bit field with 4 reserved bits and 12 bits used for MTID value.  (I believe someone else pointed this out as well.)
See RFC 5120.

You should specify that the new TLVs inherit the sub-TLV space defined in https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-135-235-236-237 

The U-bit
-------------

I appreciate that there is precedence for calling this the U-bit based on RFC 5308 - but I would prefer that you call it the D-bit.
Regardless of name, it MUST be consistent with existing usage - meaning it is set when the prefix is leaked downwards. Currently your text says:

"U (1 bit): Set indicates up.  Clear indicates down."

This needs to be reversed.

Constraints
---------------

I think you need to speak to various constraints including (but not limited to):

1)Algorithm is limited to flex-algo values (128-255)

I don't understand why Section 6 (main part - not the sub-sections) is there. What relevance do non-flex-algos have to this draft??

I also think the new sub-TLV would be better named "Native Flex-Algo Algorithm Sub-TLV".
Unless you are proposing to use this sub-TLV in ways not related to flex-algo - in which case I think you need to provide some explanation of the use case for this.

2)How to handle advertisement of same algo both in the new Algorithm sub-TLV and the existing SR Algorithm sub-TLV (prefer SR??)
Note that legacy routers may understand SR Algorithm Sub-TLV but not the new one.

   Les

> From: Lsr <[email-masked]> On Behalf Of Ron Bonica
> Sent: Tuesday, September 29, 2020 6:38 AM
> To: [email-masked]
> Subject: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-
> 00.txt
> 
>

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 30 Sep 2020 23:08:25 -0700

Hi Ron,

the readers would benefit if the draft would state that in order for the technology to work properly, there must be a contiguous set of connected routers that support it between the S/D, since lookup (route installed in context of the algo it is associated with) is done per hop.

Cheers,
Jeff
On Sep 30, 2020, 9:03 AM -0700, Ron Bonica <rbonica=[email-masked]>, wrote:
> I tried to express this in the text below, but probably didn’t do a very good job. If you can think of a better way to say it, I would appreciate suggestions.
>
>                                                   Ron
>
> Text from draft
> ============
>
> On Tue, Sep 29, 2020 at 7:07 PM Ron Bonica <rbonica=[email-masked]> wrote:
>