Subject: [Idr] Comments on draft-francois-idr-addpath-limit-00

From: Zhuangshunwan <[email-masked]>
Date: Thu, 6 Mar 2014 14:43:33 +0000

Dear Authors,

I have a comment, see inline begins with identifier [Vincent].
...
[draft-francois-idr-addpath-limit-00] defines the ADD-PATH Limit capability:
2. The ADD-PATH Limit capability
+------------------------------------------------+
| Address Family Identifier (2 octets)           |
+------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+------------------------------------------------+
| Flags(1 octet)                                 |
+------------------------------------------------+
| Receive bound (2 octet)                        |
+------------------------------------------------+

[Vincent] :
If limit-capable bit is set to 1, maybe we can add a field called 'Send upper bound' to signal
the upper bounds specified by the sender.
+------------------------------------------------+
| Address Family Identifier (2 octets)           |
+------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+------------------------------------------------+
| Flags(1 octet)                                 |
+------------------------------------------------+
| Receive bound (2 octet)                        |
+------------------------------------------------+
| Send upper bound (2 octet)                     |
+------------------------------------------------+

Benefit: Receiver can know sender's capability, and convenient for tuning the receive bound on demand.

Regards,
Vincent

---

From: Pierre Francois <[email-masked]>
Date: Thu, 6 Mar 2014 18:18:23 +0100

Dear Vincent, 

Thank you for your comment. 

What do you mean by "tuning on demand"?
To me, the limit on what the operator wants to receive was not depending on 
what the sender is capable of sending.  

Do you see a case where this would be different?

Regards, 

Pierre.

On Mar 6, 2014, at 3:43 PM, Zhuangshunwan <[email-masked]> wrote:

> …
> If limit-capable bit is set to 1, maybe we can add a field called ‘Send upper bound’ to signal
> Benefit: Receiver can know sender’s capability, and convenient for tuning the receive bound on demand.
>  
>  
> Regards,
> 
> Vincent
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Zhuangshunwan <[email-masked]>
Date: Fri, 7 Mar 2014 11:02:24 +0000

E.g.

Sender                                 Receiver
RTA------------------------------------RTB

RTA can send M paths, RTB wants the limit number to N,

If RTB knows that the Send upper bound of RTA, so RTB can figure out the appropriate number for N.

发件人: Pierre Francois [mailto:[email-masked]]
发送时间: 2014年3月7日 1:18
收件人: Zhuangshunwan
抄送: [email-masked]
主题: Re: [Idr] Comments on draft-francois-idr-addpath-limit-00

Dear Vincent,

Regards,

Pierre.

On Mar 6, 2014, at 3:43 PM, Zhuangshunwan <[email-masked]<mailto:[email-masked]>> wrote:

Dear Authors,

[Vincent] :

Regards,
Vincent
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 7 Mar 2014 12:16:40 +0100

It's impossible to know upper bound of RTA.

Add-paths has option all which means you are always able (by protocol spec)
to send all paths.

And how many paths you have is all dynamic .. depends how many you get from
your peers.

Peers may send one path or more .. in RS case it will be 1 path normally.

But it does not make sense IMHO to communicate to RTB how many peers I have
configured and in up state on RTA. When peers go down we would need to
communicate again which as said already can not be done by capabilities
anyway. Even with ORF I think this is unnecessary overhead.

Best,
R.

On Fri, Mar 7, 2014 at 12:02 PM, Zhuangshunwan <[email-masked]>wrote:

> *发件人:* Pierre Francois [mailto:[email-masked]]
> *发送时间:* 2014年3月7日 1:18
> *收件人:* Zhuangshunwan
> *抄送:* [email-masked]
> *主题:* Re: [Idr] Comments on draft-francois-idr-addpath-limit-00
>
>
>
>
>
>
>
> Dear Vincent,
>
>
>

---

From: Thomas Mangin <[email-masked]>
Date: Fri, 7 Mar 2014 12:59:40 +0000

Hello Francois,

In order to future proof this capability, as RFC 3392 does not say anything about how to handle extra data in a capability, should the wording of the draft be updated to indicate that the receiver MUST ignore any extra data after the Receive bound if some unknown flags are set ?

Thomas

---

From: Pierre Francois <[email-masked]>
Date: Fri, 7 Mar 2014 15:34:48 +0100

Hello Thomas, 

This sounds reasonable.

Cheers,

Pierre.

---

From: "Saikat Ray (sairay)" <[email-masked]>
Date: Tue, 11 Mar 2014 22:19:25 +0000

Vincent:

Are you trying to efficiently distribute the “quota” of paths among the neighbors? E.g., if RTB can only accept 10 paths and has 2 neighbors, RTA, and RTZ, if it is known to RTB that RTA can only send 3 paths, then it can request 7 paths from RTZ instead of requesting 5 paths from both. If this is what you are thinking of, then

(i)                 RTA wouldn’t really know in advance how many paths it will have that would be eligible to be sent to RTB. The number of paths may be different from one route to another. Even the number of neighbors of RTA isn’t always an upper bound – some of RTA’s neighbor might be using add-path.

(ii)               The capabilities are usually sent in parallel (i.e. RTB and RTA would independently format their capabilities and send them to each other as soon as the tcp connection comes up). Having a dependency here is not desirable.

(iii)             Do you have any concrete use case?

Thanks.

From: Idr [mailto:[email-masked]] On Behalf Of Zhuangshunwan
Sent: Friday, March 07, 2014 3:02 AM
To: Pierre Francois
Cc: [email-masked]
Subject: Re: [Idr] Comments on draft-francois-idr-addpath-limit-00

E.g.

Sender                                 Receiver

发件人: Pierre Francois [mailto:[email-masked]]
发送时间: 2014年3月7日 1:18
收件人: Zhuangshunwan
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [Idr] Comments on draft-francois-idr-addpath-limit-00

Dear Vincent,

Regards,

Pierre.

Dear Authors,

[Vincent] :

Regards,
Vincent

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 11 Mar 2014 23:19:43 +0000

OMG, this is too hard.
How about you just send all the paths and the receiver drops what it doesn’t like after performing path selection.
Then when you withdraw a path, you have to repeat the non-withdrawn ones again.
If the receiver cares about redundancy and fast convergence for a net, it will keep more paths, else just one.
This behavior would need a capability.
Not cheap, but then addpath isn’t cheap.

Cheers,
Jakob.

From: Idr [mailto:[email-masked]] On Behalf Of Saikat Ray (sairay)
Sent: Tuesday, March 11, 2014 3:19 PM
To: Zhuangshunwan; Pierre Francois
Cc: [email-masked]
Subject: Re: [Idr] Comments on draft-francois-idr-addpath-limit-00

Vincent:

Thanks.

From: Idr [mailto:[email-masked]] On Behalf Of Zhuangshunwan
Sent: Friday, March 07, 2014 3:02 AM
To: Pierre Francois
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] Comments on draft-francois-idr-addpath-limit-00

E.g.

Sender                                 Receiver

Dear Vincent,

Regards,

Pierre.

Dear Authors,

[Vincent] :

Regards,
Vincent

---

From: Ilya Varlashkin <[email-masked]>
Date: Wed, 12 Mar 2014 03:10:35 +0000

Jakob,

as an operator I wouldn’t want to send several dozen full tables between fully meshed ibgp speakers. For bigger operators that number could probably go much higher.

Kind regards,
iLya

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 12 Mar 2014 03:25:15 +0000

Then don’t. The sender is free to send as few or as many as it wants.
My suggestion frees the sender from constraints imposed by the receiver, not the operator.

Thanks,
Jakob.

From: Ilya Varlashkin [mailto:[email-masked]]
Sent: Tuesday, March 11, 2014 8:11 PM
To: Jakob Heitz
Cc: Saikat Ray (sairay); Zhuangshunwan; Pierre Francois; IETF IDR
Subject: Re: [Idr] Comments on draft-francois-idr-addpath-limit-00

Jakob,

Kind regards,
iLya

On 11 Mar 2014, at 23:19, Jakob Heitz <[email-masked]<mailto:[email-masked]>> wrote:

OMG, this is too hard.

Cheers,
Jakob.

Vincent:

Thanks.

E.g.

Sender                                 Receiver

Dear Vincent,

Regards,

Pierre.

Dear Authors,

[Vincent] :

Regards,
Vincent

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Wed, 12 Mar 2014 10:30:04 +0000

In the VPNV4 space we send multiple copies of a subset of paths by using a unique RD. The number of paths are generally unique when arriving from different egress speakers. IMO the challenge in the internet case is to identify the subset of paths that that should be propagated across the topology requiring fast convergence, load balancing ….

Jim Uttaro

From: Idr [mailto:[email-masked]] On Behalf Of Ilya Varlashkin
Sent: Tuesday, March 11, 2014 11:11 PM
To: Jakob Heitz
Cc: IETF IDR
Subject: Re: [Idr] Comments on draft-francois-idr-addpath-limit-00

Jakob,

Kind regards,
iLya

OMG, this is too hard.

Cheers,
Jakob.

Vincent:

Thanks.

E.g.

Sender                                 Receiver

Dear Vincent,

Regards,

Pierre.

Dear Authors,

[Vincent] :

Regards,
Vincent

---

From: "Simpson, Adam (Adam)" <[email-masked]>
Date: Wed, 12 Mar 2014 15:13:56 +0000

I agree. The capability was proposed to solve simple use cases — nothing as complicated as outlined below.

Consider an IBGP/RR case. (The RS case is similar though.) I believe the most common current practice is to configure Add-N mode on the RR towards Add-Path enabled clients.  Today N needs to be configured statically. Several implementations allow N to be configured differently per client peer, so how do you set N in that case? If you know a client can ‘use' no more than 3 paths as a result of the way its multipath and backup path features are enabled then it would make sense to set N to no larger value than 3; additional paths beyond 3 are just overhead for the client, overhead for the RR and overhead in terms of control plane traffic. If an RR has 100s of clients the task of coordinating the N values for each session could be somewhat time-consuming and error prone, so why not allow each client to signal the number of paths it wants to receive to simplify this coordination? I suspect that  client configuration affecting the max. number of paths they can be ‘used' does not change very frequently, so I see this as more of an isolated one-time event as opposed to a constant re-renegotiation of N.

-Adam

From: Jakob Heitz <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 11, 2014 at 7:19 PM
To: "Saikat Ray (sairay)" <[email-masked]<mailto:[email-masked]>>, Zhuangshunwan <[email-masked]<mailto:[email-masked]>>, Pierre Francois <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Comments on draft-francois-idr-addpath-limit-00

OMG, this is too hard.

Cheers,
Jakob.

Vincent:

Thanks.

E.g.

Sender                                 Receiver

Dear Vincent,

Regards,

Pierre.

Dear Authors,

[Vincent] :

Regards,
Vincent

---

From: Vitkovský Adam <[email-masked]>
Date: Thu, 13 Mar 2014 12:41:48 +0000

Hello,

I’d like to ask regarding the interoperability between the addpath and addpath-limit features.

Have you please considered some fallback mechanism in case the limit capability is not signaled by the receiver/client.
(Possible fallback modes on the sending node: All paths; N number of paths; 1 best-path.
Or is this going to be taken care of by the existing add-path settings please?

Regarding the precedence of the features.
Consider a scenario when RR has 10 paths available but there’s a limit of 5 paths set by the addpath feature (as per standard peer template).
Now the addpath-limit feature is enabled between RR and the particular client.
And the client requests 10 paths as the upper bound.
Should the RR advertise 10 paths or just 5 paths as per the addpath limit please?

adam

From: Idr [mailto:[email-masked]] On Behalf Of Simpson, Adam (Adam)
Sent: Wednesday, March 12, 2014 4:14 PM
To: Jakob Heitz; Saikat Ray (sairay); Zhuangshunwan; Pierre Francois
Cc: [email-masked]
Subject: Re: [Idr] Comments on draft-francois-idr-addpath-limit-00

-Adam

OMG, this is too hard.

Cheers,
Jakob.

Vincent:

Thanks.

E.g.

Sender                                 Receiver

Dear Vincent,

Regards,

Pierre.

Dear Authors,

[Vincent] :

Regards,
Vincent

---

From: "Simpson, Adam (Adam)" <[email-masked]>
Date: Thu, 13 Mar 2014 13:58:31 +0000

The new proposed capability signals an upper bound on the number of received paths per NLRI. This is just one more factor that the sender takes into account when selecting the paths to advertise to the receiving peer. It’s very possible that fewer than the receive-limit number of paths may be advertised based on the policy configuration of the sender and/or the number of paths known to the sender.

-Adam

From: Vitkovský Adam <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 13, 2014 at 8:41 AM
To: Adam Simpson <[email-masked]<mailto:[email-masked]>>, Jakob Heitz <[email-masked]<mailto:[email-masked]>>, "Saikat Ray (sairay)" <[email-masked]<mailto:[email-masked]>>, Zhuangshunwan <[email-masked]<mailto:[email-masked]>>, Pierre Francois <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Idr] Comments on draft-francois-idr-addpath-limit-00

Hello,

adam

-Adam

OMG, this is too hard.

Cheers,
Jakob.

Vincent:

Thanks.

E.g.

Sender                                 Receiver

发件人: Pierre Francois [mailto:[email-masked]]
发送时间: 2014年3月7日 1:18
收件人: Zhuangshunwan
抄送:[email-masked]<mailto:[email-masked]>
主题: Re: [Idr] Comments on draft-francois-idr-addpath-limit-00

Dear Vincent,

Regards,

Pierre.

Dear Authors,

[Vincent] :

Regards,
Vincent