Sorry important correction in comparison PUB/SUB to PUAM/PULSE with regards
to flooding to be fair.
PUAM/PULSE use IGP flooding which is hop by propagation of the good or bad
news so all nodes in the area are in scope in the flood.
PUB/SUB focuses the interesting traffic on BGP egress PEs that
Maybe even use SDN / PCE centralized controller , stateful PCE which has
peer to each node to instantiate the LSP as well as now manage the
component prefixes state. So we can drift completely out of the IGP realm
but we are choosing to stay in IGP realm with PUB/SUB.
The PUB/SUB model has been
Hi, Robert:
From: Robert Raszuk
Sent: Wednesday, January 26, 2022 7:58 AM
To: Aijun Wang
Cc: lsr ; Tony Li
Subject: Re: [Lsr] BGP vs PUA/PULSE
I think we have to accept that we have very different understanding on what
out-of-band means. But let's not get hang on this here
I think we have to accept that we have very different understanding on what
out-of-band means. But let's not get hang on this here.
Because to do it efficiently and in scalable manner close cooperation with
LSDB is required. Management system is completely orthogonal to that.
IMO Tony's proposal
Hi, Robert:
Then why not let all of these out of band messages delivered via the management
system?
Aijun Wang
China Telecom
> On Jan 25, 2022, at 23:28, Robert Raszuk wrote:
>
>
>
> Auto discovery is described in the draft.
>
> You may also provision this session by your management
t; -Original Message-
> From: lsr-boun...@ietf.org On Behalf Of Tony Li
> Sent: Tuesday, January 25, 2022 3:25 PM
> To: Aijun Wang
> Cc: Les Ginsberg (ginsberg) ; Gyan Mishra
> ; Peter Psenak
;
> Christian Hopps ; Robert Raszuk ;
lsr
>
Auto discovery is described in the draft.
You may also provision this session by your management plane just like you
push 1000s of configuration lines anyway to each network element.
Those are commonly used techniques to run a network.
On Tue, Jan 25, 2022 at 4:07 PM Aijun Wang
wrote:
> Or, I
Or, I guess you still need the ABR to act as the server. But, how these RRs
know which router is ABR?
Aijun Wang
China Telecom
> On Jan 25, 2022, at 23:01, Aijun Wang wrote:
>
> Hi, Robert:
>
> You mean make every PE as the register server?
>
> Aijun Wang
> China Telecom
>
>>> On Jan 25,
No. Run this node liveness service on ABR or on any other IGP node in an
area.
On Tue, Jan 25, 2022 at 4:01 PM Aijun Wang
wrote:
> Hi, Robert:
>
> You mean make every PE as the register server?
>
> Aijun Wang
> China Telecom
>
> On Jan 25, 2022, at 21:21, Robert Raszuk wrote:
>
>
> Aijun,
>
Hi, Robert:
You mean make every PE as the register server?
Aijun Wang
China Telecom
> On Jan 25, 2022, at 21:21, Robert Raszuk wrote:
>
>
> Aijun,
>
>> No, I think you misunderstanding our purpose.
>
> You are using this argument towards a number of people ... I recommend you
>
Aijun,
No, I think you misunderstanding our purpose.
>
You are using this argument towards a number of people ... I recommend you
reconsider.
> The proposed solution can fit in small network, or large network and RR
> can locate anywhere the operator want to place. We have no assumption about
Hi, Robert:
No, I think you misunderstanding our purpose. The proposed solution can fit in
small network, or large network and RR can locate anywhere the operator want to
place. We have no assumption about the location of RR and PEs.
Aijun Wang
China Telecom
> On Jan 25, 2022, at 21:03, Robert
Aijun,
The solution can’t rely only on the limited assumption.
>
And the protocol extensions can not be justified based on the limited
corner cases of broken network designs.
And, actually, the PE are Provider Edge Router, we always locate them at
> the non-backbone area in large network ,
an Mishra
Cc: Christian Hopps ; Aijun Wang ;
Hannes Gredler ; John E Drake ; Les
Ginsberg (ginsberg) ; Peter Psenak (ppsenak)
; Robert Raszuk ; Shraddha Hegde
; Tony Li ; lsr
Subject: Re: [Lsr] BGP vs PUA/PULSE
Ok, I guess I'll repeat what I said, as I don't believe anything new was
prese
Hi, Robert:
The deployment of IGP and BGP is decoupled. The solution can’t rely only on the
limited assumption.
And, actually, the PE are Provider Edge Router, we always locate them at the
non-backbone area in large network , that is close to the customer. There maybe
some small network that
hristian Hopps
Sent: Monday, January 24, 2022 1:50 PM
To: Gyan Mishra
Cc: Christian Hopps ; Aijun Wang ;
Hannes Gredler ; John E Drake ; Les
Ginsberg (ginsberg) ; Peter Psenak (ppsenak)
; Robert Raszuk ; Shraddha Hegde
; Tony Li ; lsr
Subject: Re: [Lsr] BGP vs PUA/PULSE
Ok, I guess I'll repe
Hi, Robert:
How about when the RR locates in one area(for example, backbone area), but the
PEs locates in the attached non-backbone area?
In such scenario, the RR can only receive the summary prefixes of PEs.
Aijun Wang
China Telecom
> On Jan 25, 2022, at 17:59, Robert Raszuk wrote:
>
>
>
Wang
China Telecom
-Original Message-
From: lsr-boun...@ietf.org On Behalf Of Tony Li
Sent: Tuesday, January 25, 2022 3:25 PM
To: Aijun Wang
Cc: Les Ginsberg (ginsberg) ; Gyan Mishra
; Peter Psenak ;
Christian Hopps ; Robert Raszuk ; lsr
Subject: Re: [Lsr] BGP vs PUA/PULSE
Hi Aijun,
1
Aijun,
[WAJ] X aims to how to withdraw the VPN prefixes with the mentioned
> extended communities, right?
>
Extended communities have nothing to do with this discussion at all.
> Y aims to how assist the RR get the prefix cost from one node that other
> than the RR itself. Right?
>
No.
> I
Hi, Robert:
Aijun Wang
China Telecom
> On Jan 25, 2022, at 17:36, Robert Raszuk wrote:
>
>
> Aijun,
>
>> On Tue, Jan 25, 2022 at 10:30 AM Aijun Wang
>> wrote:
>> Hi, Robert:
>>
>>
>>
>> So the main point here is that yes it is highly recommended to use summaries
>> across areas. But
Aijun,
On Tue, Jan 25, 2022 at 10:30 AM Aijun Wang
wrote:
> Hi, Robert:
>
>
>
> So the main point here is that yes it is highly recommended to use
> summaries across areas. But what's not clear (at least to me) is if we
> really need to signal node liveness in IGP to accomplish the ultimate
Hi, Robert:
So the main point here is that yes it is highly recommended to use summaries
across areas. But what's not clear (at least to me) is if we really need to
signal node liveness in IGP to accomplish the ultimate goal of few sec
connectivity restoration upon PE failure in the cases
>
> As we’ve been saying for months now, the ordering is:
>
> 1) Leak PE loopbacks
> 2) Pub/Sub
> 3) Carry loopbacks in BGP and recurse
> 4) Multi-hop BFD
> 5) Pulse
> 6) PUA
I would like to actually add to this list two alternatives which some
vendors have been shipping for decades:
X)
, 2022 3:25 PM
To: Aijun Wang
Cc: Les Ginsberg (ginsberg) ; Gyan Mishra
; Peter Psenak ;
Christian Hopps ; Robert Raszuk ; lsr
Subject: Re: [Lsr] BGP vs PUA/PULSE
Hi Aijun,
> 1) Consider in the BGP scenario: every PE may receive the routes from other
> PEs, right? So, using the PUB/SUB
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.
To: Peter Psenak
Cc: Christian Hopps ; 'John E Drake' ;
'Gyan Mishra' ; 'Robert Raszuk' ;
'Les Ginsberg (ginsberg)' ; 'Shraddha Hegde'
; Aijun Wang ; 'Tony Li'
; 'Hannes Gredler' ; lsr@ietf.org
Subject: Re: [Lsr] BGP vs PUA/PULSE
Peter Psenak writes:
> On 24/01/2022 16:19, Christian Hopps wrote:
hn E Drake ; Les
Ginsberg (ginsberg) ; Peter Psenak (ppsenak)
; Robert Raszuk ; Shraddha Hegde
; Tony Li ; lsr
Subject: Re: [Lsr] BGP vs PUA/PULSE
Ok, I guess I'll repeat what I said, as I don't believe anything new was
presented here.
Yes, having worked intimately with these IGPs for >
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
Mishra
Cc: Christian Hopps ; Aijun Wang ;
Hannes Gredler ; John E Drake ; Les
Ginsberg (ginsberg) ; Peter Psenak (ppsenak)
; Robert Raszuk ; Shraddha Hegde
; Tony Li ; lsr
Subject: Re: [Lsr] BGP vs PUA/PULSE
Ok, I guess I'll repeat what I said, as I don't believe anything new was
presented here.
22 1:50 PM
To: Gyan Mishra
Cc: Christian Hopps ; Aijun Wang ;
Hannes Gredler ; John E Drake ; Les
Ginsberg (ginsberg) ; Peter Psenak (ppsenak)
; Robert Raszuk ; Shraddha Hegde
; Tony Li ; lsr
Subject: Re: [Lsr] BGP vs PUA/PULSE
Ok, I guess I'll repeat what I said, as I don't believe an
iper.net> wrote:
>>>>>>
>>>>>> I don’t think so. Today things just work, at a given time
scale. What you said you are trying to do is reduce the time
scale for detecting that an application on a node has failed.
ation* for prefix P!
> >
> > Thanks,
> > Chris.
> > [As wg member]
> >
> > > Best Regards
> > >
> > > Aijun Wang
> > > China Telecom
> > >
> > > -Original Message-
> >
l Message-
> From: Christian Hopps
> Sent: Monday, January 24, 2022 1:50 PM
> To: Gyan Mishra
> Cc: Christian Hopps ; Aijun Wang <
wangai...@tsinghua.org.cn>;
> Hannes Gredler ; John E Drake <
jdr...@juniper.net>; Les
> Ginsberg (gins
; Chris.
> [As wg member]
>
> > Best Regards
> >
> > Aijun Wang
> > China Telecom
> >
> > -Original Message-
> > From: Christian Hopps
> > Sent: Monday, January 24, 2022 1:50 PM
> > To: Gyan Mishra
> > Cc: Christian Hopps ; Aij
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
PM
> To: Gyan Mishra
> Cc: Christian Hopps ; Aijun Wang <
> wangai...@tsinghua.org.cn>; Hannes Gredler ; John E
> Drake ; Les Ginsberg (ginsberg) ;
> Peter Psenak (ppsenak) ; Robert Raszuk <
> rob...@raszuk.net>; Shraddha Hegde ; Tony Li <
> tony...@tony.li>; lsr
>
Hopps' ; a...@cisco.com; 'John E Drake'
; 'Robert Raszuk' ; 'Les Ginsberg
(ginsberg)' ; 'Shraddha Hegde' ;
'Tony Li' ; 'Hannes Gredler' ; 'lsr'
; 'Peter Psenak (ppsenak)'
Subject: Re: [Lsr] BGP vs PUA/PULSE
[This is with my chair hat on; however, I am not making any actually calls on
rough
g (ginsberg) ; Peter
Psenak (ppsenak) ; Robert Raszuk ;
Shraddha Hegde ; Tony Li ; lsr
Subject: Re: [Lsr] BGP vs PUA/PULSE
Ok, I guess I'll repeat what I said, as I don't believe anything new was
presented here.
Yes, having worked intimately with these IGPs for > 20 years now,
trying to do is reduce the time
scale for detecting that an application on a node has failed.
However, conflating the health of a node with the health of an
application on that node seems to be inherently flawed.
>>>>>>
>>>>>&
, 2022, at 7:47 PM, John E Drake
> wrote:
> >>>>>>
> >>>>>> I don’t think so. Today things just work, at a given time scale.
> What you said you are trying to do is reduce the time scale for detecting
> that an application on a node has failed.
Hopps
Sent: Saturday, January 15, 2022 10:07 AM
To: Aijun Wang
Cc: John E Drake ; Robert Raszuk ; Les
Ginsberg (ginsberg) ; Christian Hopps ;
Shraddha Hegde ; Tony Li ; Hannes Gredler
; lsr ; Peter Psenak (ppsenak)
Subject: Re: [Lsr] BGP vs PUA/PULSE
Yes, having worked intimately with these IGPs f
; Hannes
Gredler ; lsr ; Peter Psenak (ppsenak)
Subject: Re: [Lsr] BGP vs PUA/PULSE
Yes, having worked intimately with these IGPs for > 20 years now, I understand
the use and the implications of using summary routes. :)
My opinion remains unchanged.
Thanks,
Chris.
[as wg member]
> On
gt;>>> I don’t think so. Today things just work, at a given time scale. What
>>>>>> you said you are trying to do is reduce the time scale for detecting
>>>>>> that an application on a node has failed. However, conflating the
>>>>>> hea
the health of a
>>>>> node with the health of an application on that node seems to be
>>>>> inherently flawed.
>>>>>
>>>>> Yours Irrespectively,
>>>>>
>>>>> John
>>>>>
>
t;>>> Yours Irrespectively,
>>>>
>>>> John
>>>>
>>>>
>>>> Juniper Business Use Only
>>>> From: Aijun Wang
>>>> Sent: Friday, January 14, 2022 7:40 PM
>>>> To: John E Drake
>>>>
gt;>
>>> Yours Irrespectively,
>>>
>>> John
>>>
>>>
>>> Juniper Business Use Only
>>> From: Aijun Wang
>>> Sent: Friday, January 14, 2022 7:40 PM
>>> To: John E Drake
>>> Cc: Les Ginsberg (ginsber
er Business Use Only
>> From: Aijun Wang
>> Sent: Friday, January 14, 2022 7:40 PM
>> To: John E Drake
>> Cc: Les Ginsberg (ginsberg) ; Robert Raszuk
>> ; Christian Hopps ; Shraddha Hegde
>> ; Tony Li ; Hannes Gredler
>> ; lsr ; Peter Psenak (p
gt;
> John
>
>
> Juniper Business Use Only
> From: Aijun Wang
> Sent: Friday, January 14, 2022 7:40 PM
> To: John E Drake
> Cc: Les Ginsberg (ginsberg) ; Robert Raszuk
> ; Christian Hopps ; Shraddha Hegde
> ; Tony Li ; Hannes Gredler
> ; lsr ; P
to:lsr@ietf.org>>; Peter Psenak (ppsenak)
mailto:ppse...@cisco.com>>
Subject: Re: [Lsr] BGP vs PUA/PULSE
[External Email. Be cautious of content]
Hi, John:
Please note if the node is down, the service will not be accessed.
We are discussing the “DOWN” notification, not the “UP” notification.
nes Gredler
> ; lsr ; Peter Psenak (ppsenak)
>
> Subject: Re: [Lsr] BGP vs PUA/PULSE
>
> [External Email. Be cautious of content]
>
> Hi, John:
> Please note if the node is down, the service will not be accessed.
> We are discussing the “DOWN” notification, not the “
Irrespectively,
John
Juniper Business Use Only
From: Aijun Wang
Sent: Friday, January 14, 2022 5:53 PM
To: John E Drake
Cc: Robert Raszuk ; Les Ginsberg (ginsberg)
; Christian Hopps ; Shraddha Hegde
; Tony Li ; Hannes Gredler
; lsr ; Peter Psenak (ppsenak)
Subject: Re: [Lsr] BGP vs PUA/PULSE
(ppsenak)
Subject: Re: [Lsr] BGP vs PUA/PULSE
[External Email. Be cautious of content]
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
Hi Les,
If someone (not necessarily you) wants to write up any of these proposals
> then we (the WG/Routing Area) could have a meaningful discussion about such
> alternatives.
>
Since you keep asking for a write up on an alternate solution(s) and since
you clearly stated that your connectivity
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
Wang ; Hannes Gredler
; lsr
Subject: Re: [Lsr] BGP vs PUA/PULSE
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
We – meaning the WG/IETF – are tasked with defining practical solutions
>>>> to real problems. It’s fine to object to a proposal – but that doesn’t get
>>>> us to a solution.
>>>>
>>>> I am not saying that you specifically are responsible for defin
need to
>>> accept an IGP solution or define an alternative.
>>>
>>>
>>>
>>> Now, if you are saying the problem doesn’t need to be solved – then we
>>> just disagree.
>>>
>>>
>>>
>>>Les
>>>
>>&
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
gt;> accept an IGP solution or define an alternative.
>>
>>
>>
>> Now, if you are saying the problem doesn’t need to be solved – then we
>> just disagree.
>>
>>
>>
>>Les
>>
>>
>>
>>
>>
>> *From:* To
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
>
>
>Les
>
>
>
>
>
> *From:* Tony Li *On Behalf Of *Tony Li
> *Sent:* Monday, January 10, 2022 4:43 PM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* Christian Hopps ; Peter Psenak (ppsenak) <
> ppse...@cisco.com>; Robert Raszuk ; Shraddha Hegde &l
, January 10, 2022 4:43 PM
To: Les Ginsberg (ginsberg)
Cc: Christian Hopps ; Peter Psenak (ppsenak)
; Robert Raszuk ; Shraddha Hegde
; Aijun Wang ; Hannes Gredler
; lsr
Subject: Re: [Lsr] BGP vs PUA/PULSE
Les,
And if customers could do what he suggested then they would not have an issue
sberg (ginsberg)
> *Sent:* Monday, January 10, 2022 4:34 PM
> *To:* Robert Raszuk
> *Cc:* Greg Mirsky ; Christian Hopps <
> cho...@chopps.org>; Aijun Wang ; Shraddha
> Hegde ; Tony Li ; Hannes Gredler <
> han...@gredler.at>; lsr ; Peter Psenak (ppsenak) &l
> 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
: Monday, January 10, 2022 4:34 PM
To: Robert Raszuk
Cc: Greg Mirsky ; Christian Hopps ;
Aijun Wang ; Shraddha Hegde ;
Tony Li ; Hannes Gredler ; lsr
; Peter Psenak (ppsenak)
Subject: Re: [Lsr] BGP vs PUA/PULSE
Robert –
The numbers are network-wide – not per node.
And no one has mentioned
t; *From:* Robert Raszuk
> *Sent:* Monday, January 10, 2022 4:30 PM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* Greg Mirsky ; Tony Li ;
> Christian Hopps ; Aijun Wang ;
> Shraddha Hegde ; Hannes Gredler ;
> lsr ; Peter Psenak (ppsenak)
> *Subject:* Re: [Lsr] BGP vs PUA/PULSE
>
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
; Tony Li ; Christian
Hopps ; Aijun Wang ; Shraddha
Hegde ; Hannes Gredler ; lsr
; Peter Psenak (ppsenak)
Subject: Re: [Lsr] BGP vs PUA/PULSE
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
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
om:* Robert Raszuk
> *Sent:* Monday, January 10, 2022 2:56 PM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* Tony Li ; Christian Hopps ;
> Peter Psenak (ppsenak) ; Shraddha Hegde <
> shrad...@juniper.net>; Aijun Wang ; Hannes
> Gredler ; lsr
> *Subject:* Re: [Lsr] BGP vs PU
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
, January 10, 2022 1:41 PM
To: Les Ginsberg (ginsberg)
Cc: Christian Hopps ; Peter Psenak (ppsenak)
; Robert Raszuk ; Shraddha Hegde
; Aijun Wang ; Hannes Gredler
; lsr
Subject: Re: [Lsr] BGP vs PUA/PULSE
Les,
We have received requests from real customers who both need to summarize
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
t;
>
> That’s what we are trying to do.
>
>
>
>Les
>
>
>
>
>
>
>
> *From:* Tony Li *On Behalf Of *Tony Li
> *Sent:* Monday, January 3, 2022 1:09 PM
> *To:* Christian Hopps
> *Cc:* Peter Psenak (ppsenak) ; Les Ginsberg (ginsberg)
> ; Robert Ra
> 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
are aiming for a modest number of
seconds.
Les
From: Greg Mirsky
Sent: Monday, January 10, 2022 1:30 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
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
e proposals that we
> think will be useful.
>
>
>
> That’s what we are trying to do.
>
>
>
>Les
>
>
>
>
>
>
>
> *From:* Tony Li *On Behalf Of *Tony Li
> *Sent:* Monday, January 3, 2022 1:09 PM
> *To:* Christian Hopps
> *Cc:* Peter Psenak (ppse
ailto:han...@gredler.at>>; lsr
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] BGP vs PUA/PULSE
On Jan 3, 2022, at 11:23 AM, Christian Hopps
mailto:cho...@chopps.org>> wrote:
And I'm saying if a prefix is important enough to merit a bunch of new protocol
extensions
DECRAENE Bruno INNOV/NET
> *Cc:* Aijun Wang ; Christian Hopps <
> cho...@chopps.org>; Greg Mirsky ; Hannes Gredler <
> han...@gredler.at>; Les Ginsberg (ginsberg) ; Peter
> Psenak ; Robert Raszuk ; Shraddha
> Hegde ; Tony Li ; lsr >
> *Subject:* Re: [Lsr] BGP vs PU
Robert,
On 06/01/2022 12:31, Robert Raszuk wrote:
Peter,
So far you and others have been saying all along that one of the
applications which uses PULSE can be BGP.
If so I am afraid this is not PIC (== Prefix _Independent _Convergence)
anymore. And I think this was Bruno's valid point.
Gredler ; lsr
; Peter Psenak
*Subject:* Re: [Lsr] BGP vs PUA/PULSE
Hi Robert
The goal of the draft is providing egress protection when summarization
is used similar to RFC 8679 Egress protection framework, but without the
complexities.
An IGP RIB within a domain is made up on connected interfa
ifically regarding the IGP leaf “IGP-IP1(BGP NH1)")
>
>
>
> Thanks,
>
> Regards,
>
> -Bruno
>
>
>
>
>
> Orange Restricted
>
> *From:* Lsr *On Behalf Of *Gyan Mishra
> *Sent:* Thursday, January 6, 2022 12:27 AM
> *To:* Robert Raszuk
To: "Peter Psenak (ppsenak)"
Cc: Hannes Gredler , Bruno Decraene
, Tony Li , Shraddha Hegde
, lsr
Subject: Re: [Lsr] BGP vs PUA/PULSE
Apologies ... want to correct myself for clarity:
was: "active and backup paths all going to the next hop X"
should be: "active paths al
Apologies ... want to correct myself for clarity:
was: "active and backup paths all going to the next hop X"
should be: "active paths all going to the next hop X and backup paths going
to different next hops"
On Thu, Jan 6, 2022 at 12:31 PM Robert Raszuk wrote:
> Peter,
>
> So far you and
Peter,
So far you and others have been saying all along that one of the
applications which uses PULSE can be BGP.
If so I am afraid this is not PIC (== Prefix *Independent *Convergence)
anymore. And I think this was Bruno's valid point.
Today BGP registers with RIB next hops for tracking, When
+--+
> >>>
> >>> Figure 2 Shared Hierarchical Forwarding Chain at iPE
> >>>
> >>> [1]
> >>> https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-bgp-pic-17#section-2.2
> >>> <https://datatracker.ietf.org/d
highlight/draw the
> > change(s) that you have in mind assuming IGP prefix summarization and
> > PULSE? (More specifically regarding the IGP leaf “IGP-IP1(BGP NH1)")
> >
> > Thanks,
> >
> > Regards,
> >
> > -Bruno
> >
> > Orange Restrict
Greg,
On 05/01/2022 18:39, Greg Mirsky wrote:
Hi Aijun,
thank you for pointing that out. I agree that in some deployment
scenarios, only a subset of PEs will be required to be monitored by an
ABR. But, as I look at the problem, the general use case should be the
worst case scenario, i.e.,
rsky ; Les Ginsberg (ginsberg)
; Christian Hopps ; Aijun Wang
; Shraddha Hegde ; Tony
Li ; Hannes Gredler ; lsr
; Peter Psenak
*Subject:* Re: [Lsr] BGP vs PUA/PULSE
Hi Robert
The goal of the draft is providing egress protection when summarization
is used similar to RFC 8679 Egress prot
enak
Subject: Re: [Lsr] BGP vs PUA/PULSE
Hi Robert
The goal of the draft is providing egress protection when summarization is used
similar to RFC 8679 Egress protection framework, but without the complexities.
An IGP RIB within a domain is made up on connected interfaces and loopbacks. Of
the
Hi Aijun,
thank you for posting the crucial questions. I think that we need to
consider a construct analogous to the Ethernet OAM's Maintenance
Association. We may refer to it, for now, as EVPN MA and it includes all
PEs that belong to a given EVPN. If that is the case, the news of a PE
being
Hi, Robert and Greg:
The reason that we select the IGP for advertising such “important bad news” is
that the potential receivers located in the same IGP as ABR. The nodes within
the IGP are all potential receiver for such news, then it is efficient to
advertise them via IGP.
Using other OAM
Gyan,
Everyone agrees that indicating down events is a good thing. Please observe
that the discussion is about how to do it, not if to do it.
There is nothing similar in mechanics of local protection (RFC8679) and
ingress protection (this discussion). Just like local repair works very
Hi Robert
The goal of the draft is providing egress protection when summarization is
used similar to RFC 8679 Egress protection framework, but without the
complexities.
An IGP RIB within a domain is made up on connected interfaces and
loopbacks. Of the two types, the critical prefix to be
Hi Aijun,
thank you for pointing that out. I agree that in some deployment scenarios,
only a subset of PEs will be required to be monitored by an ABR. But, as I
look at the problem, the general use case should be the worst case
scenario, i.e., all PEs in the area being monitored.
Just to be
> same happens without a pulse today without a summarization
We have established that this discussion is about this scenario:
" it's applicable in cases where summarization is used."
and in such cases under some scenarios PULSES can actually make things
worse.
The goal is (or should be) not to
Robert,
On 05/01/2022 12:57, Robert Raszuk wrote:
if the router supports NSR or NSF such event will be invisible to other
routers, including ABR. Without these mechanisms the neighboring
routers
would tear down the adjacency anyway.
So are you going to add to the draft special
>
> if the router supports NSR or NSF such event will be invisible to other
> routers, including ABR. Without these mechanisms the neighboring routers
> would tear down the adjacency anyway.
>
So are you going to add to the draft special handling in this case ?
There is difference between losing
1 - 100 of 218 matches
Mail list logo
