links
> > would expose.
> >
> > That's the real life scenario which I am trying to map to UPA (or in
> > fact also DROID) mechanism.
> >
> > Many thx,
> > Robert
> >
> >
> > On Thu, Jul 7, 2022 at 2:03 PM Peter Psenak > <mailto:pp
.
That's the real life scenario which I am trying to map to UPA (or in fact
also DROID) mechanism.
Many thx,
Robert
On Thu, Jul 7, 2022 at 2:03 PM Peter Psenak wrote:
> On 07/07/2022 12:26, Robert Raszuk wrote:
> > That's true.
> >
> > I am pointing out that this in some networ
; BGP PIC depends on the IGP convergence. We are not changing any of that
> by UPA.
>
> thanks,
> Peter
>
>
> On 07/07/2022 12:02, Robert Raszuk wrote:
> > Peter,
> >
> > All I am saying is that this may be pretty slow if even directly
> > attached P rou
for all P
routers to tell you that PE in fact went down. While in case of
invalidating service routes the first trigger is good enough.
To me this is significant architectural difference.
Many thx,
R.
On Thu, Jul 7, 2022 at 11:54 AM Peter Psenak wrote:
> On 07/07/2022 11:38, Robert Raszuk wr
PE.
On Thu, Jul 7, 2022 at 11:35 AM Peter Psenak wrote:
> Robert,
>
> On 07/07/2022 11:25, Robert Raszuk wrote:
> > Hi Peter,
> >
> > > Section 4:
> > >
> > > "The intent of UPA is to provide an event driven signal of the
> >
rom different carriers and may have for
stability varying BFD timers. So here you would have to wait for the
slowest link to be detected on the neighbouring P router as down.
Thx,
R.
On Thu, Jul 7, 2022 at 10:16 AM Peter Psenak wrote:
> Robert,
>
> On 06/07/2022 15:07, Robert Raszuk w
Hi Peter,
Can you please point me in the draft
https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt
to some section which specifies based on exactly what network flooding
changes UPA will be generated by ABRs ?
I think such text is not an implementation detail, but it is
ert,
>
>
> On Jun 30, 2022, at 6:56 PM, Robert Raszuk wrote:
>
> Isn't the YANG section a requirement for all protocol extension
> documents before they are sent for publications these days ?
>
>
> We're not yet to the point where extensions to YANG modules are part
Hello,
I have a question ... likely to the WG chairs.
Why
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-flood-reflection-07
does not have a YANG section ? Is there a separate document for it just
like we see a separate document for BGP-LS encoding ?
Isn't the YANG section a
UPAs may not even contain the advertised locator in SIDs. That is not
clearly spelled out what exactly ABRs should advertise.
I presume:
a) something which was flooded in the local domain and was not being leaked
AND
b) something which stopped to be flooded in a local domain
AND
c) there is local
Bruno,
Actually I like your flag suggestion for an additional and different
reason.
If someone does not need to flood UPAs in any remote area it is trivial to
filter those on the ABRs connecting those areas to the core. Otherwise such
filtering could be more difficult if at all possible.
Thx,
Gunter,
(1) Multiple-ABRs
>
>
>
> I was wondering for example if a ingress router receives a PUA signaling
> that a given locator becomes unreachable, does that actually really signals
> that the SID ‘really’ is unreachable for a router?
>
Aas there is no association between node_id (perhaps
Hi Gyan,
While I agree with your final conclusion and description there is one
important detail missing.
PODs consist of both network elements and compute nodes. Virtualization
happens in the latter. Dynamic routing between those almost in all
cases talk BGP in the underlay not IGP simply as
>
> looks to me that you are trying to steer the discussion towards the BGP
> based solution. Not something I'm interested on this thread.
>
Not at all. It was you not me who used argument that UPA/PUA is useful for
networks with no BGP ... example:
Quote:
*"I have explained that several
> Traffic will initially switch to alternate path, if any, an
> later the native mechanism (BGP signalling, tunnel keepalive, etc), will
> take over and bring it to its final state.
>
On one hand you are saying that UPA is useful where there is no BGP. So
let's talk about such a scenario.
Also
:
> Robert,
>
> On 15/06/2022 14:13, Robert Raszuk wrote:
> > Peter,
> >
> > the meaning of LSInfinity has been defined decades ago. No matter how
> >
> > much you may not like it, but it means unreachable.
> >
> >
> > True. But th
Peter,
the meaning of LSInfinity has been defined decades ago. No matter how
>
much you may not like it, but it means unreachable.
True. But that brings another question ... Do you envision to use UPA also
to indicate planned maintenance of a node ?
Thx,
R.
> Well, we can blame marketing all we want. All I know is that we, as a
> group, failed to come together and present a unified front with
> interoperable implementations. That left us in a position where marketing
> is pushing rocks up hills and customers are waiting for the dust to settle.
I
Hi Tony,
> So, can we PLEASE stop beating a dead horse?
Are you stating that computing dynamic flooding topologies has no use case
outside of MSDCs or for that matter ANY-DCs ?
Thx,
R.
PS. It is true that folks even running 10 racks think BGP is the only
choice for the underlay but to me this
ped the discussion to summaries.
I realize PUE also wants to cover P failures so in this case each P is
also equally important.
Thx,
R,
On Tue, Jun 14, 2022 at 3:57 PM Acee Lindem (acee) wrote:
> Speaking as WG member:
>
>
>
> *From: *Lsr on behalf of Robert Raszuk <
> rob...@raszu
All,
> What is wrong with simply not doing summaries
What's wrong is that you are reaching the scaling issue much sooner than
when you inject summaries.
Note that the number of those host routes is flooded irrespective of the
actual need everywhere based on the sick assumption that perhaps they
Hello Gunter,
I agree with pretty much all you said except the conclusion - do nothing
:).
To me if you need to accelerate connectivity restoration upon an unlikely
event like a complete PE failure the right vehicle to signal this is
within the service layer itself. Let's keep in mind that links
e experience with “fallback”. It is complex
> to implement – especially in the forwarding plane – and would not be my
> first choice as a solution.
>
>
>
> ??
>
>
>
> Les
>
>
>
>
>
> *From:* Lsr *On Behalf Of * Robert Raszuk
> *Sent:* Tuesday, M
at deployment model IMO should get
attention and be addressed in base flex-algo specs.
Cheers,
Robert
On Wed, May 18, 2022 at 11:46 AM Peter Psenak wrote:
> Robert,
>
> On 18/05/2022 10:53, Robert Raszuk wrote:
> > Peter,
> >
> > It is not about someone thinking if this
Missed it - sorry:
s/ control plane CPUs and data plane FIBs / control plane CPUs and data
plane FIBs with LFA or R-LFA enabled per topo/
On Wed, May 18, 2022 at 10:53 AM Robert Raszuk wrote:
> Peter,
>
> It is not about someone thinking if this is a good idea or not. It is
> abo
gt; Peter
>
>
>
> On 17/05/2022 19:58, Robert Raszuk wrote:
> > Hi Peter,
> >
> > Enabling local protection on all nodes in all topologies may also not be
> > the best thing to do (for various reasons).
> >
> > While I agree that general fallback may be
> Robert,
>
> On 17/05/2022 14:14, Robert Raszuk wrote:
> > Ok cool - thx Peter !
> >
> > More general question - for any FlexAlgo model (incl. SR):
> >
> > Is fallback between topologies - say during failure of primary one -
> > only allowed on the ingress t
Peter Psenak wrote:
> Hi Robert,
>
>
> On 17/05/2022 12:11, Robert Raszuk wrote:
> >
> > Actually I would like to further clarify if workaround 1 is even doable
> ...
> >
> > It seems to me that the IP flexalgo paradigm does not have a way for
> > mor
, 2022 at 12:01 PM Robert Raszuk wrote:
> Folks,
>
> A bit related to Aijun's point but I have question to the text from the
> draft he quoted:
>
>In cases where a prefix advertisement is received in both a IPv4
>Prefix Reachability TLV and an IPv4 Algorithm Prefix
Folks,
A bit related to Aijun's point but I have question to the text from the
draft he quoted:
In cases where a prefix advertisement is received in both a IPv4
Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability
TLV, the IPv4 Prefix Reachability advertisement MUST be
Hi John,
In the IETF context I have always associated ‘data plane’ with packet
> forwarding,
>
No one disputes that.
But the fact that various sub-data-planes are built on top of base physical
data planes needs to be clearly distinguished.
Kind regards,
R.
Hi Robert,
>
> On 14/04/2022 11:21, Robert Raszuk wrote:
> > Hi Peter,
> >
> > Term "data-plane" usually means physical resources links, switch fabric,
> > ASIC etc ... so I am afraid it will also generate confusion with default
> > data plane.
> >
&
Hi Peter,
Term "data-plane" usually means physical resources links, switch fabric,
ASIC etc ... so I am afraid it will also generate confusion with default
data plane.
How about two alternatives:
- custom/logical topology
- logical-data-plane
Thx,
Robert.
On Thu, Apr 14, 2022 at 9:27 AM
Hi Ketan,
> KT2> I see the primary use case for IP FlexAlgo (or another data plane)
> > to be that the data plane is used by itself. In the (rare?) case where
> > multiple data planes are required to coexist, it is simpler both from
> > implementation and deployment POV to use different algos. It
Hi Tony,
Just two follow up points,
#1 - I can't stop the feeling that DROID is very IGP centric and not
generic enough. Do you think we need DROID-2 to start offloading BGP or at
least stop trashing it ? Or you think that DROID as proposed could take on
day one flowspec v2 with its various
Hi Tony,
Very happy to see this draft.
First question - the draft seems to be focusing on hierarchical IGPs and is
clearly driven by liveness propagation discussion.
But the motivation of offloading non routing information from IGPs (and/or
BGP) is also full applicable to non hierarchical IGPs
cenario is described in
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-3.2
> .
>
> The corresponding solution will be updated later.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From
hable information ?
Thx a lot,
Robert
On Wed, Mar 30, 2022 at 10:48 AM Aijun Wang
wrote:
> Hi, Robert:
>
>
>
> *From:* Robert Raszuk
> *Sent:* Tuesday, March 29, 2022 3:53 PM
> *To:* Aijun Wang
> *Cc:* Tony Li ; Aijun Wang ;
> lsr
> *Subject:* Re: [Lsr] Is it ne
t Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* Robert Raszuk
> *Sent:* Monday, March 28, 2022 5:01 PM
> *To:* Aijun Wang ; Tony Li
> *Cc:* Aijun Wang ; lsr
> *Subject:* Re: [Lsr] Is it necessary to define new PUB/SUB model to
> moni
Aijun,
> For PUAM, the receiver NEED NOT register anything.
> Once the node fails, all the receivers(normally the nodes within one
area) will be notified.
That's a spec bug not a feature.
Not only those egress nodes which would have otherwise register will get it
with PUAM, but also all P nodes
opportunity to improve.
>
>
>
> Rgds
>
> Shraddha
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Robert Raszuk
> *Sent:* Sunday, March 27, 2022 5:22 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* lsr ; Christian Hopps ; Shraddha
> Hegde
to abbreviate that as “Application”. If you
> find that confusing, we can all try to use the more complete name.
>
> But whatever name we use, that is what is being referenced when we discuss
> the use of ASLA.
>
>
>
>Les
>
>
>
> *From:* Robert Raszuk
> *Sent:*
cs is to be used for
> that algo. But in doing so, the App associated with each of the Generic
> Metric advertisements will be Flex-Algo.
>
>
>
> Les
>
>
>
> *From:* Robert Raszuk
> *Sent:* Saturday, March 26, 2022 9:10 AM
> *To:* Les Ginsberg (ginsberg)
nderstand it and want
> to do a major rewrite of it – I am not sure which.
>
> But either way, none of this has anything to do with the original thread.
>
>
>
>Les
>
>
>
> *From:* Robert Raszuk
> *Sent:* Saturday, March 26, 2022 3:43 AM
> *To:* Christian Hopps
gold
etc ...
Now tell me how does it make sense to enable each app on the link delay
attribute ?
Cheers,
Robert
On Sat, Mar 26, 2022 at 6:42 AM Christian Hopps wrote:
>
> Robert Raszuk writes:
>
> > Les,
> >
> > I don't think this is noise.
> >
&g
erization isn’t accurate.
>
>
>
> I don’t think this sub-thread is useful – you are adding noise to the
> conversation.
>
>
>
> If you want to discuss offline – please contact me directly.
>
>
>
>Les
>
>
>
>
>
> *From:* Robert Raszuk
>
> I don’t think there is anything else that needs to be said.
>
>
>
>Les
>
>
>
> *From:* Robert Raszuk
> *Sent:* Friday, March 25, 2022 4:53 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* Shraddha Hegde ; Martin Horneffer <
> m...@lab.dtag.de>
are off-topic with your post.
>
>
>
>Les
>
>
>
>
>
> *From:* Robert Raszuk
> *Sent:* Friday, March 25, 2022 4:41 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* Shraddha Hegde ; Martin Horneffer <
> m...@lab.dtag.de>; lsr@ietf.org
> *Subject:* Re
Hi Les,
Let me clarify if I read you correctly ...
Are you saying that because quoted RFCs have been published in Oct 2020 no
one has a right to define any new standard link attributes any more as
implementations are closed ? Including those which would be common to all
applications on a link ?
page but not much content there
...
Best,
Robert.
On Tue, Mar 8, 2022 at 3:11 PM Acee Lindem (acee) wrote:
> Hi Robert,
>
>
>
> *From: *Robert Raszuk
> *Date: *Tuesday, March 8, 2022 at 7:00 AM
> *To: *Acee Lindem
> *Cc: *Aijun Wang , Alvaro Retana <
> alvaro.
Can you please list those standards ?
Thank you,
R.
On Tue, Mar 8, 2022 at 12:36 PM Acee Lindem (acee) wrote:
> Hi Robert,
>
>
>
> *From: *Robert Raszuk
> *Date: *Tuesday, March 8, 2022 at 4:09 AM
> *To: *Acee Lindem
> *Cc: *Aijun Wang , Alvaro Retana <
> alv
8, 2022 at 4:02 AM Acee Lindem (acee) wrote:
> Hi Aijun,
>
>
>
>
>
>
>
> *From: *Aijun Wang
> *Date: *Monday, March 7, 2022 at 9:41 PM
> *To: *Acee Lindem , Robert Raszuk ,
> 'Alvaro Retana'
> *Cc: *'Lin Han' , "lsr@ietf.org"
> *Subject: *
Hi Alvaro,
Practically speaking, yes Monitor nodes are cool to have. But so are the
Controller nodes. The difference would be that in both cases there is no
topology information being injected by such nodes, however in the latter
case the additional information could be injected.
Such
Hi Tony,
> If FlexAlgo is adopted, then we should expect that it will get stressed
> and that further conditions will be added to a FAD. The problem will only
> become worse the more success that FlexAlgo has. It sounds to me like you
> want FlexAlgo to fail, which seems strange.
Well I have a
Hi Chris,
Tony Li (at least) seemed to think that it was useful to be able to attach
> TE attributes to a link, not just to prefixes. Perhaps I've missed this in
> the thread but what current mechanism (rfc?) are you referring to, to
> identify a link and attach TE attributes to it?
I have two
Hi Aijun,
I do have some sympathy to what you are trying to do here. But I also have
a concern if IGP is the right protocol to load it and use it disseminate
completely opaque to its main role information.
Imagine your CAN use case and use of areas with summarization. The ingress
nodes/machines
Thu, Feb 10, 2022 at 10:59 AM Acee Lindem (acee) 40cisco@dmarc.ietf.org> wrote:
>
>> Hi Robert,
>>
>> This is great to hear – I thought you wanted to make this required for
>> implementation as opposed to a recommendation.
>>
>> Thanks,
>>
>
Hi Acee,
> There was debate regarding making the delay timer described in section 5
a normative requirement.
I see added into new version of the draft the following text into section
5:
The use of OSPF BFD strict-
mode along with mechanisms such as hold-down
*(a delay in the initial
gh). IMO, link quality
> issue is outside the scope of this draft.
>
> Thanks
> Albert
>
> From: Robert Raszuk To: Les Ginsberg <
> ginsb...@cisco.com>
> Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD"
> - draft-ietf-lsr-ospf-bf
Les,
Please kindly present the facts.
The facts are that equivalent functionality in OSPF which has been approved
for years uses a configurable timer which allows both - to wait for BFD as
well to make sure that BFD stays UP till that timer expires. The point I
even started this discussion was
ent to change its FSM in that respect. I do not see why this should
not be at least described in the draft.
Anyhow enough time spent on this ...
Many thx,
Robert
On Sun, Feb 6, 2022 at 11:29 PM Christian Hopps wrote:
>
> Robert Raszuk writes:
>
> > Hi Les,
> >
> >
Dampening can be
used as an unconditional UP transition suppression buffer.
The same applies to interfaces which went down and came UP after
max-suppress-time had already expired.
Thx,
R.
On Sun, Feb 6, 2022 at 11:05 PM Les Ginsberg (ginsberg)
wrote:
> Robert –
>
>
>
>
>
>
Hi Les,
> There is nothing in RFC 5880 (nor in, what I consider to be even more
> relevant, RFC 5882) that requires a BFD implementation to signal UP state
> to a BFD client within a specific time following transition of the BFD
> state machine to UP . An implementation is free to introduce a
draft to bring up OSPF adj. without risk of it to shortly go down.
Thx,
R
On Sun, Feb 6, 2022 at 6:24 PM Gyan Mishra wrote:
> Hi Robert
>
> On Sun, Feb 6, 2022 at 6:11 AM Robert Raszuk wrote:
>
>> Gyan,
>>
>> > Overall I believe the goal of the strict mode BFD
hese additional capabilities (e.g., MTU testing and link quality
> determination beyond what is already in BFD) in a separate draft.
>
> Thanks,
>
> Acee
>
>
>
> *From: *Robert Raszuk
> *Date: *Sunday, February 6, 2022 at 6:11 AM
> *To: *Gyan Mishra
> *Cc: *Acee Lindem
Gyan,
> Overall I believe the goal of the strict mode BFD “wait for BFD” is
accomplished
> and solve all problems
I do not agree with this statement.
As currently defined in the posted version of the draft "wait for BFD"
means wait for BFD control packets to bring the session up.
The session
> leaking of backbone routes without summarization. Also note that the
> virtual link endpoint could be reachable in the transit area but may not be
> up. Multi-hop BFD would still be useful for a virtual link.
>
> Thanks,
>
> Acee
>
>
>
> *From: *Robert Raszuk
>
Muthu,
If you are using virtual link why is this still multihop BFD ?
Thx,
R.
On Fri, Feb 4, 2022 at 6:22 PM Muthu Arul Mozhi Perumal <
muthu.a...@gmail.com> wrote:
> Hi Ketan,
>
> Sure, looking forward to the clarification in the draft on multi-hop BFD..
>
> Just curious, are there
Ketan,
> What the OSPF draft discusses in Sec 5 is a "hold-down" wait period where
> even though the BFD session is established the protocol FSM does not
> proceed further until a period of time has passed to ensure the stability
> of the BFD session.
>
Which protocol FSM ? BFD FSM or OSPF FSM
Hey Albert,
Ok now we are in sync as far as what is the topic.
I think such a delay is very useful and completely in the spirit of OSPF or
ISIS strict-mode operation.
So I do recommend that the draft should discuss it.
The default can be 0 if you think that is the proper value. But the
long in this draft. Which is why I agree with everything you
> say below except for your perception that you are agreeing with Robert. You
> are actually agreeing with myself, Albert, Ketan.
>
>
>
> Thanx for your participation.
>
>
>
> Les
>
>
>
> *From
nted at the OSPF level.
>>>
>>>
>>>
>>> Once you have strict mode support, the sequence becomes:
>>>
>>>
>>>
>>> a)BFD goes down
>>>
>>> b)OSPF goes down in response to BFD
>>>
>>> c)BFD comes back u
ig deeper into what could be a very lengthy discussion. If you
> really want to pursue this idea, I suggest you write a new draft.
>
>
>
>Les
>
>
>
> *From:* Robert Raszuk
> *Sent:* Monday, January 31, 2022 6:59 AM
> *To:* Albert Fu ; Les Ginsberg (ginsberg) &
clients benefit from this. Ad if the link is still
> unstable, it is more likely that the BFD session will go down during the
> delay period than it would be for OSPF because the BFD timers are
> significantly more aggressive.
>
> (BTW, this behavior can be done w/o a BFD protocol ext
. Ad if the link is still
> unstable, it is more likely that the BFD session will go down during the
> delay period than it would be for OSPF because the BFD timers are
> significantly more aggressive.
>
> (BTW, this behavior can be done w/o a BFD protocol extension – it is
> purely a
this behavior can be done w/o a BFD protocol extension – it is
> purely an implementation choice.)
>
>
>
> From a design perspective, dampening is always best done at the lowest
> layer possible. In most cases, interface layer dampening is best. If that
> is not reliable fo
Hi Ketan,
> It explains the scenario of a noisy link that experiences traffic drops.
The point is that BFD may or may not detect noisy links or links with
"degraded or poor quality". There are many failure scenarios - especially
brownouts - where BFD will continue to run just fine over a link
Hi Ketan,
I would like to point out that the draft discusses the BFD "dampening" or
> "hold-down" mechanism in Sec 5. We are aware of BFD implementations that
> include such mechanisms in a protocol-agnostic manner.
>
BFD dampening or hold-time are completely orthogonal to my point. Both have
layer or
>> in the BFD implementation.
>>
>> I am familiar with implementations which apply this timer at the protocol
>> level (AKA BFD client in this context) and this is done precisely because
>> the protocol does NOT have the functionality being defined in this draft.
Hi Les,
That timer and its consistency on both ends clearly belongs to OSPF not to
> BFD.
>
> *[LES:] I disagree. The definition of UP state belongs to the BFD
> protocol/implementation.*
>
> *If you don’t want BFD clients (like OSPF) to react “too quickly” then
> build additional config/logic
gt; Once you have implemented “wait-for-BFD” logic as defined in this draft you
> do not need additional delay timers in the protocol.
>
>
>
> I don’t think the suggestions you are making belong in this document.
>
>
>
> Les
>
>
>
>
>
> *From:* Lsr
Acee,
> I don’t anyone has implemented the later capability. This MTU test
> extension could be added in a separate draft if there were a strong
> requirement.
>
I think you are mixing an example of what BFD could be doing to make sure
the link is fine with the delay timer allowing it to do
Hi Acee,
Can you suggest text which with you’d be happy? I’m sure the authors would
> add you to the acknowledgements.
>
Actually instead of suggesting any new text I would suggest to delete the
two below sentences and it will be fine:
*"In certain other scenarios, a degraded or poor quality
Hi Albert,
> [AF] This draft ensures that BFD can be used to detect failure quickly
> when there is a complete path failure between the nodes. You are right that
> there are many other types of failure that BFD cannot detect.
>
> Indeed, but the draft says otherwise. I think that needs to be
Hi Ketan and all,
I support this draft - it is a useful addition.
There are two elements which I would suggest to adjust in the text before
publication.
*#1 Overpromise*
Even below you say:
> Since there is a issue with forwarding *(which is what BFD detects)*
and in the text we see:
"In
Hi Les,
Yes you are correct. It is a classic pull vs push model.
Push gives you notification about state. That's it.
Pull gives you much more as it includes e2e elements of the data plane - of
course for a bit higher cost.
I would not disregard any of the above.
We have been having similar
> The pulse solution does not suffer from the scale issues.
It shifts that "suffering" to flood the entire domain with information
which is not needed on P routers and selectively useful on the remote PEs.
Also fast signaling the fact that PE may have been disconnected from the
network for a few
ed 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 plane just like you
> push 1000s
Hi Tony,
If a given PE needs to get all notifications from all other PEs it is
> sufficient that it sends to local ABRs a single registration in a form of
> 0.0.0.0/0 and be done.
>
>
> If you look a bit more carefully, you will find that registering for 0/0
> doesn’t work without a bit more
.
Thx,
R.
On Tue, Jan 25, 2022 at 4:42 PM Peter Psenak wrote:
> On 25/01/2022 15:18, Robert Raszuk wrote:
> > Peter,
> >
> > You clearly missed the added new sentence to section 4.3 in version -01
> >
> > It is RECOMMENDED that the ABR register for the
>
ang
> 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
> reconsider.
>
>
>> The
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 Rasz
Peter,
You clearly missed the added new sentence to section 4.3 in version -01
It is RECOMMENDED that the ABR register for the
most specific prefix that is less specific than the original prefix.
Thx,
R
On Tue, Jan 25, 2022 at 2:57 PM Peter Psenak wrote:
> On 25/01/2022 14:07, Rob
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
Peter,
Your math is off.
> 1. 100k registrations in each ABR, 10 million network wide
ABRs will "aggregate" atomic registrations to summaries when passing them
to other ABRs. Please recalculate,
Thx,
R.
On Tue, Jan 25, 2022 at 12:25 PM Peter Psenak wrote:
> Tony,
>
> I'm going to use my
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 ,
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
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
>
> 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)
proposal since he doesn’t think the IGP should be in the business of
> sending node liveness information.
>
> The service itself doesn’t even need to be running on a router at all.
>
>
>
>Les
>
>
>
>
>
> *From:* Robert Raszuk
> *Sent:* Monday, January 24
101 - 200 of 557 matches
Mail list logo