Hi Aijun,
> 1) Consider in the BGP scenario: every PE may receive the routes from other
> PEs, right? So, using the PUB/SUB model, every PE should subscribe the status
> of the other PEs, right?
My understanding is that a PE typically only has tunnels to some other select
number of PEs.
Hi, Christian、Robert、Tony:
1) Consider in the BGP scenario: every PE may receive the routes from other
PEs, right? So, using the PUB/SUB model, every PE should subscribe the status
of the other PEs, right?
2) Consider in the tunnel scenario: every PE/P may select other PE/P as the
tunnel
Hi Les,
I think using IGP to *discover* some services is perfectly fine.
For example many years ago I proposed to use IGP to automatically discover
BGP route reflectors for the sole purpose of bgp auto discovery. After that
originally BGP friends suggested that we will do faster if we do not
Robert –
Please read more carefully.
The draft introduces “a protocol(service) that will provide prompt notification
of changes in node liveness…”
What I am talking about here is NOT the information being sent by the service –
but rather the service itself. Advertisement of the
Hi Les,
> Advertisement of the availability of an application is not within the
scope of an IGP
Who proposes that ?
AFAIK protocol Tony proposed indicates livness of an IGP node and
specifically not any application on that node.
Thx,
R.
On Mon, Jan 24, 2022 at 9:24 PM Les Ginsberg
Peter Psenak writes:
On 24/01/2022 16:19, Christian Hopps wrote:
Peter Psenak writes:
Chris,
On 24/01/2022 10:29, Christian Hopps wrote:
Again KISS applies here:
If the summarization process *doesn't work* for a given prefix P, then
*don't use summarization* for prefix P!
Tony –
Advertisement of the availability of an application is not within the scope of
an IGP no matter what level of TLV you use to do so.
Existing capability advertisements (e.g., flex-algo participation, SR ) are
indicators of what the IGP implementation supports and/or is configured to
Les,
> My precedent is the use Router Capability for advertising FlexAlgo
> definitions. This is a service being provided by the area and it seems
> equally relevant. Would you prefer a top level TLV?
>
> [LES:] Flex Algo is a routing calculation being performed by the IGPs who
> also
Tony –
Inline.
From: Tony Li On Behalf Of Tony Li
Sent: Monday, January 24, 2022 10:15 AM
To: Les Ginsberg (ginsberg)
Cc: lsr
Subject: Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt
Hi Les,
Thank you for commenting.
I am not enthused about this solution. Full mesh
Hi Les,
Thank you for commenting.
> I am not enthused about this solution. Full mesh isn’t appealing at scale.
> But I recognize this as an alternative which some might find useful in some
> deployments.
Is it clear that the full mesh is only at the ABR level?
> I also understand why and
Tony -
I am not enthused about this solution. Full mesh isn't appealing at scale. But
I recognize this as an alternative which some might find useful in some
deployments.
I also understand why and find it appropriate that you have introduced
discussion of this alternative in LSR. But
Hi Peter,
> - nobody claims every PE needs to talk to every PE. But any PE in any
> area may need to talk to some PEs from other areas.
Thx for admitting that true statement.
The issue with PULSE is then why to send PULSES to those PEs which do not
need them ? Same for all the P routers which
On 24/01/2022 16:19, Christian Hopps wrote:
Peter Psenak writes:
Chris,
On 24/01/2022 10:29, Christian Hopps wrote:
Again KISS applies here:
If the summarization process *doesn't work* for a given prefix P, then
*don't use summarization* for prefix P!
above simply does not
Indeed. If you have unreliable registrations, and a registration is lost, then
subsequent notifications would be lost as well. The entire service could yield
no results. What is the use case?
On the bright side, you can always claim that the service is already deployed
and you just happened
Yours is a good operational point, Robert. I wonder what others might think.
Regards,
Greg
On Mon, Jan 24, 2022 at 9:30 AM Robert Raszuk wrote:
>
> Are you sure this is operationally a good idea ?
>
> It's cool when registrations and up notifications will not get lost. But I
> would not like
Are you sure this is operationally a good idea ?
It's cool when registrations and up notifications will not get lost. But I
would not like to be the one troubleshooting a network when some
registrations or up notifications packets get lost ... It sounds like a
nightmare to me.
Best,
R.
On Mon,
Frankly, I don't see that registrations, at least for the node liveness use
case, require using reliable transport. If the registration is lost, the
faster convergence doesn't work for that node but the existing slower
mechanism still does the job done. I want to note that I'm not proposing
Hi Robert,
thank you for clearly stating the question I was implying - Is the reliable
distribution of notifications a requirement or recommendation? I think it
is the latter. In some scenarios and use cases, for example, when the
pub-sub provides the critical service that doesn't have a backup
Hi Greg,
> thank you for your responses to my notes. I should have been more clear in
> explaining the rationale for adding the UDP transport option to the list.
> Reliability comes at a cost. If the system already has a mechanism that
> guarantees convergence a faster, lightweight though not
Hi Greg,
Granted you are correct, but only if we consider p2p distribution and low
level triggers. You are also correct if we would just be continue to use
PULSE style. But Tony's proposal is fundamentally different. It does not
send PULSE and forgets. It distributed node liveness both down and
Hi Tony and Robert,
thank you for your responses to my notes. I should have been more clear in
explaining the rationale for adding the UDP transport option to the list.
Reliability comes at a cost. If the system already has a mechanism that
guarantees convergence a faster, lightweight though not
Hi Greg,
> I got to think about the benefits of using reliable transport for
> notifications. If I understand the use case correctly, the proposed mechanism
> allows for a faster convergence but is supplemental to slower BGP
> convergence. If that is the case, it seems that if a subscriber to
Peter Psenak writes:
Chris,
On 24/01/2022 10:29, Christian Hopps wrote:
Again KISS applies here:
If the summarization process *doesn't work* for a given prefix P, then
*don't use summarization* for prefix P!
above simply does not work.
1. so far nobody summarizes and it all
Hi Gyan,
> So basically the event notification process done in PUAM / Pulse inband, here
> we are using an out-of-band transport protocol QUIC / TCP for the Publisher
> RDB registration DB service on the ABRs which advertises the node liveliness
> service into the L1 and L2 areas for
Hi Greg,
Thank you for your suggestions.
> It seems that referencing the multi-hop BFD [RFC5883] in the Introduction
> section as the existing mechanism detecting the node liveness can make the
> document more thorough.
While I have no objection to being thorough, being that thorough would
Chris,
On 24/01/2022 10:29, Christian Hopps wrote:
"Aijun Wang" writes:
Hi, Chris:
We should notice here that it is not "a prefix", it's possible for "all node's
loopback address, or even some link's address".
Gyan's reference for RFC5302 state clearly the disadvantage of
Chris,
Of course there are more prefixes then PEs in the IGP.
But I understood as in the light of this discussion some folks attempted to
say that you can trim that set even more.
So for the purpose of the topic I would rather call them as service
endpoint nodes and do not attempt to make an
Robert Raszuk writes:
Chris,
I would like to state one important point ...
Some folks used terms "for those special prefixes" or "super
important prefixes" only to smooth the discussion. But there is not
such a thing. All what is being discussed is all PEs. Some want to
also add SR
Chris,
I would like to state one important point ...
Some folks used terms "for those special prefixes" or "super important
prefixes" only to smooth the discussion. But there is not such a thing.
All what is being discussed is all PEs. Some want to also add SR segment
endpoints.
No one will
On Mon, Jan 24, 2022 at 5:43 AM Gyan Mishra wrote:
>
>
> Hi Chris
>
>
> Just about every vendor out there recommended best practice is to layout
> address plan to take advantage of summarization wherever possible and that
> as well includes PE loopback next hop attribute to limit the router load
Aijun,
> and the operators have followed this approach also about 20 years
For the record that assertion is just not true.
Most operators for over 20 years run MPLS encapsulation and with that they
are already leaking *all* loopbacks of the edge nodes domain wide. None of
the networks have
Hi, Christian:
OK, let's try to converge into one standard. But it should be IGP based, or
else should be discussed by other WG.
Best Regards
Aijun Wang
China Telecom
-Original Message-
From: Christian Hopps
Sent: Monday, January 24, 2022 11:48 AM
To: Aijun Wang
Cc: 'Christian
Hi, Chris:
We should notice here that it is not "a prefix", it's possible for "all node's
loopback address, or even some link's address".
Gyan's reference for RFC5302 state clearly the disadvantage of
non-summarization, and the operators have followed this approach also about 20
years, then you
Hi Greg,
> as that node will catch up with "luckier" neighbors eventually.
The crux of the matter is that there is no "luckier" neighbors. There is no
database synchronization. Sure service will eventually converge, but what
is being tried here is to trigger data plane switchover a bit faster.
34 matches
Mail list logo
