Greetings,
We do not see the text reported in RFC 6823 but is found in RFC 823. If this
is correct, please submit a new errata referencing RFC 823. Errata #6995 will
be deleted.
Thank you.
RFC Editor/cs
> On Jun 16, 2022, at 2:12 AM, RFC Errata System
> wrote:
>
> The following
By the way,
> On Jun 13, 2022, at 1:15 AM, Les Ginsberg (ginsberg)
> wrote:
>
> If you want to see the diff from the respective RFCs, simply go to the IETF
> Diff tool: https://tools.ietf.org/rfcdiff
tools.ietf.org and everything hosted there is deprecated. You’re better off
using
Acee -
I agree.
It appears the intent was to file it against RFC 823 (which BTW is Historic).
Les
> -Original Message-
> From: Acee Lindem (acee)
> Sent: Thursday, June 16, 2022 11:38 AM
> To: RFC Errata System ; Les Ginsberg (ginsberg)
> ; sprev...@cisco.com; imc.sh...@gmail.com;
This Errata should be summarily rejected as there is no such reference in RFC
6823. Perhaps, it was reported against the wrong RFC.
Thanks,
Acee (as WG Co-Chair)
On 6/16/22, 5:13 AM, "Lsr on behalf of RFC Errata System"
wrote:
The following errata report has been submitted for
Hi Gunter, see [DV]
From: "Van De Velde, Gunter (Nokia - BE/Antwerp)"
Date: Thursday, June 16, 2022 at 6:38 AM
To: Robert Raszuk
Cc: Gyan Mishra , Dan Voyer ,
"draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org"
,
draft-wang-lsr-prefix-unreachable-annoucement
, "lsr@ietf.org"
Subject:
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
Hi Bruno,
please see inline (##PP2):
On 16/06/2022 12:01, bruno.decra...@orange.com wrote:
Hi Peter,
Thanks for your reply. Please see inline [Bruno2]
Orange Restricted
-Original Message-
From: Peter Psenak
Sent: Thursday, June 16, 2022 11:22 AM
To: DECRAENE Bruno INNOV/NET ;
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
reachability or liveness. “
Sure, but UPA signals that a locator is unreachable, would that not result
Hi Gunter,
please see inline (##PP):
On 16/06/2022 10:09, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
Hi Gyan, Daniel, Peter, All,
Thanks for sharing your insights and I agree mostly with your feedback
I agree and understand that summarization is needed to reduce the size
of the LSDB.
Hi Peter,
Thanks for your reply. Please see inline [Bruno2]
Orange Restricted
> -Original Message-
> From: Peter Psenak
> Sent: Thursday, June 16, 2022 11:22 AM
> To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org
> Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce
>
> Hi
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
Hi Bruno,
thanks for your feedback, please see inline (##PP):
On 15/06/2022 16:09, bruno.decra...@orange.com wrote:
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
The following errata report has been submitted for RFC6823,
"Advertising Generic Information in IS-IS".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6995
--
Type: Technical
Reported by:
Hi, Gunter:
Thanks for your through thoughts.
For your mentioned case 1), the PUA draft has already the considerations:
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-09#section-4
“If the nodes in the area receive the PUAM flood from all of its ABR
Hi Les,
Thanks for the response.
Yes, i understand that it would require a lot of efforts and can take some
years.
But as we discussed SYS ID 0 should be considered valid as Standard
Documents doesn't define otherwise and at same time we should try to use a
logical value as a SYS ID so we don't
Hi Gyan, Daniel, Peter, All,
Thanks for sharing your insights and I agree mostly with your feedback
I agree and understand that summarization is needed to reduce the size of the
LSDB. I also agree summarization good design practice, especially with IPv6 and
SRv6 in mind. There never has been
Daniel, inline
Orange Restricted
From: Voyer, Daniel
Sent: Wednesday, June 15, 2022 9:43 PM
To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org
Subject: RE: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce
Bruno, inline
From: Bruno Decraene
mailto:bruno.decra...@orange.com>>
Date: Wednesday, June
Hi Aijun,
Orange Restricted
From: Aijun Wang
Sent: Thursday, June 16, 2022 1:59 AM
To: DECRAENE Bruno INNOV/NET
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce
Hi, Bruno:
I agree with your thoughts on the solutions to this questions.
Actually, this is the
20 matches
Mail list logo
