Hi Tony
“So, can we PLEASE stop beating a dead horse?”
As data center have evolved over the years prior to NVO overlay
architectures becoming more prevalent, many operators had moved to from L2
fault domains to an L3 POD based architecture carving the DC or MSDC into
many smaller PODs sub
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, Bruno:
I agree with your thoughts on the solutions to this questions.
Actually, this is the reason that we brought up the thread “Convergence of
Prefixes Unreachable Announcement Proposal” and I think you can review the
discussion of this thread again.
And, in the mail
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
Bruno, inline
From: Bruno Decraene
Date: Wednesday, June 15, 2022 at 12:27 PM
To: Dan Voyer , "lsr@ietf.org"
Subject: [EXT]RE: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce
Hi Daniel,
I agree that the draft-ppsenak-lsr-igp-ureach-prefix-announce, is presented as
“a use
Hi Daniel,
I agree that the draft-ppsenak-lsr-igp-ureach-prefix-announce, is presented as
"a use case"/informational.
My point is that IMO the draft changes the behavior defined in RFC5305/RFC5308.
Indeed, as per those two RFC, I'm allowed, today, to advertise a prefix with
MAX_PATH_METRIC for
Hi Bruno,
Thanks for your comment on the draft. I too, have a minor disagreement on your
disagreement.
The draft-ppsenak-lsr-igp-ureach-prefix-announce, is really presented as “a use
case”/informational. In this case, a PE being hidden from other area due to
route summarization. The draft is
Robin:
Thank- you for responding to me.
As long as the OSPFv3 heads into WG LC at IETF114, then the BGP draft can move
quickly forward.
It takes a long time to work to the top of Alvaro’s review queue. He is
willing to keep the place for the BGP document at the head of the line if I can
get
Hi Robin,
Thanks for the WG update.
From: Lsr on behalf of Lizhenbin
Date: Wednesday, June 15, 2022 at 10:20 AM
To: Susan Hares , lsr
Cc: draft-ietf-lsr-ospfv3-srv6-extensions
Subject: Re: [Lsr] Status of draft-ietf-lsr-ospv3-srv6-extensions
Hi Sue,
Sorry for the late response. Thanks
Hi Sue,
Sorry for the late response. Thanks very much for your reminding. We co-authors
are updating the draft and will refresh it soon.
We will try to move it to WGLC in the IETF114. For the issue of moving BGP-LS
without OSPFv3, I am not experienced enough to reply. Wish to learn the ADs and
Hi Peter, authors, all
Thanks for the draft. I find it a useful contribution to the problem space.
IMHO the use of MAX_PATH_METRIC is a good idea in particular since it can be
made backward compatible and provides incremental benefits with incremental
deployment.
I also have two disagreements
>
> 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
Hi Tom,
I think "Experimental" is more appropriate given all the WG participants
(including myself as WG member) who think it is a very useful flooding
optimization. We've done this in the past and while none of the experimental
RFCs have become popular enough to reach justify promotion to
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
Hi, Peter:
Please review your document carefully:
https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-ureach-prefix-announce-00#section-2.1:(UPA
in IS-IS)
As per the definitions referenced in the preceding section, any
prefix advertisement with a metric value greater than 0xFE00
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.
On 15/06/2022 13:39, Aijun Wang wrote:
Hi, Peter:
What’s my meaning is that if you redefine or reuse the meaning of LSInfinity,
there will be issues for other scenario that want to utilize this field.
In the mentioned example, the prefixes associated with the LSInfinity is
certainly reachable,
From: John Scudder
Sent: 14 June 2022 21:49
Cc: John E Drake; Les Ginsberg (ginsberg); Tony Li; tom petch; Acee Lindem
(acee); lsr@ietf.org
Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
draft-ietf-lsr-dynamic-flooding
I’ll point out that option 2 frees us from having to run an annual
Hi, Peter:
What’s my meaning is that if you redefine or reuse the meaning of LSInfinity,
there will be issues for other scenario that want to utilize this field.
In the mentioned example, the prefixes associated with the LSInfinity is
certainly reachable, which is contradicted with your
Aijun,
On 15/06/2022 12:12, Aijun Wang wrote:
Hi, Peter:
If you use LSInfinity as the indicator of the prefixes unreachable, then
how about you solve the situations that described in
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-6.4
From: Lsr on behalf of Les Ginsberg (ginsberg)
Sent: 14 June 2022 17:29
Jaideep –
I am not aware that any standard formally defines a system-id of ..
as invalid.
If there is, it would be an ISO specification – but a perusal of ISO 10589, ISO
8348, and ISO 7498 did not yield any
(Taking this offlist – BCC the WG)
Jaideep –
From a standards perspective I have provided you with what I know.
To characterize this as something which can cause “serious routing issues” is
an exaggeration.
Given that the same system ID cannot be used on more than one router, at worst
if you
Hi, Peter:
If you use LSInfinity as the indicator of the prefixes unreachable, then how
about you solve the situations that described in
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-6.4,
in which the the metric in parent TLV MUST be set to LSInfinity?
Will you
Hi Gunter,
On 15/06/2022 11:02, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
Hi Robert,
I agree with you that the operator problem space is not limited to
multi-area/levels with IGP summarisation.
With the PUA/UPA proposals I get the feeling that LSR WG is jumping into
the deep-end and
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.
Hi Robert,
I agree with you that the operator problem space is not limited to
multi-area/levels with IGP summarisation.
With the PUA/UPA proposals I get the feeling that LSR WG is jumping into the
deep-end and is re-vectoring the IGP to carry opaque information not used for
SPF/cSPF.
I
Hi Aijun,
Thanks for sharing your thoughts.
I agree that the observed problem is valid and is service impacting for
operators.
It is wise to be conservative about using the IGP as an API to advertise opaque
properties. The PUA/UPA have nothing to do with calculating SPF/cSPF.
Maybe we should
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
33 matches
Mail list logo
