t R4 as the bypass router to reach prefix
>Pt2.
> ***
>
> G/
>
>
> -Original Message-
> From: Peter Psenak
> Sent: Thursday, June 16, 2022 12:04 PM
> To: Van De Velde, Gunter (Nokia - BE/Antwerp)
> ; Gyan Mishra ; Voyer,
> Daniel
> Cc: dr
-prefix-annou...@ietf.org;
draft-wang-lsr-prefix-unreachable-annoucement
; lsr@ietf.org
Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
Hi Gunter,
please see inline (##PP):
On 16/06/2022 10:09, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> Hi Gyan, Daniel, Peter,
l.vo...@bell.ca>, "
>> draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org" <
>> draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>,
>> draft-wang-lsr-prefix-unreachable-annoucement <
>> draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org>
>> Cc: Gyan Mishra , Dan Voyer ,
>> "draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org"
>> ,
>> draft-wang-lsr-prefix-unreachable-annoucement
>> , "lsr@ietf.org"
>>
>> Subject: [EXT]RE: [Lsr] Thoughts about PUAs - are w
prefix-annou...@ietf.org" <
> draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>,
> draft-wang-lsr-prefix-unreachable-annoucement <
> draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org>, "lsr@ietf.org" <
> lsr@ietf.org>
> *Subject: *[EXT]RE: [Ls
t;lsr@ietf.org"
Subject: [EXT]RE: [Lsr] Thoughts about PUAs - are we not over-engineering?
Hi Robert, Peter, Bruno
You wrote:
“Aas there is no association between node_id (perhaps loopback) and SIDs (note
that egress can use many SIDs) UPA really does not signal anything about SIDs
rea
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
-wang-lsr-prefix-unreachable-annoucement
; lsr@ietf.org
Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
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
] Thoughts about PUAs - are we not over-engineering?
Summarization has always been a best practice for network scalability
thereby reducing the size of the RIB and LSDB.
So in this case as Dan pointed out, the summary route is an abstraction
of the area and so if a component prefix of the summary
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
t; If there is an SRTE or sr-policy using a given SID somewhere in the SID list…
> and suddenly
>
>
>
> From: Gyan Mishra
> Sent: Thursday, June 16, 2022 6:12 AM
> To: Voyer, Daniel
> Cc: Van De Velde, Gunter (Nokia - BE/Antwerp)
> ;
> draft-ppsenak-l
-unreachable-annoucement
; lsr@ietf.org
Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
Summarization has always been a best practice for network scalability thereby
reducing the size of the RIB and LSDB.
So in this case as Dan pointed out, the summary route is an abstraction
Summarization has always been a best practice for network scalability
thereby reducing the size of the RIB and LSDB.
So in this case as Dan pointed out, the summary route is an abstraction of
the area and so if a component prefix of the summary became unreachable we
need a way to signal that the
Hi Gunter,
Thanks for your comments,
The idea, here, with summarization is to "reduce" the LSDB quite a lots and
make a given backbone much more scalable / flexible and allow to simplify NNI's
within that given backbones considerably.
Summarization is "needed" for better scale and, in the
Hi Gunter,
Thanks for your comments,
The idea, here, with summarization is to "reduce" the LSDB quite a lots and
make a given backbone much more scalable / flexible and allow to simplify NNI's
within that given backbones considerably.
Summarization is "needed" for better scale and, in the
>
> 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
On 15/06/2022 15:41, Robert Raszuk wrote:
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
> 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:47, Robert Raszuk wrote:
Peter,
My question is precise your answer is pretty loose :)
Imagine I use summarization and as you many times said there is no BGP
running. So how do I indicate planned scheduled maintenance in such
cases ? Say from either ABRs or
Peter,
My question is precise your answer is pretty loose :)
Imagine I use summarization and as you many times said there is no BGP
running. So how do I indicate planned scheduled maintenance in such cases ?
Say from either ABRs or PEs/Ps itself ?
In fact, looking practically that may be
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 that brings another question ... Do you envision to use UPA
also to indicate planned
fication
>>>>> defined in RFC5305 and RFC5308 that allow the metric larger then
>>>>> MAX_PATH_METRIC to be used "for purposes other than building the normal
>>>>> IP routing table". We are just documenting one of them.
>>>>
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.
G/
*From:*Robert Raszuk
*Sent:* Tuesday, June 14, 2022 11:51 AM
*To:* Van De Velde, Gunter (Nokia - BE/Antwerp)
*Cc:* lsr ; draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org;
draft-wang-lsr-prefix-unreachable-annoucement
*Subject:* Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
;>>> It could very well be that re-vectoring is the best solution, but I guess
>>>> we need to agree first on understanding the operator problem space.
>>>> G/
>>>> *From:*Robert Raszuk
>>>> *Sent:* Tuesday, June 14, 2022 11:51 AM
>>>
org;
draft-wang-lsr-prefix-unreachable-annoucement
*Subject:* Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
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
an De Velde, Gunter (Nokia - BE/Antwerp)
>>
>> *Cc:* lsr ;
>> draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org;
>> draft-wang-lsr-prefix-unreachable-annoucement
>>
>> *Subject:* Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
>> Hello Gunter
blem space.
G/
*From:*Robert Raszuk
*Sent:* Tuesday, June 14, 2022 11:51 AM
*To:* Van De Velde, Gunter (Nokia - BE/Antwerp)
*Cc:* lsr ;
draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org;
draft-wang-lsr-prefix-unreachable-annoucement
*Subject:* Re: [Lsr] Thoughts about PUAs - are w
Hi Gunter,
please see inline:
On 15/06/2022 10:38, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
Hi Peter, All,
From a BGP perspective (PE service nodes) the event detection when transport
tunnel end-point suddenly becomes unreachable is an operational problem. I
think we all agree.
De Velde, Gunter (Nokia - BE/Antwerp)
Cc: lsr ; draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org;
draft-wang-lsr-prefix-unreachable-annoucement
Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
Hello Gunter,
I agree with pretty much all you said except the conclusion
-annou...@ietf.org;
draft-wang-lsr-prefix-unreachable-annoucement
Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
Hi, Gunter:
Let me try to answer some of your concerns.
The reason that we prefer to the Summary+PUA/UPA solution is that the node
failure(which is the main
Hi Peter, All,
From a BGP perspective (PE service nodes) the event detection when transport
tunnel end-point suddenly becomes unreachable is an operational problem. I
think we all agree.
This problem exists in any multi-domain network, and is not limited to a
multi-area/level IGP with
indem (acee) wrote:
>> Speaking as WG member:
>>
>>
>>
>> From: Lsr on behalf of Robert Raszuk
>>
>> Date: Tuesday, June 14, 2022 at 9:27 AM
>> To: Christian Hopps
>> Cc: Gunter Van de Velde , lsr ,
>> "draft-ppsenak-lsr-ig
Hi Gunter,
please see inline:
On 14/06/2022 10:59, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
Hi All,
When reading both proposals about PUA's:
* draft-ppsenak-lsr-igp-ureach-prefix-announce-00
* draft-wang-lsr-prefix-unreachable-annoucement-09
The identified problem space seems a
t-wang-lsr-prefix-unreachable-annoucement <
> draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org>
> *Subject: *Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
>
>
>
> All,
>
>
>
> > What is wrong with simply not doing summaries
>
>
>
&
ghts about PUAs - are we not over-engineering?
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 any good implementation will allow one to punch holes in their area
ranges so
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
> On Jun 14, 2022, at 04:59, Van De Velde, Gunter (Nokia - BE/Antwerp)
> wrote:
>
> What is wrong with simply not doing summaries and forget about these PUAs to
> pinch holes in the summary prefixes? this worked very well during last two
> decennia. Are we not over-engineering with PUAs?
Hi, Gunter:
Let me try to answer some of your concerns.
The reason that we prefer to the Summary+PUA/UPA solution is that the node
failure(which is the main scenario that we focus now) is one rarely thing in
the network. Then the unreachable event triggered mechanism is more efficient
than
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
Hi All,
When reading both proposals about PUA's:
* draft-ppsenak-lsr-igp-ureach-prefix-announce-00
* draft-wang-lsr-prefix-unreachable-annoucement-09
The identified problem space seems a correct observation, and indeed summaries
hide remote area network instabilities. It is one of the perceived
41 matches
Mail list logo
