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
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
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,
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
an impression that only some of
them are important. That includes all PEs or PEs & Segment endpoints.
Thx,
R.
On Mon, Jan 24, 2022 at 11:31 AM Christian Hopps wrote:
>
> Robert Raszuk writes:
>
> > Chris,
> >
> > I would like to state one important point ..
; 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
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
>
dd a useful model
> to the proposed mechanism.
>
> Regards,
> Greg
>
> On Sun, Jan 23, 2022 at 2:09 PM Robert Raszuk wrote:
>
>> Gyan,
>>
>> By design of the proposal there is no synchronization of "state" between
>> ABRs needed. In fact the
Gyan,
By design of the proposal there is no synchronization of "state" between
ABRs needed. In fact the main benefit is that ABRs will be receiving and
storing a completely different set of registrations and notifications for
scalability of the overall system.
What you wrote in the second
Sounds good.
Thx,
R.
On Thu, Jan 20, 2022 at 6:23 PM Tony Li wrote:
>
> Hi Robert,
>
> While perhaps pretty obvious, it would be good to also highlight what
> implementation should do in the event of covering prefix changes in the
> LSDB if those are to happen after registrations have already
Hi Tony,
> You mean to show up in registration ? I guess there could be a triggering
> threshold with some wisely chosen % of the min. number of host routes in
> the summaries to avoid too much noise.
>
> That seems like a difficult condition to explain. How do you feel about
> just always
20, 2022 at 4:01 PM Acee Lindem (acee) wrote:
> Hi Robert,
>
>
>
>
>
> *From: *Lsr on behalf of Robert Raszuk <
> rob...@raszuk.net>
> *Date: *Thursday, January 20, 2022 at 4:59 AM
> *To: *Aijun Wang
> *Cc: *lsr , Tony Li
> *Subject: *Re: [Lsr] New Ver
>
> [WAJ] The exact description should be “It proposes to use IGP establishing
> the out of band channel to deliver the PUB/SUB information”
>
Sorry - no. You seem to be locking IGPs to flooding based transport only.
Anything else you call "out of band" - I do not subscribe to this.
Many thx,
Aijun,
> You are proposing to use the Out of Band channel to solve the IGP problem.
I am not sure if you noticed but Tony's proposal is an IGP extension not
out of band channel.
> all the registered clients will also receive the massive notification
> information unless you do some filter
Hi Tony,
Ok, this was the intent already. The current text says:
>
>If an ABR receives a Registration Message for a prefix that is being
>injected by a non-attached area, then it should determine the set of
>ABRs that are advertising that prefix or less specifics and register
>
Hi Tony,
> Do you envision any form of aggregation to happen in the messaging
> between ABRs (for both registrations and notifications) ?
>
> Well, as always, I try to generalize mechanisms and solutions. So while I
> don’t see an immediate need or benefit to it, I did write the protocol so
>
Tony P,
> though this leads to chicken-egg since kafka needs routing to strip
e'thing together
I am not sure I follow the above parenthesis ... Routing will be there
already as we are not talking about any reachability distribution hence I
am not sure where is the chicken-egg dilemma ?
Would
Linda,
But the point is that you can only have a single topology for a prefix - so
why not to do it in base ?
Thx
On Wed, Jan 19, 2022 at 5:28 PM Linda Dunbar
wrote:
> Robert,
>
>
>
> Replies inserted below:
>
>
>
>
>
> *From:* Robert Raszuk
> *Sent:*
ternal)
to your anycast prefixes.
Thx,
R.
On Wed, Jan 19, 2022 at 4:59 PM Linda Dunbar
wrote:
> Robert,
>
>
>
> Reply to your comments are inserted below:
>
>
>
> *From:* Robert Raszuk
> *Sent:* Wednesday, January 19, 2022 4:18 AM
> *To:* Linda Dunbar
he traffic to this address will be
> distributed equally among the three locations. No traffic oscillation will
> occur.
>
> The key point here is that the attributes associated with these stub
> links/prefixes should be considered or emphasized.
>
> Aijun Wang
> China Telec
Hi Tony,
*Question: *
Do you envision any form of aggregation to happen in the messaging between
ABRs (for both registrations and notifications) ?
*Comment: *
I think the pub-sub model is really cool, but I am not clear what are the
advantages to do it in the IGP from ABRs vs BGP from area RRs
hours..”*
>
>
>
> Your comments and suggestions are greatly appreciated.
>
>
>
> Linda
>
>
>
> *From:* Robert Raszuk
> *Sent:* Monday, January 17, 2022 5:29 AM
> *To:* Aijun Wang
> *Cc:* Acee Lindem (acee) ; Linda Dunbar <
> linda.dun...@futurewei.co
Aijun,
Such metric will be same(because of the ANYCAST address be advertised
> simultaneously via R1/R2/R3 at the same time for one application server,
> for example, S1/aa08::4450).
>
That is not really correct.
On each router R1 or R2 or R3 when you for example redistribute or
originate in
> For the current scenarios and solutions, we have analyzed that RFC 5316
> and RFC5392 are not suitable for such purposes—we must generate bogus AS,
> bogus Remote ASBR Router ID on every inter-AS, or non inter-AS boundary
> links.
>
Why do you think those values need to be "bogus" ? And
Hi Aijun,
> If not, I would say both you and Les’s understanding of this draft is not
> correct.
>
If two (or more) subject matter experts like Les & John can not understand
the IGP draft I would not draw an immediate conclusion that this is their
perception fault.
Instead I would take a step
.
On Fri, Jan 14, 2022 at 4:53 AM Gyan Mishra wrote:
> Robert
>
> Responses in-line
>
>
>
> On Thu, Jan 13, 2022 at 5:55 AM Robert Raszuk wrote:
>
>> Gyan,
>>
>> I see what the draft is trying to do now. /* I did not even consider this
>> for the rea
doesn’t cause spurious rerouting.
>
>
>
> Seems to me you are asking Linda this question in one of your other posts.
>
>
>
> My agreement on the use of the IGP assumes that the entity calculating the
> metric to be provided to the IGP has the correct intelligence.
>
>
>
t; Egress routers can be assigned with a site preference index for a specific
> set of prefixes attached.
>
>
>
> Linda
>
>
>
> *From:* Robert Raszuk
> *Sent:* Thursday, January 13, 2022 11:27 AM
> *To:* Linda Dunbar
> *Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra
hu, Jan 13, 2022 at 6:18 PM Linda Dunbar
wrote:
> Robert,
>
>
>
> The draft is about distributing the Site Index and preferences of the
> Egress routers to which the application load balancers (or instances) are
> attached.
>
>
>
> Thanks, Linda
>
>
>
> *Fro
t a high rate.
>
> Can you put some language in the draft that indicates the expected rate of
> updates to the metric and some guidelines on limiting the frequency?
>
>
>
> Thanx.
>
>
>
>Les
>
>
>
>
>
> *From:* Linda Dunbar
> *Sent:* Th
a cluster of micro-service instances
>are rarely dynamically changed. Most of those values are configured.
>Therefore, the oscillation is minimal.
>- Flows among micro-services are very short. Put less requirements to
>flow affinity.
>-
>
>
>
> Linda
>
>
And one more question - apologies if it was already discussed and I missed
it.
How will the PE / edge router receive information describing current (for
example) load of the compute or LB sitting behind the switch on one of the
VLANs ?
Many thx,
R.
On Thu, Jan 13, 2022 at 4:08 PM Robert Raszuk
into this
new amount of (stub) link information.
Kind regards,
R.
On Thu, Jan 13, 2022 at 4:03 PM Aijun Wang
wrote:
> Hi, Robert:
>
> Aijun Wang
> China Telecom
>
> On Jan 13, 2022, at 22:29, Robert Raszuk wrote:
>
>
>
>
>> [WAJ] VLAN interface is the logical
> [WAJ] VLAN interface is the logical interfaces that connected to servers
> that are out side of the IGP domain. It is also different from the inter-AS
> link that described in RFC5316 and RFC5392.
> Some information that related to the attached severs or some policy to
> these server can be
his. RFC9086 requires every border router
> run BGP-LS.
> But normally, we need only one router within IGP run BGP-LS.
>
> I think Tony has gotten one of key use use case for this draft. The
> difference between us is how to accomplish it.
>
> Aijun Wang
> China Telecom
>
>
And just to provide a sound alternative to the objective of this work.
Please consider using Traefik - https://traefik.io/
Thx,
R.
On Thu, Jan 13, 2022 at 11:56 AM Robert Raszuk wrote:
> Gyan,
>
> I see what the draft is trying to do now. /* I did not even consider this
> fo
;>
>>
>>
>> The difference between ECMP and UCMP is not significant in this
>> discussion.
>>
>> I don’t want to speak for Robert, but for me his point was that IGPs can
>> do “multipath” well – but this does not translate into managing flows.
>>
&
rg/doc/html/draft-mohanty-bess-ebgp-dmz
>
>
>
> There are many use cases in routing for unequal cost load balancing
> capabilities.
>
> Kind Regards
>
> Gyan
>
> On Wed, Jan 12, 2022 at 2:23 PM Robert Raszuk wrote:
>
>> Linda,
>>
>> > IGP has bee
Hi Tony,
If you originate BGP-LS on the PE of interest it seems you can stuff it
with whatever you like. I read RFC9086 as one example of it.
Thx,
R.
On Thu, Jan 13, 2022 at 3:05 AM Tony Li wrote:
>
> Robert,
>
> On Jan 12, 2022, at 5:06 PM, Robert Raszuk wrote:
>
>
Tony Li wrote:
>
>
> On Jan 12, 2022, at 4:01 PM, Robert Raszuk wrote:
>
> Very honestly I must have missed that the objective here is to include
> those links in the TE constrained computation. You mean MPLS RSVP-TE ?
>
> Is that so in 2022 ?
>
>
>
> Robert,
>
Hi Tony,
Very honestly I must have missed that the objective here is to include
those links in the TE constrained computation. You mean MPLS RSVP-TE ?
Is that so in 2022 ?
Kind regards,
R.
On Thu, Jan 13, 2022 at 12:58 AM Tony Li wrote:
>
>
> On Jan 12, 2022, at 3:54 PM, Robert Rasz
Aijun,
[WAJ] If the proposed stub link follow the same rule as the existing link,
> we can adding the new sub-TLV to achieve the goal.
>
What puzzles me in this proposal is why are you insisting on making a stub
link not-so-stubby instead of treating it as a passive interface (as others
already
omputation.
>
> Using MPLS is too heavy.
>
>
>
> Linda
>
>
>
> *From:* Robert Raszuk
> *Sent:* Wednesday, January 12, 2022 1:23 PM
> *To:* Linda Dunbar
> *Cc:* Les Ginsberg (ginsberg) ; lsr@ietf.org
> *Subject:* Re: [Lsr] Seeking feedback to the revised
&g
ead has always been
done at the application layer *for example MPLS*
Thx a lot,
R.
On Wed, Jan 12, 2022 at 8:18 PM Linda Dunbar
wrote:
> Robert,
>
>
>
> Please see inline in green:
>
>
>
> *From:* Robert Raszuk
> *Sent:* Wednesday, January 12, 2022 1:00 PM
> *To:
Hi Linda,
*[LES:] It is my opinion that what you propose will not achieve your goals
> – in part because IGPs only influence forwarding on a per packet basis –
> not a per flow/connection basis.*
>
> *[Linda] Most vendors do support flow based ECMP, with Shortest Path
> computed by attributes
;
>
> What is being debated here is the issue of whether 5G application load
> should be used by IGPs for route computation.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr on behalf of Robert Raszuk <
> rob...@raszuk.net>
> *Date: *Wednesday, J
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
Ginsberg (ginsberg)
wrote:
> 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
>
>
>
>
>
&g
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
hop is open or has crabs.
That info you need to get over the top as a service. So I am much more in
favor to make the service to tell you directly or indirectly that it is
available.
Best,
R.
On Tue, Jan 11, 2022 at 1:07 AM Les Ginsberg (ginsberg)
wrote:
> Robert -
>
>
>
> *Fr
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
> 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
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
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 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
ith
> BFD, LFA/RLFA/TILFA local protection , PIC and other optimizations we still
> need an optimization to track the summary route component prefixes to speed
> up convergence providing egress PE protection.
>
> Kind Regards
>
> Gyan
>
> On Tue, Jan 4, 2022 at 6:55 PM
n the draft how to
use it instead of leaving lots of challenges and interpretations to
potential users/apps of this new extension.
Many thx,
R.
On Wed, Jan 5, 2022 at 1:16 PM Peter Psenak wrote:
> Robert,
>
> On 05/01/2022 12:57, Robert Raszuk wrote:
> > if the router supports NS
>
> 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
t 12:22 PM Robert Raszuk wrote:
> Peter,
>
> Two other points ..
>
> #1 - Imagine PE
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Peter,
Two other points ..
#1 - Imagine PE
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Hi Aijun,
In most deployments summary routes are already crafted carefully to only
cover those destinations which are important and should be reachable from
outside of the area.
So I see no point in building yet another policy to select a subset of
summaries to be PUA eligible.
Along those
>
> no. It's a limit not a delay.
That is directly contradicting the message from Les stating that this is
going to be a rate limit not cut out.
*"[LES2:] It is reasonable to limit the rate of pulses sent. "*
If too many edge nodes loose connectivity
> to the ABR in its area, it's a result of
Peter,
> > Take SR-MPLS and RFC8667.
>
> for MPLS summarization is practically not possible, we have been through
> that.
>
The point is that the proposed solution is applicable to only a subset of
real practical deployments even if everyone would agree that this is a cool
idea.
> > Take
Hi Peter,
Take SR-MPLS and RFC8667.
Take RFC7810
Take RFC5120
literally anything which uses inter-area leaking today.
Thx,
R.
On Mon, Jan 3, 2022 at 6:18 PM Peter Psenak wrote:
> Robert,
>
> On 03/01/2022 18:04, Robert Raszuk wrote:
> > Peter,
> >
> > > We
Peter,
> We want network to be summarized all times
Please - can you answer my question which was already stated at least twice
?
How can you summarize PE addresses if outside of reachability they
advertise and leak across areas lots of other important information in an
opaque to the IGP
Hey Les,
I think you are making a very valid point. Especially important in
the context of link state protocols.
To illustrate perhaps even better your point, let's assume there is a
customer who is not a single vendor one. So assume he is using vendor J
with reflection and vendor's A with
Well WFIW IDR solved this dilemma by mandating at least two documented
implementations before proceeding with any proposal to IESG (irrespective
of the RFC document type).
After all nothing stops anyone from implementing an idea described in the
WG document using if needed early code point
>
> we are going to use the same "rumour" that is used today when the /32 is
> lost on ABR in the source area. The only difference is that instead of
> stopping the advertisement of the previously advertised /32, we generate
> a pulse and keep advertising the summary.
>
That is not the only
1 at 8:13 PM Les Ginsberg (ginsberg)
> > mailto:ginsb...@cisco.com>> wrote:
> >
> > Tony –
> >
> > __ __
> >
> > Inline.
> >
> > __ __
> >
> > *From:* Tony Przygienda > <mailto:tonysi
Peter,
> Pulse does not replace the overlay protocols functionality. They are the
> ultimate source of the trust.
The entire point of PULSE is to speed up the process of service and
connectivity restoration. You can't just back off from it now and say that
it is all up to overlay to
Hey Peter,
> I don't understand what "service stops" you are talking about. Pulse
> will never stop any service. It will at most trigger the switch to
> alternate service source. If there is none available, nothing will happen.
>
Oh really ? Is that so ? That's not what you have been saying
as the reasons for such scenarios is just tip
of the iceberg in pile of reasons why ABR may think PEs went down. There
are many more...
Kind regards,
Robert
On Thu, Dec 2, 2021 at 12:58 AM Aijun Wang
wrote:
> Hi, Robert:
>
> Aijun Wang
> China Telecom
>
> On Dec 2, 2021
ll sources of the summaries inject identical PULSE.
That makes the feature a bit more complex
Thx,
R.
On Wed, Dec 1, 2021 at 9:25 PM Robert Raszuk wrote:
> Hi Tony,
>
> I have been thinking about your email a bit more. Actually the destructive
> issue you have described can happe
, 2021 at 5:04 PM Robert Raszuk wrote:
> Hi Tony,
>
> On #2 I you are right in the case of src L1 getting partitioned. Yes it
> will kill anycast design. If this is showstopper ... not sure. AFAIK only
> sourcing ABRs need to keep track about all links to PE to be down. That
>
whiteboard and do some innovations
to make sure feature is useful and harmless ?
Best,
R.
On Wed, Dec 1, 2021 at 8:18 PM Les Ginsberg (ginsberg)
wrote:
> Robert –
>
>
>
> One last time…inline.
>
>
>
> *From:* Robert Raszuk
> *Sent:* Wednesday, December 1, 2021
t;
> If they have enabled it my comment regarding partition still applies.
>
>
>
> Thanx.
>
>
>
>Les
>
>
>
>
>
> *From:* Robert Raszuk
> *Sent:* Wednesday, December 1, 2021 9:02 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* Tony Przygienda ;
isable protocol operation entirely on those links. So again
> I do not see that any special consideration of max-metric is needed.
>
>
>
> Les
>
>
>
>
>
> *From:* Robert Raszuk
> *Sent:* Wednesday, December 1, 2021 7:36 AM
> *To:* Peter Psenak (ppsenak
Hi Les,
*so one could argue that switching BGP traffic to the backup path is still
> a good idea.*
>
Well you are making a huge assumption that there is a backup path via a
given domain.
In modern networks true backup is build from CE POV and happens via
another domain or via another service.
The new Pulse LSPs don't have remaining lifetime - quite
>> intentionally.
>> > They are only retained long enough to support flooding.
>> >
>> > But, you remind me that we need to specify how the checksum is
>> > calculated. Will do that
Peter and Les,
Do you plan to have a provision to suspend PULSE generation for the planned
maintenance windows where service reachability was removed before PE went
down ?
What was the conclusion in respect to MAX AGE and OL bits ?
Thx,
R.
___
Lsr
>
> and it brings up the issue of having anycast for e.g. load-balancing or
> reliability and one pulse basically tearing the session for another
> destination.
>
I don't think so. The PULSE can be sent *only* when every router in an area
removed all links going to a dead PE. Not when ABR noticed
ction-4.1
>>
>> The new Pulse LSPs don't have remaining lifetime - quite intentionally.
>> They are only retained long enough to support flooding.
>>
>> But, you remind me that we need to specify how the checksum is
>> calculated. Will do that in the next revisio
Hi Greg,
GIM2>> Now we have to reconcile states reported by RRs.
>
Not really. That "reconciliation" is native and automatic. No need to do
anything. If you are hearing updates from two RRs you only consider it DOWN
when both RRs withdraw the very path. Otherwise it is all UP.
#3 - If my
Hi,
The current PUA/PULSE discussion is aiming for letting the ingress PEs know
about egress PE failures. Alternatives to IGP domian wide flooding has been
discussed on other threads.
But I would like to bring to your attention a different point.
Imagine I am an ingress PE and have N paths for
> > Can't you run OSPF over GRE ? For ISIS Henk had proposal not so long ago
> > to run it over TCP too.
> >
> https://datatracker.ietf.org/doc/html/draft-hsmit-lsr-isis-flooding-over-tcp-00
>
> you can run anything over GRE, including IGPs, and you don't need TCP
> transport for that. I don't see
Hey Peter,
> #1 - I am not ok with the ephemeral nature of the advertisements. (I
> > proposed an alternative).
>
> LSPs have their age today. One can generate LSP with the lifetime of 1
> min. Protocol already allows that.
That's a pretty clever comparison indeed. I had a feeling it will come
Les,
*I was just trying to illustrate that prefixes covered by the summary could
> be advertised using existing IGP advertisements even when the summary is
> being advertised. **It is still reachability. The determination of when
> to advertise the prefix and when not to is still based upon
t Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> *From:* Greg Mirsky
>> *Sent:* Tuesday, November 30, 2021 11:11 AM
>> *To:* Aijun Wang
>> *Cc:* lsr ; Gyan Mishra ; Robert
>> Raszuk
>> *Subject
Hi Greg,
If BFD would have autodiscovery built in, that would indeed be the ultimate
>> solution. Of course folks will worry about scaling and number of BFD
>> sessions to be run PE-PE.
>>
> GIM>> I sense that it is not "BFD autodiscovery" but an advertisement of
> BFD multi-hop system readiness
Hi Greg,
/* Changing the subject as the other thread just tried to re-focus on IGP
*/
/* Keeping lsr WG cc-ed just as FYI */
>From my OAM PoV, the most reliable option is, as you've pointed out, to run
> BFD over EVPN underlay between PEs.
>
If BFD would have autodiscovery built in, that would
Hi Tony,
> It is OK for IGPs to advertise multiple summaries (e.g., multiple /24s
> instead of a single /16).
> It is even OK for IGPs to advertise some prefixes covered by a summary
> along with the summary (don’t know if any implementations do this - but
> they could).
> None of this is an
rom:* Lsr *On Behalf Of * Robert Raszuk
> *Sent:* Monday, November 29, 2021 2:54 PM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* Aijun Wang ; Shraddha Hegde <
> shrad...@juniper.net>; Tony Li ; Hannes Gredler <
> han...@gredler.at>; lsr ; Peter Psenak (ppsenak) <
> ppse
s/ 1 days ago you said/ 11 days ago you said/
Apologies,
R.
On Mon, Nov 29, 2021 at 11:53 PM Robert Raszuk wrote:
> Hi Les,
>
> Just to summarize my personal take on this thread in the light of your
> last email.
>
> #1 - I am not ok with the ephemeral nature of the
Hi Les,
Just to summarize my personal take on this thread in the light of your last
email.
#1 - I am not ok with the ephemeral nature of the advertisements. (I
proposed an alternative).
#2 - I am not ok with spreading the information everywhere including all P
and PE routers which do not need
Hi Acee,
> Robert believes that this is a problem that needs to be solved but that
it could be better
> solved using BGP as described in
draft-raszuk-idr-yet-another-complex-idr-draft-00.txt.
>
> Correct me if I'm wrong...
Indeed you are not correct.
The draft name (if at needed to have a draft
Hey Peter,
> think of it as LSP with the lifetime of 60 sec. Nothing magical about it.
>
That 60 sec is not long enough.
If folks do not want to quickly detect the failure by iBGP by running BFD
def iBGP holdtime is 180 sec ! So right there if you timeout PULSE after 60
sec the broken best
> So the IGP would provide reachability between the PE and RR loopbacks and
> so the IGP would have to be converged for BGP TCP session to establish.
>
> Am I missing something?
>
Yes. Entire concept of PUA/PULSE is about detecting transition to "DOWN"
state of the PE.
So talking about IGP
> > All P routers (except very few exceptions) run the very same software
> > as PEs. So it can easily build a session to RR to learn the routes.
>
> [WAJ] if we agree all P routers and PE routers expect to receive such
information,
Not all but only those adjacent to PEs under such protection
Hi Aijun,
>
> Yes BGP option 2 as I described gives you PIC effect. In fact I am quite
> convinced that if done right it can be much faster then IGP flooding
> especially at scale. Please recall all safety belts build into IGP to slow
> down churn when multiple events happens in a time scale.
egards
>
>
>
> Zhibo
>
>
>
> *发件人:* Lsr [mailto:lsr-boun...@ietf.org] *代表 *Robert Raszuk
> *发送时间:* 2021年11月26日 17:00
> *收件人:* Huzhibo
> *抄送:* Les Ginsberg (ginsberg) ; Gyan Mishra <
> hayabusa...@gmail.com>; Acee Lindem (acee) ; Christian
> Hopps
201 - 300 of 557 matches
Mail list logo
