Hi, Tony:
We are trying to reuse the existing mechanism to solve such problem, but as
mentioned in
https://mailarchive.ietf.org/arch/msg/lsr/kTWLct7VgEfOxexdwzwcFS3Ctqc/:
"[WAJ] Reuse the Link TLV that defined in inter-AS-TE-v2/v3 to contain such
information is possible, but we should still
Hi Aijun,
> Just because some mechanism wants to use toplogy information does NOT imply
> that it should be part of the routing protocol.
>
> In this case, load balancing should be an independent mechanism. If it wants
> to peek into the LSDB, that would be perfectly acceptable, IMHO.
>
Hi, Tony:
From: lsr-boun...@ietf.org On Behalf Of Tony Li
Sent: Tuesday, January 11, 2022 4:20 AM
To: Aijun Wang
Cc: Les Ginsberg (ginsberg) ; lsr
; Linda Dunbar
Subject: Re: [Lsr] Seeking feedback to the revised
draft-dunbar-lsr-5g-edge-compute
On Jan 10, 2022, at 9:05 AM, Aijun
Les,
> [LES:] I believe some of the alternate proposals are tractable – which is not
> to say that I prefer them.
> But I don’t want to ask questions like “How do you do this…?” in the absence
> of a writeup. I am assuming that if we had a writeup the authors would have
> done their best to
Hi, Les:
From: Les Ginsberg (ginsberg)
Sent: Tuesday, January 11, 2022 4:55 AM
To: Aijun Wang ; Les Ginsberg (ginsberg)
Cc: lsr@ietf.org; Linda Dunbar
Subject: RE: [Lsr] Seeking feedback to the revised
draft-dunbar-lsr-5g-edge-compute
Aijun –
Top posting here.
I think what is
Hi Aijun,
> For the AS boundary use case, do you have other better solution?
Is there some way that this could be modeled as a normal link instead of a stub
link? In any case, I am not responsible for coming up with a better solution.
The onus is on you to convince us that this is a Good
Hi, Tony:
For the AS boundary use case, do you have other better solution?
I have responded to Les for his mentioned/insisted unnumbered link scenario. if
it is acceptable, is it the general design then?
Best Regards
Aijun Wang
China Telecom
-Original Message-
From:
Hi, Les:
There is the way to solve your concern.
1.
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-02#section-4.1
and
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-02#section-4.2
includes also the sub-TLVs field, which is pointed to the
Tony –
Probably too many emails in one day on this – but did want to respond to a few
points.
Inline.
From: Tony Li On Behalf Of Tony Li
Sent: Monday, January 10, 2022 5:35 PM
To: Les Ginsberg (ginsberg)
Cc: Christian Hopps ; Peter Psenak (ppsenak)
; Robert Raszuk ; Shraddha Hegde
; Aijun
Hi Greg
Thanks for the reference.
Agreed on the different UDP port 3784 and 4784 to differentiate the single
hop and multi hop sessions respectively.
In the multi hop BFD scenario to monitor the egress PE loopbacks in the
case where an RR exists and all PEs are Route-Reflector Clients, the BFD
Hi Gyan,
thank you for sharing the operator's perspective and experience on using
the multi-hop BFD. Thinking of additional challenges, I may add the
authentication of BFD Control packets. But the extra-processing can be
significantly reduced by draft-ietf-bfd-optimizing-authentication-13 -
I think the point is that just saying:
>> And if customers could do what he suggested then they would not have an
>> issue.
>>
>> But there are deployments where what he suggested is not possible – largely
>> I think because the set of “prefixes of interest” is in itself large.
maybe isn't
Greg
I believe the scalability context for multi hop BFD is the operational
complexity introduced with the number of sessions especially within very
large domains with inordinate number of routers. Single hop BFD is more
manageable and is predominately user by operators for underlay failure
Les,
> I could be more specific regarding my opinion about various alternatives that
> have been mentioned (BFD, OAM, BGP, pub-sub) – but it doesn’t make sense to
> me to comment on proposals which have not actually been defined.
The proposals have been put forth in adequate detail for a
Hi Les,
do you see anything that requires further specification in addition to RFC
5883?
Regards
Greg
On Mon, Jan 10, 2022, 17:14 Les Ginsberg (ginsberg) wrote:
> Tony –
>
>
>
> I could be more specific regarding my opinion about various alternatives
> that have been mentioned (BFD, OAM, BGP,
Tony –
I could be more specific regarding my opinion about various alternatives that
have been mentioned (BFD, OAM, BGP, pub-sub) – but it doesn’t make sense to me
to comment on proposals which have not actually been defined.
If someone (not necessarily you) wants to write up any of these
Hi Les,
in this case, using multi-hop BFD will add, in my estimation, 10 Mbyte/sec
of extra traffic if the network is IPv4. Is it a real scaling concern these
days?
Regards,
Greg
On Mon, Jan 10, 2022 at 4:44 PM Les Ginsberg (ginsberg)
wrote:
> Some comments from Robert offline cause me to
> On Jan 10, 2022, at 4:44 PM, Les Ginsberg (ginsberg)
> wrote:
>
> As BFD sessions are bidirectional we are talking about a Combination of (n,2)
> – so in the case of 500 nodes the actual number of BFD sessions network-wide
> is 124750.
Which sounds terrifying until you realize that it’s
Some comments from Robert offline cause me to issue a correction.
As BFD sessions are bidirectional we are talking about a Combination of (n,2) –
so in the case of 500 nodes the actual number of BFD sessions network-wide is
124750.
Les
From: Lsr On Behalf Of Les Ginsberg (ginsberg)
Sent:
The point I am making is that the total number of BFD sessions in the
entire network is irrelevant.
While looking scary (even if divided by 2) those numbers should not be
even exposed to operators or used as counterargument. What may matter is a
hypothetical scale on a per smallest PE * number of
Les,
> And if customers could do what he suggested then they would not have an issue.
>
> But there are deployments where what he suggested is not possible – largely I
> think because the set of “prefixes of interest” is in itself large.
Well, the alleged customers have not come forward to
Robert –
The numbers are network-wide – not per node.
And no one has mentioned config as an issue in this thread – though no doubt
some operators might have concerns in that area.
Les
From: Robert Raszuk
Sent: Monday, January 10, 2022 4:30 PM
To: Les Ginsberg (ginsberg)
Cc: Greg Mirsky ;
Hi Les,
*[LES:] Even a modest sized N = 100 (which is certainly not a high number)
> leads to 1 BFD sessions. N= 500 => 250,000 sessions. Etc.*
>
>
Are you doing N^2 ? Why ? All you need to keep in mind is number of those
sessions per PE so in worst case (N-1) - here 99 and 499.
And as we
Greg –
Inline.
From: Greg Mirsky
Sent: Monday, January 10, 2022 3:36 PM
To: Les Ginsberg (ginsberg)
Cc: Tony Li ; Christian Hopps ; Robert
Raszuk ; Aijun Wang ; Shraddha
Hegde ; Hannes Gredler ; lsr
; Peter Psenak (ppsenak)
Subject: Re: [Lsr] BGP vs PUA/PULSE
Hi Les,
thank you for the
Hi Les,
*> You seem focused on the notification delivery mechanism only.*
Not really. For me, an advertised summary is like a prefix when you are
dialing a country code. Call signaling knows to go north if you are calling
a crab shop in Alaska.
Now such direction does not indicate if the shop
Robert -
From: Robert Raszuk
Sent: Monday, January 10, 2022 2:56 PM
To: Les Ginsberg (ginsberg)
Cc: Tony Li ; Christian Hopps ; Peter
Psenak (ppsenak) ; Shraddha Hegde ;
Aijun Wang ; Hannes Gredler ; lsr
Subject: Re: [Lsr] BGP vs PUA/PULSE
Les,
We have received requests from real
Tony –
I understand what Chris wrote.
And if customers could do what he suggested then they would not have an issue.
But there are deployments where what he suggested is not possible – largely I
think because the set of “prefixes of interest” is in itself large.
So while not all customers have
Les,
The obvious issue is scale. Since you need a full mesh you are talking
> about N**2 behavior – so it doesn’t take many nodes to require thousands of
> BFD sessions.
>
That does sound scary doesn't it ? 1000s is a rather big number ... :)
Well good news is that we have recently finished
Hi Les,
thank you for the detailed clarifications. Please find my follow-up notes
in-lined below under the GIM>> tag.
Regards,
Greg
On Mon, Jan 10, 2022 at 3:19 PM Les Ginsberg (ginsberg)
wrote:
> Greg –
>
>
>
> The obvious issue is scale. Since you need a full mesh you are talking
> about
> we are trying to get an order of magnitude improvement from normal BGP
> session timers
>
Please observe that "normal BGP session timers" play no role in this if we
are serious about the objective.
Just like ABR get's the information about PE down events so can the local
area BGP Route
Greg –
The obvious issue is scale. Since you need a full mesh you are talking about
N**2 behavior – so it doesn’t take many nodes to require thousands of BFD
sessions.
In terms of detect time, we are trying to get an order of magnitude improvement
from normal BGP session timers – so we are
Les,
> We have received requests from real customers who both need to summarize
> AND would like better response time to loss of reachability to individual
> nodes.
>
We all agree the request is legitimate.
But do they realize that to practically employ what you are proposing (new
PDU
Hi Les,
thank you for bringing the real-life scenarios to the discussion. In your
opinion, what prevents an operator from monitoring a remote PE using a
multi-hop BFD? Do you have an estimated number of such sessions each PE
must handle? What could be the required guaranteed failure detection
Chris/Tony -
We have received requests from real customers who both need to summarize AND
would like better response time to loss of reachability to individual nodes.
If they could operate at the necessary scale without summarizing they would
have already - so telling customers to simply make
Aijun –
Top posting here.
I think what is desired is load balancing at the application layer – coupled
with persistence of a given flow (AKA client-server connection). You aren’t
going to achieve that by dynamically adjusting IGP costs.
And you are likely to get oscillation – which is
I object to the adoption of this draft.
I don’t think that it’s fundamentally a correct approach.
One of the important things that we’ve learned over the years is that we need
to build general designs and not simply add new elements and mechanisms for
each use case that we think of.
I
> On Jan 10, 2022, at 9:05 AM, Aijun Wang wrote:
>
> [WAJ] Selecting the most appropriate/optimized application server should base
> on the topology information which is routing protocol related.
Just because some mechanism wants to use toplogy information does NOT imply
that it should be
Aijun -
Please see inline.
> -Original Message-
> From: Aijun Wang
> Sent: Monday, January 10, 2022 8:34 AM
> To: Les Ginsberg (ginsberg)
> Cc: Christian Hopps ; lsr@ietf.org; lsr-cha...@ietf.org;
> lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
> Subject: Re: [Lsr] WG
yes, first, if you abstract in _any_ way (except a full mesh for a single
metric) you will end up with suboptimal paths (compared to global, flat
topology view) traversing an abstracted subgraph and different ECMP
behavior in corner cases, it's basic graph theory (aggravated by hop-by-hop
or
I'll defer to Tony but my understanding is that there could be suboptimal paths
if there are both Level-1 and Level-2 paths but not loops.
Thanks,
Acee
On 1/10/22, 11:38 AM, "Aijun Wang" wrote:
But there are unsolved issues for this draft—— BGP has loop prevention
mechanism, current
Hi, Les:
Aijun Wang
China Telecom
> On Jan 10, 2022, at 23:48, Les Ginsberg (ginsberg)
> wrote:
>
>
> Linda –
>
> I believe the most valuable feedback you received during your presentation at
> IETF 112 is that using IGPs likely will not meet the deployment requirements.
> In particular,
But there are unsolved issues for this draft—— BGP has loop prevention
mechanism, current flood reflection draft hasn’t, the operator must design the
topology/link metric carefully to avoid the possible loop.
Aijun Wang
China Telecom
> On Jan 11, 2022, at 00:10, Acee Lindem (acee)
> wrote:
Hi, Les:
Wish the below explanation can correct your understanding of this draft, and
also your conclusions.
Aijun Wang
China Telecom
> On Jan 10, 2022, at 23:13, Les Ginsberg (ginsberg)
> wrote:
>
> I oppose WG adoption of this draft.
>
> In addition to my comments below, I am in
Speaking as a WG member, these documents are all "experimental" and, IMO, it
would really stifle innovation to require a single experimental solution. We've
never done that in the past. Also, while all three solutions have the goal of
reducing control plane overhead when using Level-1 areas as
Linda –
I believe the most valuable feedback you received during your presentation at
IETF 112 is that using IGPs likely will not meet the deployment requirements.
In particular, persistence of a given client session with a given application
server is likely a requirement which will not be
+1
Hopefully this would help us understand the use cases better and why/if more
than one solution might be appropriate.
Can’t happen too soon IMO.
Les
From: Jeff Tantsura
Sent: Monday, January 3, 2022 11:21 AM
To: Tony Przygienda
Cc: Christian Hopps ; Les Ginsberg (ginsberg)
; lsr ;
I oppose WG adoption of this draft.
In addition to my comments below, I am in agreement with the points made by
Peter and Shraddha previously in this thread.
My comments below are in the context of IS-IS/RFC5316, but I believe are
equally valid in the context of OSPF/RFC5392.
There are two
47 matches
Mail list logo
