"Les Ginsberg (ginsberg)" writes:
Chris/David -
I was replying to Peter saying that implementations are using the max metric
announcements to avoid sending traffic to overload routers.
[LES:] Are you claiming this because you know this to be true - or are you just
speculating that an imp
Chris/David -
>
> I was replying to Peter saying that implementations are using the max metric
> announcements to avoid sending traffic to overload routers.
[LES:] Are you claiming this because you know this to be true - or are you just
speculating that an implementation "might" do this?
If t
On 12/11/2022 06:45, Christian Hopps wrote:
On Nov 9, 2022, at 2:13 PM, Peter Psenak
wrote:
On 09/11/2022 14:56, David Lamparter wrote:
On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
I guess I'd like to understand what one would accomplish with further
specification of
Hi Chris,
> If that means they are installing a negative route then they are
modifying the IP routing table.
> If he meant they don't do anything with the announcement, well then
that's in spec.
There are lots of options between installing negative route in IP routing
table and not doing anything
Robert Raszuk writes:
Chris,
unreachable routes in the IP routing table
That quote leaves zero context at all for what I was saying.
I was replying to Peter saying that implementations are using the max metric
announcements to avoid sending traffic to overload routers. If that means they
Hi, Robert:
> "other than building the normal IP routing table"
There may be different purposes, so advertise the “unreachable within the
summary address” should be signed explicitly.
Aijun Wang
China Telecom
> On Nov 12, 2022, at 11:59, Robert Raszuk wrote:
>
>
> Chris,
>
> > unreachab
Chris,
> unreachable routes in the IP routing table
I don't see anywhere in the UPA spec even a hint that those unreachable
pulses would be installed in the IP routing table. It seems to be a local
implementation choice how ISIS or OSPF would inform other protocols about
them.
In fact the quote
> On Nov 9, 2022, at 2:13 PM, Peter Psenak
> wrote:
>
> On 09/11/2022 14:56, David Lamparter wrote:
>> On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
>>> I guess I'd like to understand what one would accomplish with further
>>> specification of prefix reachable? What requi
>
>
> > I think the point of this was that it could be other applications where
> > an ephemeral unreachability notification is useful. For this type of
> > notification, recursive route resolution is the primary application.
> > However, I’ll defer to the authors.
>
> that is correct indeed.
>
Ok
;mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
*Subject: *Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce /
UPA IS-IS semantics
Peter,
> But:
> - that is nonetheless a change which is non backward
compatible with people currently
Hi Robert,
From: Robert Raszuk
Date: Thursday, November 10, 2022 at 10:51 AM
To: Acee Lindem
Cc: Peter Psenak , Bruno Decraene
, David Lamparter ,
"lsr@ietf.org"
Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS
semantics
> But BGP service PIC is the
Hi, Peter:
I suggest that you consider such problems and the solutions from the broader
viewpoint, not just the behavior of one single device, or only from the vendor
side.
To deploy the mechanism into the network, the operator must assure it will not
conflict with other possible usages, and no
raene , David Lamparter <
> equi...@diac24.net>, Acee Lindem , "lsr@ietf.org" <
> lsr@ietf.org>
> *Subject: *Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA
> IS-IS semantics
>
>
>
> Peter,
>
>
>
> > But:
> > - that is non
Hi Robert,
From: Robert Raszuk
Date: Thursday, November 10, 2022 at 9:41 AM
To: Peter Psenak
Cc: Bruno Decraene , David Lamparter
, Acee Lindem , "lsr@ietf.org"
Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS
semantics
Peter,
> But:
> - that
On 09/11/2022 22:51, Aijun Wang wrote:
Hi, Peter:
Actually, the “unreachable” meaning of LSInfinity in current standard is
not the same as the “unreachable” meaning that we are supposed to act:
1) In current standard, the “unreachable” is meant that the related
prefix will not be in the FIB.(y
Peter,
> But:
> > - that is nonetheless a change which is non backward compatible with
> people currently using such high metric without the intention to mean UPA
> > - to differentiate different usages (e.g. your UPA, my other usage such
> as "graceful shutdown" (still reachable but will disappea
Bruno,
On 10/11/2022 02:18, bruno.decra...@orange.com wrote:
Peter,
From: Peter Psenak
Sent: Wednesday, November 9, 2022 2:13 PM
On 09/11/2022 14:56, David Lamparter wrote:
On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
I guess I'd like to understand what one would acc
Peter,
> From: Peter Psenak
> Sent: Wednesday, November 9, 2022 2:13 PM
>
> On 09/11/2022 14:56, David Lamparter wrote:
> > On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
> >> I guess I'd like to understand what one would accomplish with further
> >> specification of prefix
Aijun,
> there is another summary address that covers it is in the FIB.
You keep bringing this point over and over.
But what you are not aware of is that service route validation or
invalidation can be set and tracked for reachability with specific length
of the next hop. Both validation and in
Hi, Peter:
Actually, the “unreachable” meaning of LSInfinity in current standard is not
the same as the “unreachable” meaning that we are supposed to act:
1) In current standard, the “unreachable” is meant that the related prefix will
not be in the FIB.(you can read again and again
https://www.
On 09/11/2022 16:32, David Lamparter wrote:
On Wed, Nov 09, 2022 at 03:16:11PM +, Peter Psenak wrote:
On 09/11/2022 15:48, David Lamparter wrote:
On Wed, Nov 09, 2022 at 02:32:35PM +, Peter Psenak wrote:
as far as that /128 is not used as BGP next-hop (which obviously is not
the case),
On Wed, Nov 09, 2022 at 03:16:11PM +, Peter Psenak wrote:
> On 09/11/2022 15:48, David Lamparter wrote:
> > On Wed, Nov 09, 2022 at 02:32:35PM +, Peter Psenak wrote:
> >> as far as that /128 is not used as BGP next-hop (which obviously is not
> >> the case),
> >
> > You keep saying things
On 09/11/2022 15:48, David Lamparter wrote:
On Wed, Nov 09, 2022 at 02:32:35PM +, Peter Psenak wrote:
On 09/11/2022 15:26, David Lamparter wrote:
On Wed, Nov 09, 2022 at 02:13:17PM +, Peter Psenak wrote:
and why that would be a problem? Such prefix would never be used to for
resolution
On Wed, Nov 09, 2022 at 02:32:35PM +, Peter Psenak wrote:
> On 09/11/2022 15:26, David Lamparter wrote:
> > On Wed, Nov 09, 2022 at 02:13:17PM +, Peter Psenak wrote:
> >> and why that would be a problem? Such prefix would never be used to for
> >> resolution of the BGP prefix.
> >
> > Says
On 09/11/2022 15:26, David Lamparter wrote:
On Wed, Nov 09, 2022 at 02:13:17PM +, Peter Psenak wrote:
On 09/11/2022 14:56, David Lamparter wrote:
On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
The problem is that a prefix with metric > 0xfe00 isn't actually an
unrea
On Wed, Nov 09, 2022 at 02:13:17PM +, Peter Psenak wrote:
> On 09/11/2022 14:56, David Lamparter wrote:
> > On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
> > The problem is that a prefix with metric > 0xfe00 isn't actually an
> > unreachable prefix, it's a prefix that
On 09/11/2022 14:56, David Lamparter wrote:
On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
I guess I'd like to understand what one would accomplish with further
specification of prefix reachable? What requirement would this
satisfy? For the use case UPA is designed to handle
Aijun,
On 09/11/2022 13:21, Aijun Wang wrote:
Hi, Peter:
I think you over explain the meaning of “LSInfinity”. I concur with David:
A less specific prefix may cover it
Then, you conclusion that:
when a prefix is "not considered during the normal Shortest Path First (SPF)
computation", th
On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
> I guess I'd like to understand what one would accomplish with further
> specification of prefix reachable? What requirement would this
> satisfy? For the use case UPA is designed to handle (triggering BGP
> PIC or other local act
One more information:
The explicit solution,
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10
does not require all the nodes be upgraded simultaneously.
Aijun Wang
China Telecom
> On Nov 9, 2022, at 12:06, Peter Psenak
> Using a new Sub-TLV to signal unr
Speaking as WG Participant:
Hi Bruno, David,
I guess I'd like to understand what one would accomplish with further
specification of prefix reachable? What
requirement would this satisfy? For the use case UPA is designed to handle
(triggering BGP PIC or other local
action) , I can't see that t
Hi, Peter:
I think you over explain the meaning of “LSInfinity”. I concur with David:
>> A less specific prefix may cover it
Then, you conclusion that:
> when a prefix is "not considered during the normal Shortest Path First (SPF)
> computation", the result will be that the prefix will become
Hi David,
On 09/11/2022 11:44, David Lamparter wrote:
Hi Peter, hi all,
to iterate on the comment I made on the mic a few minutes ago, I
apparently have a rather different understanding of existing IS-IS
behaviour. Reading 5305/5308,
... "if a prefix is advertised with a
On Wed, Nov 09, 2022 at 10:55:38AM +, bruno.decra...@orange.com wrote:
> > From: Lsr On Behalf Of David Lamparter
> > I'd rather not do that and just add
> > a sub-TLV for it.
>
> I'm fine to use max_prefix as per RFC 5305 (prefix not considered
> during SPF) as this allow for incremental dep
> From: Lsr On Behalf Of David Lamparter
> Sent: Wednesday, November 9, 2022 10:45 AM
> Hi Peter, hi all,
>
>
> to iterate on the comment I made on the mic a few minutes ago, I
> apparently have a rather different understanding of existing IS-IS
> behaviour. Reading 5305/5308,
>
> ...
Hi Peter, hi all,
to iterate on the comment I made on the mic a few minutes ago, I
apparently have a rather different understanding of existing IS-IS
behaviour. Reading 5305/5308,
... "if a prefix is advertised with a metric larger
than MAX_V6_PATH_METRIC (0xFE00), th
36 matches
Mail list logo
