Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Christian Hopps]

"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 implementation "might" do this?


I think you may have misunderstood me. I wasn't claiming anything, rather I was 
replying to a point Peter brought up about overload bit.

I believe David was also not talking about overload bit either. He was saying 
there was a case of using a >= max metric prefix to distribute non-routing 
specific information about a prefix, and thus it would probably be wrong to modify 
routing to that prefix based on that advertisement. At least that's how I read his 
comment.

Thanks,
Chris.



If there is an implementation doing this (i.e., sending max-metric for prefixes
in conjunction with setting the OL bit) I would like to know - and I would like
to know why such an implementation does this.

I am familiar with implementations that may set max-link-metric in conjunction 
with setting the OL bit.
I am also familiar with implementations that withdraw advertisements of 
prefixes in conjunction with setting the OL bit (oftentimes under control of a 
configuration option).
But I am not aware of implementations that send prefix advertisements with max
metric in conjunction with setting the OL bit. Doing so seems rather odd and not
very useful. If an implementation wants to indicate that traffic for that
destination should not be sent to that router, it would normally simply stop
advertising the prefix.
(The OL bit, of course, would keep traffic from transiting the router.)

??

   Les



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr




signature.asc
Description: PGP signature
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Les Ginsberg (ginsberg)]

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 there is an implementation doing this (i.e., sending max-metric for prefixes 
in conjunction with setting the OL bit) I would like to know - and I would like 
to know why such an implementation does this.

I am familiar with implementations that may set max-link-metric in conjunction 
with setting the OL bit.
I am also familiar with implementations that withdraw advertisements of 
prefixes in conjunction with setting the OL bit (oftentimes under control of a 
configuration option).
But I am not aware of implementations that send prefix advertisements with max 
metric in conjunction with setting the OL bit. Doing so seems rather odd and 
not very useful. If an implementation wants to indicate that traffic for that 
destination should not be sent to that router, it would normally simply stop 
advertising the prefix.
(The OL bit, of course, would keep traffic from transiting the router.)

??

   Les



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Peter Psenak]

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 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 there would be any case
where you wouldn’t want to take this action for an unreachable prefix.

The problem is that a prefix with metric > 0xfe00 isn't actually an
unreachable prefix, it's a prefix that doesn't have specific routing
information associated with it, which in turn allows sticking other data
into it that might be routing-related but not quite a reachability.


well, that is your interpretation. For me a prefix with metric > 0xfe00 is 
unreachable. Implementations use the max-metric today to signal the prefix 
unreachability - to avoid reaching local/leaked/redistributed prefixes in cases 
where OL-bit is set on the originator. So we are not doing anything new here 
really.


[as wg-member]

But his interpretation seems correct. RFC5305 says specifically that the prefix 
is not to be used for building the normal IP routing table, that would include 
not creating/installing blackhole/reject routes in the normal IP routing table.

If a prefix is advertised with a metric larger then MAX_PATH_METRIC
(0xFE00, see paragraph 3.0), this prefix MUST NOT be considered
during the normal SPF computation.  This allows advertisement of a
prefix for purposes other than building the normal IP routing table.

Do the implementations you’re referring to install unreachable routes in the IP 
routing table, seemingly in violation of this?


no.

And we are not proposing anything like that to be done with UPA either. 
The usage of the UPA is up to the receiving application. How it deals 
with the UPA signal is outside of the scope of the UPA draft.


thanks,
Peter




Thanks,
Chris.



I vaguely remember several years back we did indeed implement something
(seriously no memory on details) that resulted in the creation of a new
prefix reachability TLV with some experimental/local sub-TLVs.  These
prefixes did not exist in the IS-IS domain beforehand.  I have no idea
what the operational reality is on the existence of such things, but I
know that /some/ code exists that does this.
To boil this down into the core of the essence and be explicit,
- you can create an IS-IS prefix reachability for some arbitrary prefix,
   and stick > 0xfe00 into the metric, and that won't have any effect
   on the existing IS-IS domain
- this has in fact been done to carry custom bits of information that
   for one reason or another were decided to be routing-related and thus
   make sense to put there
- the assumption for the use case is that there are indeed less specific
   covering prefixes around, providing actual reachability
- any setup doing that would now suddenly have fresh "unreachable"
   semantics attached to something that didn't have them before, which
   breaks things (or rather: prevents enabling/deployment of the UPA
   feature)


and why that would be a problem? Such prefix would never be used to for 
resolution of the BGP prefix. So the presence of such unreachable prefix would 
never trigger any action even of the UPA processing was enabled on the 
receiver. I don't see a problem.


- (if those extra prefixes are created with 0x metric, a
   configurable >= limit for UPA does not help either.)


again, what is the problem?


Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
(IMHO) not a significant cost, and completely eliminates this issue.
The only reason against it (that I can think of) is that the
advertisement might be a little bit larger;  a new sub-TLV or flag bit
should be completely invisible to existing implementations (= I don't
see how this would create compatibility or rollout problems.)


I'm afraid, you forgot to consider an operational aspect of the solution.

thanks,
Peter


Cheers,
-David


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Robert Raszuk]

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 with that.

As example negative route may be passed directly to BGP to invalidate BGP
next hop and trigger a new best path run on a set of routes which happen to
select path with such next hop as best.

That would not require to install negative route anywhere.

Second an implementation may have N RIBs - one of them be negative and be
used for next hop validation. It is clearly not an IP routing table
in terms of IP reachability.

A good test perhaps would be to locally originate ICMP ping to PUA covered
dst from PUA receiving node after getting PUA for 1.1.1.1/32 (before the
timeout) ... If ICMP packets will go out of the box to IGP neighbor as
covered by say summary of 1.1.1.0/24 that means PUA is in spec as IP
routing table is unaltered. If we would not see such packets that would
mean there is base for more discussions and the point you are making
stands.

Cheers,
Robert


On Sun, Nov 13, 2022 at 1:18 PM Christian Hopps  wrote:

>
> 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 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.
>
> Thanks,
> Chris.
>
> >
> > 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 you provided specifically "other than building the
> > normal IP routing table" IMO endorses quite verbatim what Peter
> > claims. They can be used for other purposes then building a
> > reachability table.
> >
> > Thx,
> > R.
> >
> >
> >
> >
> >
> >
> > On Sat, Nov 12, 2022 at 6:47 AM Christian Hopps 
> > wrote:
> >
> >
> >
> > > On Nov 9, 2022, at 2:13 PM, Peter Psenak  > 40cisco@dmarc.ietf.org> 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 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 there would be
> > any case
> > >>> where you wouldn’t want to take this action for an
> > unreachable prefix.
> > >> The problem is that a prefix with metric > 0xfe00 isn't
> > actually an
> > >> unreachable prefix, it's a prefix that doesn't have specific
> > routing
> > >> information associated with it, which in turn allows sticking
> > other data
> > >> into it that might be routing-related but not quite a
> > reachability.
> > >
> > > well, that is your interpretation. For me a prefix with metric
> > > 0xfe00 is unreachable. Implementations use the max-metric
> > today to signal the prefix unreachability - to avoid reaching
> > local/leaked/redistributed prefixes in cases where OL-bit is set
> > on the originator. So we are not doing anything new here really.
> >
> > [as wg-member]
> >
> > But his interpretation seems correct. RFC5305 says specifically
> > that the prefix is not to be used for building the normal IP
> > routing table, that would include not creating/installing
> > blackhole/reject routes in the normal IP routing table.
> >
> >If a prefix is advertised with a metric larger then
> > MAX_PATH_METRIC
> >(0xFE00, see paragraph 3.0), this prefix MUST NOT be
> > considered
> >during the normal SPF computation.  This allows advertisement
> > of a
> >prefix for purposes other than building the normal IP routing
> > table.
> >
> > Do the implementations you’re referring to install unreachable
> > routes in the IP routing table, seemingly in violation of this?
> >
> > Thanks,
> > Chris.
> >
> >
> > >> I vaguely remember several years back we did indeed implement
> > something
> > >> (seriously no memory on details) that resulted in the creation
> > of a new
> > >> prefix reachability TLV with some experimental/local
> > sub-TLVs.  These
> > >> prefixes did not exist in the IS-IS domain beforehand.  I have
> > no idea
> > >> what the 

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Christian Hopps]

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 
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.

Thanks,
Chris.



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 you provided specifically "other than building the
normal IP routing table" IMO endorses quite verbatim what Peter
claims. They can be used for other purposes then building a
reachability table. 

Thx,
R.






On Sat, Nov 12, 2022 at 6:47 AM 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 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 there would be
any case
>>> where you wouldn’t want to take this action for an
unreachable prefix.
>> The problem is that a prefix with metric > 0xfe00 isn't
actually an
>> unreachable prefix, it's a prefix that doesn't have specific
routing
>> information associated with it, which in turn allows sticking
other data
>> into it that might be routing-related but not quite a
reachability.
>
> well, that is your interpretation. For me a prefix with metric
> 0xfe00 is unreachable. Implementations use the max-metric
today to signal the prefix unreachability - to avoid reaching
local/leaked/redistributed prefixes in cases where OL-bit is set
on the originator. So we are not doing anything new here really.

[as wg-member]

But his interpretation seems correct. RFC5305 says specifically
that the prefix is not to be used for building the normal IP
routing table, that would include not creating/installing
blackhole/reject routes in the normal IP routing table.

   If a prefix is advertised with a metric larger then
MAX_PATH_METRIC
   (0xFE00, see paragraph 3.0), this prefix MUST NOT be
considered
   during the normal SPF computation.  This allows advertisement
of a
   prefix for purposes other than building the normal IP routing
table.

Do the implementations you’re referring to install unreachable
routes in the IP routing table, seemingly in violation of this?

Thanks,
Chris.


>> I vaguely remember several years back we did indeed implement
something
>> (seriously no memory on details) that resulted in the creation
of a new
>> prefix reachability TLV with some experimental/local
sub-TLVs.  These
>> prefixes did not exist in the IS-IS domain beforehand.  I have
no idea
>> what the operational reality is on the existence of such
things, but I
>> know that /some/ code exists that does this.
>> To boil this down into the core of the essence and be
explicit,
>> - you can create an IS-IS prefix reachability for some
arbitrary prefix,
>>   and stick > 0xfe00 into the metric, and that won't have
any effect
>>   on the existing IS-IS domain
>> - this has in fact been done to carry custom bits of
information that
>>   for one reason or another were decided to be routing-related
and thus
>>   make sense to put there
>> - the assumption for the use case is that there are indeed
less specific
>>   covering prefixes around, providing actual reachability
>> - any setup doing that would now suddenly have fresh
"unreachable"
>>   semantics attached to something that didn't have them
before, which
>>   breaks things (or rather: prevents enabling/deployment of
the UPA
>>   feature)
>
> and why that would be a problem? Such prefix would never be
used to for resolution of the BGP prefix. So the presence of such
unreachable prefix would never trigger any action even of the UPA
processing was enabled on the receiver. I don't see a problem.
>
>> - (if those extra prefixes are created with 0x metric,
a
>>   configurable >= limit for UPA does not help either.)
>
> again, what is the problem?
>
>> Making IS-IS UPA explicit with a bit, sub-TLV, or whatever
else is
>> (IMHO) not a significant cost, and completely eliminates this
issue.

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Aijun Wang]

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,
> 
> > 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 you provided specifically "other than building the normal 
> IP routing table" IMO endorses quite verbatim what Peter claims. They can be 
> used for other purposes then building a reachability table. 
> 
> Thx,
> R.
> 
> 
> 
> 
> 
> 
>> On Sat, Nov 12, 2022 at 6:47 AM 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 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 there would be any case
>> >>> where you wouldn’t want to take this action for an unreachable prefix.
>> >> The problem is that a prefix with metric > 0xfe00 isn't actually an
>> >> unreachable prefix, it's a prefix that doesn't have specific routing
>> >> information associated with it, which in turn allows sticking other data
>> >> into it that might be routing-related but not quite a reachability.
>> > 
>> > well, that is your interpretation. For me a prefix with metric > 
>> > 0xfe00 is unreachable. Implementations use the max-metric today to 
>> > signal the prefix unreachability - to avoid reaching 
>> > local/leaked/redistributed prefixes in cases where OL-bit is set on the 
>> > originator. So we are not doing anything new here really.
>> 
>> [as wg-member]
>> 
>> But his interpretation seems correct. RFC5305 says specifically that the 
>> prefix is not to be used for building the normal IP routing table, that 
>> would include not creating/installing blackhole/reject routes in the normal 
>> IP routing table.
>> 
>>If a prefix is advertised with a metric larger then MAX_PATH_METRIC
>>(0xFE00, see paragraph 3.0), this prefix MUST NOT be considered
>>during the normal SPF computation.  This allows advertisement of a
>>prefix for purposes other than building the normal IP routing table.
>> 
>> Do the implementations you’re referring to install unreachable routes in the 
>> IP routing table, seemingly in violation of this?
>> 
>> Thanks,
>> Chris.
>> 
>> 
>> >> I vaguely remember several years back we did indeed implement something
>> >> (seriously no memory on details) that resulted in the creation of a new
>> >> prefix reachability TLV with some experimental/local sub-TLVs.  These
>> >> prefixes did not exist in the IS-IS domain beforehand.  I have no idea
>> >> what the operational reality is on the existence of such things, but I
>> >> know that /some/ code exists that does this.
>> >> To boil this down into the core of the essence and be explicit,
>> >> - you can create an IS-IS prefix reachability for some arbitrary prefix,
>> >>   and stick > 0xfe00 into the metric, and that won't have any effect
>> >>   on the existing IS-IS domain
>> >> - this has in fact been done to carry custom bits of information that
>> >>   for one reason or another were decided to be routing-related and thus
>> >>   make sense to put there
>> >> - the assumption for the use case is that there are indeed less specific
>> >>   covering prefixes around, providing actual reachability
>> >> - any setup doing that would now suddenly have fresh "unreachable"
>> >>   semantics attached to something that didn't have them before, which
>> >>   breaks things (or rather: prevents enabling/deployment of the UPA
>> >>   feature)
>> > 
>> > and why that would be a problem? Such prefix would never be used to for 
>> > resolution of the BGP prefix. So the presence of such unreachable prefix 
>> > would never trigger any action even of the UPA processing was enabled on 
>> > the receiver. I don't see a problem.
>> > 
>> >> - (if those extra prefixes are created with 0x metric, a
>> >>   configurable >= limit for UPA does not help either.)
>> > 
>> > again, what is the problem?
>> > 
>> >> Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
>> >> (IMHO) not a significant cost, and completely eliminates this issue.
>> >> The only reason against it (that I can think of) is that the
>> >> advertisement might be a little bit larger;  a new sub-TLV or flag bit
>> >> should be completely invisible to existing implementations (= I don't
>> >> see how 

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Robert Raszuk]

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 you provided specifically "other than building the normal
IP routing table" IMO endorses quite verbatim what Peter claims. They can
be used for other purposes then building a reachability table.

Thx,
R.






On Sat, Nov 12, 2022 at 6:47 AM Christian Hopps  wrote:

>
>
> > On Nov 9, 2022, at 2:13 PM, Peter Psenak  40cisco@dmarc.ietf.org> 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 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 there would be any case
> >>> where you wouldn’t want to take this action for an unreachable prefix.
> >> The problem is that a prefix with metric > 0xfe00 isn't actually an
> >> unreachable prefix, it's a prefix that doesn't have specific routing
> >> information associated with it, which in turn allows sticking other data
> >> into it that might be routing-related but not quite a reachability.
> >
> > well, that is your interpretation. For me a prefix with metric >
> 0xfe00 is unreachable. Implementations use the max-metric today to
> signal the prefix unreachability - to avoid reaching
> local/leaked/redistributed prefixes in cases where OL-bit is set on the
> originator. So we are not doing anything new here really.
>
> [as wg-member]
>
> But his interpretation seems correct. RFC5305 says specifically that the
> prefix is not to be used for building the normal IP routing table, that
> would include not creating/installing blackhole/reject routes in the normal
> IP routing table.
>
>If a prefix is advertised with a metric larger then MAX_PATH_METRIC
>(0xFE00, see paragraph 3.0), this prefix MUST NOT be considered
>during the normal SPF computation.  This allows advertisement of a
>prefix for purposes other than building the normal IP routing table.
>
> Do the implementations you’re referring to install unreachable routes in
> the IP routing table, seemingly in violation of this?
>
> Thanks,
> Chris.
>
>
> >> I vaguely remember several years back we did indeed implement something
> >> (seriously no memory on details) that resulted in the creation of a new
> >> prefix reachability TLV with some experimental/local sub-TLVs.  These
> >> prefixes did not exist in the IS-IS domain beforehand.  I have no idea
> >> what the operational reality is on the existence of such things, but I
> >> know that /some/ code exists that does this.
> >> To boil this down into the core of the essence and be explicit,
> >> - you can create an IS-IS prefix reachability for some arbitrary prefix,
> >>   and stick > 0xfe00 into the metric, and that won't have any effect
> >>   on the existing IS-IS domain
> >> - this has in fact been done to carry custom bits of information that
> >>   for one reason or another were decided to be routing-related and thus
> >>   make sense to put there
> >> - the assumption for the use case is that there are indeed less specific
> >>   covering prefixes around, providing actual reachability
> >> - any setup doing that would now suddenly have fresh "unreachable"
> >>   semantics attached to something that didn't have them before, which
> >>   breaks things (or rather: prevents enabling/deployment of the UPA
> >>   feature)
> >
> > and why that would be a problem? Such prefix would never be used to for
> resolution of the BGP prefix. So the presence of such unreachable prefix
> would never trigger any action even of the UPA processing was enabled on
> the receiver. I don't see a problem.
> >
> >> - (if those extra prefixes are created with 0x metric, a
> >>   configurable >= limit for UPA does not help either.)
> >
> > again, what is the problem?
> >
> >> Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
> >> (IMHO) not a significant cost, and completely eliminates this issue.
> >> The only reason against it (that I can think of) is that the
> >> advertisement might be a little bit larger;  a new sub-TLV or flag bit
> >> should be completely invisible to existing implementations (= I don't
> >> see how this would create compatibility or rollout problems.)
> >
> > I'm afraid, you forgot to consider an operational aspect of the solution.
> >
> > thanks,
> > Peter
> >
> >> Cheers,
> >> -David
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> 

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Christian Hopps]

> 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 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 there would be any case
>>> where you wouldn’t want to take this action for an unreachable prefix.
>> The problem is that a prefix with metric > 0xfe00 isn't actually an
>> unreachable prefix, it's a prefix that doesn't have specific routing
>> information associated with it, which in turn allows sticking other data
>> into it that might be routing-related but not quite a reachability.
> 
> well, that is your interpretation. For me a prefix with metric > 0xfe00 
> is unreachable. Implementations use the max-metric today to signal the prefix 
> unreachability - to avoid reaching local/leaked/redistributed prefixes in 
> cases where OL-bit is set on the originator. So we are not doing anything new 
> here really.

[as wg-member]

But his interpretation seems correct. RFC5305 says specifically that the prefix 
is not to be used for building the normal IP routing table, that would include 
not creating/installing blackhole/reject routes in the normal IP routing table.

   If a prefix is advertised with a metric larger then MAX_PATH_METRIC
   (0xFE00, see paragraph 3.0), this prefix MUST NOT be considered
   during the normal SPF computation.  This allows advertisement of a
   prefix for purposes other than building the normal IP routing table.

Do the implementations you’re referring to install unreachable routes in the IP 
routing table, seemingly in violation of this?

Thanks,
Chris.


>> I vaguely remember several years back we did indeed implement something
>> (seriously no memory on details) that resulted in the creation of a new
>> prefix reachability TLV with some experimental/local sub-TLVs.  These
>> prefixes did not exist in the IS-IS domain beforehand.  I have no idea
>> what the operational reality is on the existence of such things, but I
>> know that /some/ code exists that does this.
>> To boil this down into the core of the essence and be explicit,
>> - you can create an IS-IS prefix reachability for some arbitrary prefix,
>>   and stick > 0xfe00 into the metric, and that won't have any effect
>>   on the existing IS-IS domain
>> - this has in fact been done to carry custom bits of information that
>>   for one reason or another were decided to be routing-related and thus
>>   make sense to put there
>> - the assumption for the use case is that there are indeed less specific
>>   covering prefixes around, providing actual reachability
>> - any setup doing that would now suddenly have fresh "unreachable"
>>   semantics attached to something that didn't have them before, which
>>   breaks things (or rather: prevents enabling/deployment of the UPA
>>   feature)
> 
> and why that would be a problem? Such prefix would never be used to for 
> resolution of the BGP prefix. So the presence of such unreachable prefix 
> would never trigger any action even of the UPA processing was enabled on the 
> receiver. I don't see a problem.
> 
>> - (if those extra prefixes are created with 0x metric, a
>>   configurable >= limit for UPA does not help either.)
> 
> again, what is the problem?
> 
>> Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
>> (IMHO) not a significant cost, and completely eliminates this issue.
>> The only reason against it (that I can think of) is that the
>> advertisement might be a little bit larger;  a new sub-TLV or flag bit
>> should be completely invisible to existing implementations (= I don't
>> see how this would create compatibility or rollout problems.)
> 
> I'm afraid, you forgot to consider an operational aspect of the solution.
> 
> thanks,
> Peter
> 
>> Cheers,
>> -David
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Robert Raszuk]

>
>
> > 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 that explanation works !

Thx,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Peter Psenak]

On 10/11/2022 11:59, Acee Lindem (acee) wrote:

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 use case this draft is targeting?

For many emails on LSR and beyond I got point from authors against using 
BGP for such signalling as "BGP may not be running there at all".


So if the draft works *only* with service provided by BGP let's please 
state it clearly in the document. This is not my current assumption.


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.

thanks,
Peter




Thanks,
Acee

Many thx,

R.

On Thu, Nov 10, 2022 at 11:47 AM Acee Lindem (acee) <mailto:a...@cisco.com>> wrote:


Hi Robert,

*From: *Robert Raszuk mailto:rob...@raszuk.net>>
*Date: *Thursday, November 10, 2022 at 9:41 AM
*To: *Peter Psenak mailto:40cisco@dmarc.ietf.org>>
*Cc: *Bruno Decraene mailto:bruno.decra...@orange.com>>, David Lamparter
mailto:equi...@diac24.net>>, Acee Lindem
mailto:a...@cisco.com>>, "lsr@ietf.org
    <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 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
disappear soon), endpoint CPU load is 80%...) one

well, the question is whether it would not make sense to trigger
UPA for
the above mentioned usages as well. Because eventually the
destination
is becoming unreachable anyway and I would want my services to
reroute
to alternate egress node. But seems like folks want to have a
way to
differentiate, so I'm not going to argue against it.

I think You are right if there is a hierarchical service above it.

But consider flat routing - where there is no BGP service on top.
Example - some DCs do use flat routing.

With that I am afraid UPA triggers may not work well (or at all) ...
especially considering that they are history after the timeout
irrespective of the remote prefix state.

But BGP service PIC is the use case this draft is targeting? For
example, there is no intent to install negative routes throughout
the domain.

Thanks,
Acee

Cheers,

R.


thanks,
Peter

 > would need to use different metric values that would need to
be at least locally registered. So why not have the IANA
register a flag and avoid each network operator to do that job?
 >
 > In all cases, I don't see a reason for UPA to change the
meaning of all the metric values >0xFE00. You can pick a
single value (e.g. 0xFE01) and that would equally work for
your use case.
 >
 > Regards,
 > --Bruno
 >
 >
 >
 >
 >>
 >>>
 >>> I vaguely remember several years back we did indeed
implement something
 >>> (seriously no memory on details) that resulted in the
creation of a new
 >>> prefix reachability TLV with some experimental/local
sub-TLVs.  These
 >>> prefixes did not exist in the IS-IS domain beforehand.  I
have no idea
 >>> what the operational reality is on the existence of such
things, but I
 >>> know that /some/ code exists that does this.
 >>>
 >>> To boil this down into the core of the essence and be explicit,
 >>>
 >>> - you can create an IS-IS prefix reachability for some
arbitrary prefix,
 >>>     and stick > 0xfe00 into the metric, and that won't
have any effect
 >>>     on the existing IS-IS domain
 >>> - this has in fact been done to carry custom bits of
information that
 >>>     for one reason or another were decided to be
routing-related and thus
 >>>     make sense to put there
 >>> - the assumption for the use case is

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Acee Lindem (acee)]

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 use case this draft is targeting?

For many emails on LSR and beyond I got point from authors against using BGP 
for such signalling as "BGP may not be running there at all".

So if the draft works *only* with service provided by BGP let's please state it 
clearly in the document. This is not my current assumption.

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.

Thanks,
Acee


Many thx,
R.



On Thu, Nov 10, 2022 at 11:47 AM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Robert,

From: Robert Raszuk mailto:rob...@raszuk.net>>
Date: Thursday, November 10, 2022 at 9:41 AM
To: Peter Psenak 
mailto:40cisco@dmarc.ietf.org>>
Cc: Bruno Decraene 
mailto:bruno.decra...@orange.com>>, David Lamparter 
mailto:equi...@diac24.net>>, Acee Lindem 
mailto:a...@cisco.com>>, "lsr@ietf.org<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 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 disappear soon), endpoint CPU 
> load is 80%...) one

well, the question is whether it would not make sense to trigger UPA for
the above mentioned usages as well. Because eventually the destination
is becoming unreachable anyway and I would want my services to reroute
to alternate egress node. But seems like folks want to have a way to
differentiate, so I'm not going to argue against it.

I think You are right if there is a hierarchical service above it.

But consider flat routing - where there is no BGP service on top. Example - 
some DCs do use flat routing.

With that I am afraid UPA triggers may not work well (or at all) ... especially 
considering that they are history after the timeout irrespective of the remote 
prefix state.

But BGP service PIC is the use case this draft is targeting? For example, there 
is no intent to install negative routes throughout the domain.

Thanks,
Acee


Cheers,
R.








thanks,
Peter

> would need to use different metric values that would need to be at least 
> locally registered. So why not have the IANA register a flag and avoid each 
> network operator to do that job?
>
> In all cases, I don't see a reason for UPA to change the meaning of all the 
> metric values >0xFE00. You can pick a single value (e.g. 0xFE01) and 
> that would equally work for your use case.
>
> Regards,
> --Bruno
>
>
>
>
>>
>>>
>>> I vaguely remember several years back we did indeed implement something
>>> (seriously no memory on details) that resulted in the creation of a new
>>> prefix reachability TLV with some experimental/local sub-TLVs.  These
>>> prefixes did not exist in the IS-IS domain beforehand.  I have no idea
>>> what the operational reality is on the existence of such things, but I
>>> know that /some/ code exists that does this.
>>>
>>> To boil this down into the core of the essence and be explicit,
>>>
>>> - you can create an IS-IS prefix reachability for some arbitrary prefix,
>>> and stick > 0xfe00 into the metric, and that won't have any effect
>>> on the existing IS-IS domain
>>> - this has in fact been done to carry custom bits of information that
>>> for one reason or another were decided to be routing-related and thus
>>> make sense to put there
>>> - the assumption for the use case is that there are indeed less specific
>>> covering prefixes around, providing actual reachability
>>> - any setup doing that would now suddenly have fresh "unreachable"
>>> semantics attached to something that didn't have them before, which
>>> breaks things (or rather: prevents enabling/deployment of the UPA
>>> feature)
>>
>> and why that would be a problem? Such prefix would never be used to for
>> resolution of the BGP prefix. So the presence of such unreachable prefix
>> would never trigger any action even of the UPA processing was enabled on
>> th

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Aijun Wang]

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 more constrained for the network 
planning, network operations.

There are already amounts of solutions cannot be deployed widespread in the 
network.

Let’s take the explicit signaling approaches. 



Aijun Wang
China Telecom

> On Nov 10, 2022, at 10:41, Peter Psenak  
> wrote:
> 
> 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.(you can read again and again 
>> https://www.rfc-editor.org/rfc/rfc2328.html#page-157 
>> )
>> 2) What we aim to solve is that although the specific prefixes is not in the 
>> FIB, there is another summary address that cover it is in the FIB. Even in 
>> such situations, the specific prefixes is still unreachable.
>> Then, depend solely on 1) is not enough.
>> We must need one explicit information to signal 2).
>> There are so many experts within LSR state that your solution is not 
>> appropriate,  will bring much chaos into the network, you still insist your 
>> approach. Is this productive?
> 
> interesting that you, who hardly listen to these experts at all, are saying 
> that.
> 
> Peter
> 
> 
>> The final solution should be definitely in “Standard Track”, but not your 
>> approach.
>> The explicit signaling is the right direction.
>> Even the experts in LSR are confusing on your multiplex usage of 
>> “LSInfinity”, how to deploy it in the large scale network?
>> Please don’t let the operator struggle to explain such vague usages to its 
>> Network OPS, Network Planning team.
>> Aijun Wang
>> China Telecom
>>> 
 I wasn't clear on that in the first mail but Bruno clarified
 that this would still be inside a high-metric prefix reachability TLV.
 The only difference is that there is a flag/sub-TLV inside that triggers
 UPA behavior.  However, prefixes with > 0xfe00 metric *without*
 the UPA indicator MUST be ignored as they were before and MUST NOT
 trigger UPA/PIC.
>>> 
>>> for me flagging something that is unreachable with a unreachable flag is 
>>> redundant. But I let the WG to decide. That would obviously push the draft 
>>> to standard track trajectory.
>>> 
>>> Peter
>>> 
>>> 
 Cheers,
 -David
>>> 
>>> ___
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lsr
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Robert Raszuk]

> But BGP service PIC is the use case this draft is targeting?

For many emails on LSR and beyond I got point from authors against using
BGP for such signalling as "BGP may not be running there at all".

So if the draft works *only* with service provided by BGP let's please
state it clearly in the document. This is not my current assumption.

Many thx,
R.



On Thu, Nov 10, 2022 at 11:47 AM Acee Lindem (acee)  wrote:

> Hi Robert,
>
>
>
> *From: *Robert Raszuk 
> *Date: *Thursday, November 10, 2022 at 9:41 AM
> *To: *Peter Psenak 
> *Cc: *Bruno Decraene , 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 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 disappear soon), endpoint
> CPU load is 80%...) one
>
> well, the question is whether it would not make sense to trigger UPA for
> the above mentioned usages as well. Because eventually the destination
> is becoming unreachable anyway and I would want my services to reroute
> to alternate egress node. But seems like folks want to have a way to
> differentiate, so I'm not going to argue against it.
>
>
>
> I think You are right if there is a hierarchical service above it.
>
>
>
> But consider flat routing - where there is no BGP service on top. Example
> - some DCs do use flat routing.
>
>
>
> With that I am afraid UPA triggers may not work well (or at all) ...
> especially considering that they are history after the timeout irrespective
> of the remote prefix state.
>
>
>
> But BGP service PIC is the use case this draft is targeting? For example,
> there is no intent to install negative routes throughout the domain.
>
>
>
> Thanks,
> Acee
>
>
>
>
>
> Cheers,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> thanks,
> Peter
>
> > would need to use different metric values that would need to be at least
> locally registered. So why not have the IANA register a flag and avoid each
> network operator to do that job?
> >
> > In all cases, I don't see a reason for UPA to change the meaning of all
> the metric values >0xFE00. You can pick a single value (e.g.
> 0xFE01) and that would equally work for your use case.
> >
> > Regards,
> > --Bruno
> >
> >
> >
> >
> >>
> >>>
> >>> I vaguely remember several years back we did indeed implement something
> >>> (seriously no memory on details) that resulted in the creation of a new
> >>> prefix reachability TLV with some experimental/local sub-TLVs.  These
> >>> prefixes did not exist in the IS-IS domain beforehand.  I have no idea
> >>> what the operational reality is on the existence of such things, but I
> >>> know that /some/ code exists that does this.
> >>>
> >>> To boil this down into the core of the essence and be explicit,
> >>>
> >>> - you can create an IS-IS prefix reachability for some arbitrary
> prefix,
> >>> and stick > 0xfe00 into the metric, and that won't have any
> effect
> >>> on the existing IS-IS domain
> >>> - this has in fact been done to carry custom bits of information that
> >>> for one reason or another were decided to be routing-related and
> thus
> >>> make sense to put there
> >>> - the assumption for the use case is that there are indeed less
> specific
> >>> covering prefixes around, providing actual reachability
> >>> - any setup doing that would now suddenly have fresh "unreachable"
> >>> semantics attached to something that didn't have them before, which
> >>> breaks things (or rather: prevents enabling/deployment of the UPA
> >>> feature)
> >>
> >> and why that would be a problem? Such prefix would never be used to for
> >> resolution of the BGP prefix. So the presence of such unreachable prefix
> >> would never trigger any action even of the UPA processing was enabled on
> >> the receiver. I don't see a problem.
> >>
> >>> - (if those extra prefixes are created with 0x metric, a
> &g

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Acee Lindem (acee)]

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 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 disappear soon), endpoint CPU 
> load is 80%...) one

well, the question is whether it would not make sense to trigger UPA for
the above mentioned usages as well. Because eventually the destination
is becoming unreachable anyway and I would want my services to reroute
to alternate egress node. But seems like folks want to have a way to
differentiate, so I'm not going to argue against it.

I think You are right if there is a hierarchical service above it.

But consider flat routing - where there is no BGP service on top. Example - 
some DCs do use flat routing.

With that I am afraid UPA triggers may not work well (or at all) ... especially 
considering that they are history after the timeout irrespective of the remote 
prefix state.

But BGP service PIC is the use case this draft is targeting? For example, there 
is no intent to install negative routes throughout the domain.

Thanks,
Acee


Cheers,
R.








thanks,
Peter

> would need to use different metric values that would need to be at least 
> locally registered. So why not have the IANA register a flag and avoid each 
> network operator to do that job?
>
> In all cases, I don't see a reason for UPA to change the meaning of all the 
> metric values >0xFE00. You can pick a single value (e.g. 0xFE01) and 
> that would equally work for your use case.
>
> Regards,
> --Bruno
>
>
>
>
>>
>>>
>>> I vaguely remember several years back we did indeed implement something
>>> (seriously no memory on details) that resulted in the creation of a new
>>> prefix reachability TLV with some experimental/local sub-TLVs.  These
>>> prefixes did not exist in the IS-IS domain beforehand.  I have no idea
>>> what the operational reality is on the existence of such things, but I
>>> know that /some/ code exists that does this.
>>>
>>> To boil this down into the core of the essence and be explicit,
>>>
>>> - you can create an IS-IS prefix reachability for some arbitrary prefix,
>>> and stick > 0xfe00 into the metric, and that won't have any effect
>>> on the existing IS-IS domain
>>> - this has in fact been done to carry custom bits of information that
>>> for one reason or another were decided to be routing-related and thus
>>> make sense to put there
>>> - the assumption for the use case is that there are indeed less specific
>>> covering prefixes around, providing actual reachability
>>> - any setup doing that would now suddenly have fresh "unreachable"
>>> semantics attached to something that didn't have them before, which
>>> breaks things (or rather: prevents enabling/deployment of the UPA
>>> feature)
>>
>> and why that would be a problem? Such prefix would never be used to for
>> resolution of the BGP prefix. So the presence of such unreachable prefix
>> would never trigger any action even of the UPA processing was enabled on
>> the receiver. I don't see a problem.
>>
>>> - (if those extra prefixes are created with 0x metric, a
>>> configurable >= limit for UPA does not help either.)
>>
>> again, what is the problem?
>>
>>>
>>> Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
>>> (IMHO) not a significant cost, and completely eliminates this issue.
>>> The only reason against it (that I can think of) is that the
>>> advertisement might be a little bit larger;  a new sub-TLV or flag bit
>>> should be completely invisible to existing implementations (= I don't
>>> see how this would create compatibility or rollout problems.)
>>
>> I'm afraid, you forgot to consider an operational aspect of the solution.
>>
>> thanks,
>> Peter
>>
>>>
>>> Cheers,
>>>
>>>
>>> -David
>>>
>>
>
> Orange Restricted
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou p

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Peter Psenak]

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.(you can read again and again 
https://www.rfc-editor.org/rfc/rfc2328.html#page-157 
)


2) What we aim to solve is that although the specific prefixes is not in 
the FIB, there is another summary address that cover it is in the FIB. 
Even in such situations, the specific prefixes is still unreachable.


Then, depend solely on 1) is not enough.
We must need one explicit information to signal 2).

There are so many experts within LSR state that your solution is not 
appropriate,  will bring much chaos into the network, you still insist 
your approach. Is this productive?


interesting that you, who hardly listen to these experts at all, are 
saying that.


Peter




The final solution should be definitely in “Standard Track”, but not 
your approach.

The explicit signaling is the right direction.

Even the experts in LSR are confusing on your multiplex usage of 
“LSInfinity”, how to deploy it in the large scale network?


Please don’t let the operator struggle to explain such vague usages to 
its Network OPS, Network Planning team.


Aijun Wang
China Telecom



I wasn't clear on that in the first mail but Bruno clarified
that this would still be inside a high-metric prefix reachability TLV.
The only difference is that there is a flag/sub-TLV inside that triggers
UPA behavior.  However, prefixes with > 0xfe00 metric *without*
the UPA indicator MUST be ignored as they were before and MUST NOT
trigger UPA/PIC.


for me flagging something that is unreachable with a unreachable flag 
is redundant. But I let the WG to decide. That would obviously push 
the draft to standard track trajectory.


Peter



Cheers,
-David


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Robert Raszuk]

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 disappear soon), endpoint
> CPU load is 80%...) one
>
> well, the question is whether it would not make sense to trigger UPA for
> the above mentioned usages as well. Because eventually the destination
> is becoming unreachable anyway and I would want my services to reroute
> to alternate egress node. But seems like folks want to have a way to
> differentiate, so I'm not going to argue against it.
>

I think You are right if there is a hierarchical service above it.

But consider flat routing - where there is no BGP service on top. Example -
some DCs do use flat routing.

With that I am afraid UPA triggers may not work well (or at all) ...
especially considering that they are history after the timeout irrespective
of the remote prefix state.

Cheers,
R.








>
> thanks,
> Peter
>
> > would need to use different metric values that would need to be at least
> locally registered. So why not have the IANA register a flag and avoid each
> network operator to do that job?
> >
> > In all cases, I don't see a reason for UPA to change the meaning of all
> the metric values >0xFE00. You can pick a single value (e.g.
> 0xFE01) and that would equally work for your use case.
> >
> > Regards,
> > --Bruno
> >
> >
> >
> >
> >>
> >>>
> >>> I vaguely remember several years back we did indeed implement something
> >>> (seriously no memory on details) that resulted in the creation of a new
> >>> prefix reachability TLV with some experimental/local sub-TLVs.  These
> >>> prefixes did not exist in the IS-IS domain beforehand.  I have no idea
> >>> what the operational reality is on the existence of such things, but I
> >>> know that /some/ code exists that does this.
> >>>
> >>> To boil this down into the core of the essence and be explicit,
> >>>
> >>> - you can create an IS-IS prefix reachability for some arbitrary
> prefix,
> >>> and stick > 0xfe00 into the metric, and that won't have any
> effect
> >>> on the existing IS-IS domain
> >>> - this has in fact been done to carry custom bits of information that
> >>> for one reason or another were decided to be routing-related and
> thus
> >>> make sense to put there
> >>> - the assumption for the use case is that there are indeed less
> specific
> >>> covering prefixes around, providing actual reachability
> >>> - any setup doing that would now suddenly have fresh "unreachable"
> >>> semantics attached to something that didn't have them before, which
> >>> breaks things (or rather: prevents enabling/deployment of the UPA
> >>> feature)
> >>
> >> and why that would be a problem? Such prefix would never be used to for
> >> resolution of the BGP prefix. So the presence of such unreachable prefix
> >> would never trigger any action even of the UPA processing was enabled on
> >> the receiver. I don't see a problem.
> >>
> >>> - (if those extra prefixes are created with 0x metric, a
> >>> configurable >= limit for UPA does not help either.)
> >>
> >> again, what is the problem?
> >>
> >>>
> >>> Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
> >>> (IMHO) not a significant cost, and completely eliminates this issue.
> >>> The only reason against it (that I can think of) is that the
> >>> advertisement might be a little bit larger;  a new sub-TLV or flag bit
> >>> should be completely invisible to existing implementations (= I don't
> >>> see how this would create compatibility or rollout problems.)
> >>
> >> I'm afraid, you forgot to consider an operational aspect of the
> solution.
> >>
> >> thanks,
> >> Peter
> >>
> >>>
> >>> Cheers,
> >>>
> >>>
> >>> -David
> >>>
> >>
> >
> > Orange Restricted
> >
> >
> _
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> > Orange decline toute responsabilite si ce message a ete altere, deforme
> ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> > they should not be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
> > 

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Peter Psenak]

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 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 there would be any case
where you wouldn’t want to take this action for an unreachable prefix.


The problem is that a prefix with metric > 0xfe00 isn't actually an
unreachable prefix, it's a prefix that doesn't have specific routing
information associated with it, which in turn allows sticking other data
into it that might be routing-related but not quite a reachability.


well, that is your interpretation. For me a prefix with metric >
0xfe00 is unreachable. Implementations use the max-metric today to
signal the prefix unreachability - to avoid reaching
local/leaked/redistributed prefixes in cases where OL-bit is set on the
originator. So we are not doing anything new here really.


I'm a bit surprised since even draft-ppsenak-lsr-igp-ureach-prefix-announce 
seems to say the contrary:

Old nodes:
" Existing nodes in a network which receive UPA advertisements will
ignore them."

New nodes:
"As per the definitions referenced in the preceding section, any
prefix advertisement with a metric value greater than 0xFE00 can
be used for purposes other than normal routing calculations.  Such an
advertisement can be interpreted by the receiver as a UPA."

https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-ureach-prefix-announce-01#section-2.1

So draft seems to clearly state that the UPA is a new interpretation leading to 
a new behavior.

To me, the difference of opinions expressed on the list is the following:
a) draft-ppsenak-lsr-igp-ureach-prefix-announce is fine with the specific 
metric value being locally interpreted as UPA even though that's not a 
standard/global behavior
b) multiple other persons on the list have preference for an explicit signaling with a 
standardized meaning being "UPA"

I agree that "a" can be made to work, with a local interpretation through local 
config or new code.


thanks for admitting that.


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 disappear soon), endpoint CPU load is 80%...) one 


well, the question is whether it would not make sense to trigger UPA for 
the above mentioned usages as well. Because eventually the destination 
is becoming unreachable anyway and I would want my services to reroute 
to alternate egress node. But seems like folks want to have a way to 
differentiate, so I'm not going to argue against it.


thanks,
Peter


would need to use different metric values that would need to be at least 
locally registered. So why not have the IANA register a flag and avoid each 
network operator to do that job?

In all cases, I don't see a reason for UPA to change the meaning of all the metric 
values >0xFE00. You can pick a single value (e.g. 0xFE01) and that 
would equally work for your use case.

Regards,
--Bruno








I vaguely remember several years back we did indeed implement something
(seriously no memory on details) that resulted in the creation of a new
prefix reachability TLV with some experimental/local sub-TLVs.  These
prefixes did not exist in the IS-IS domain beforehand.  I have no idea
what the operational reality is on the existence of such things, but I
know that /some/ code exists that does this.

To boil this down into the core of the essence and be explicit,

- you can create an IS-IS prefix reachability for some arbitrary prefix,
and stick > 0xfe00 into the metric, and that won't have any effect
on the existing IS-IS domain
- this has in fact been done to carry custom bits of information that
for one reason or another were decided to be routing-related and thus
make sense to put there
- the assumption for the use case is that there are indeed less specific
covering prefixes around, providing actual reachability
- any setup doing that would now suddenly have fresh "unreachable"
semantics attached to something that didn't have them before, which
breaks things (or rather: prevents enabling/deployment of the UPA
feature)


and why that would be a problem? Such prefix would never be used to for
resolution of the BGP prefix. So the presence of such unreachable prefix
would never trigger any action even of the UPA processing was enabled on
the receiver. I don't see a problem.


- (if those extra prefixes are created with 0x metric, a
configurable >= 

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[bruno.decraene]

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 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 there would be any case
> >> where you wouldn’t want to take this action for an unreachable prefix.
> > 
> > The problem is that a prefix with metric > 0xfe00 isn't actually an
> > unreachable prefix, it's a prefix that doesn't have specific routing
> > information associated with it, which in turn allows sticking other data
> > into it that might be routing-related but not quite a reachability.
> 
> well, that is your interpretation. For me a prefix with metric > 
> 0xfe00 is unreachable. Implementations use the max-metric today to 
> signal the prefix unreachability - to avoid reaching 
> local/leaked/redistributed prefixes in cases where OL-bit is set on the 
> originator. So we are not doing anything new here really.

I'm a bit surprised since even draft-ppsenak-lsr-igp-ureach-prefix-announce 
seems to say the contrary:

Old nodes:
" Existing nodes in a network which receive UPA advertisements will
   ignore them."

New nodes:
"As per the definitions referenced in the preceding section, any
   prefix advertisement with a metric value greater than 0xFE00 can
   be used for purposes other than normal routing calculations.  Such an
   advertisement can be interpreted by the receiver as a UPA."

https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-ureach-prefix-announce-01#section-2.1

So draft seems to clearly state that the UPA is a new interpretation leading to 
a new behavior.

To me, the difference of opinions expressed on the list is the following:
a) draft-ppsenak-lsr-igp-ureach-prefix-announce is fine with the specific 
metric value being locally interpreted as UPA even though that's not a 
standard/global behavior
b) multiple other persons on the list have preference for an explicit signaling 
with a standardized meaning being "UPA"

I agree that "a" can be made to work, with a local interpretation through local 
config or new code.
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 disappear soon), endpoint CPU 
load is 80%...) one would need to use different metric values that would need 
to be at least locally registered. So why not have the IANA register a flag and 
avoid each network operator to do that job?

In all cases, I don't see a reason for UPA to change the meaning of all the 
metric values >0xFE00. You can pick a single value (e.g. 0xFE01) and 
that would equally work for your use case.

Regards,
--Bruno




> 
> > 
> > I vaguely remember several years back we did indeed implement something
> > (seriously no memory on details) that resulted in the creation of a new
> > prefix reachability TLV with some experimental/local sub-TLVs.  These
> > prefixes did not exist in the IS-IS domain beforehand.  I have no idea
> > what the operational reality is on the existence of such things, but I
> > know that /some/ code exists that does this.
> > 
> > To boil this down into the core of the essence and be explicit,
> > 
> > - you can create an IS-IS prefix reachability for some arbitrary prefix,
> >and stick > 0xfe00 into the metric, and that won't have any effect
> >on the existing IS-IS domain
> > - this has in fact been done to carry custom bits of information that
> >for one reason or another were decided to be routing-related and thus
> >make sense to put there
> > - the assumption for the use case is that there are indeed less specific
> >covering prefixes around, providing actual reachability
> > - any setup doing that would now suddenly have fresh "unreachable"
> >semantics attached to something that didn't have them before, which
> >breaks things (or rather: prevents enabling/deployment of the UPA
> >feature)
> 
> and why that would be a problem? Such prefix would never be used to for 
> resolution of the BGP prefix. So the presence of such unreachable prefix 
> would never trigger any action even of the UPA processing was enabled on 
> the receiver. I don't see a problem.
> 
> > - (if those extra prefixes are created with 0x metric, a
> >configurable >= limit for UPA does not help either.)
> 
> again, what is the problem?
> 
> > 
> > Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
> > (IMHO) not a significant cost, and completely eliminates this issue.
> > The only reason against it (that I can think of) is that the
> > 

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Robert Raszuk]

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 invalidation can be of different
length. So from this point of view what UPA suggests works just fine.

Your local implementation can trivially be able to handle such triggers for
invalidation.

I have my own reservations for UPA but I do not see how points you are
raising are of any real issues.

Kind regards,
R.









On Wed, Nov 9, 2022 at 10:51 PM 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.(you can read again and again
> https://www.rfc-editor.org/rfc/rfc2328.html#page-157)
>
> 2) What we aim to solve is that although the specific prefixes is not in
> the FIB, there is another summary address that cover it is in the FIB. Even
> in such situations, the specific prefixes is still unreachable.
>
> Then, depend solely on 1) is not enough.
> We must need one explicit information to signal 2).
>
> There are so many experts within LSR state that your solution is not
> appropriate,  will bring much chaos into the network, you still insist your
> approach. Is this productive?
>
> The final solution should be definitely in “Standard Track”, but not your
> approach.
> The explicit signaling is the right direction.
>
> Even the experts in LSR are confusing on your multiplex usage of
> “LSInfinity”, how to deploy it in the large scale network?
>
> Please don’t let the operator struggle to explain such vague usages to its
> Network OPS, Network Planning team.
>
> Aijun Wang
> China Telecom
>
>
> I wasn't clear on that in the first mail but Bruno clarified
>
> that this would still be inside a high-metric prefix reachability TLV.
>
> The only difference is that there is a flag/sub-TLV inside that triggers
>
> UPA behavior.  However, prefixes with > 0xfe00 metric *without*
>
> the UPA indicator MUST be ignored as they were before and MUST NOT
>
> trigger UPA/PIC.
>
>
> for me flagging something that is unreachable with a unreachable flag is
> redundant. But I let the WG to decide. That would obviously push the draft
> to standard track trajectory.
>
> Peter
>
>
> Cheers,
>
> -David
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Aijun Wang]

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.rfc-editor.org/rfc/rfc2328.html#page-157)

2) What we aim to solve is that although the specific prefixes is not in the 
FIB, there is another summary address that cover it is in the FIB. Even in such 
situations, the specific prefixes is still unreachable.

Then, depend solely on 1) is not enough.
We must need one explicit information to signal 2).

There are so many experts within LSR state that your solution is not 
appropriate,  will bring much chaos into the network, you still insist your 
approach. Is this productive?

The final solution should be definitely in “Standard Track”, but not your 
approach.
The explicit signaling is the right direction.

Even the experts in LSR are confusing on your multiplex usage of “LSInfinity”, 
how to deploy it in the large scale network?

Please don’t let the operator struggle to explain such vague usages to its 
Network OPS, Network Planning team.

Aijun Wang
China Telecom
> 
>> I wasn't clear on that in the first mail but Bruno clarified
>> that this would still be inside a high-metric prefix reachability TLV.
>> The only difference is that there is a flag/sub-TLV inside that triggers
>> UPA behavior.  However, prefixes with > 0xfe00 metric *without*
>> the UPA indicator MUST be ignored as they were before and MUST NOT
>> trigger UPA/PIC.
> 
> for me flagging something that is unreachable with a unreachable flag is 
> redundant. But I let the WG to decide. That would obviously push the draft to 
> standard track trajectory.
> 
> Peter
> 
> 
>> Cheers,
>> -David
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Peter Psenak]

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),


You keep saying things are "obvious"; they are not.  Why are you
assuming that my /128 is not in fact used as a BGP next-hop?

My /128 is a routing no-op right now.  The /64 is what gives the nexthop
reachability.  With your change, the /128 takes precedence as a more
specific unreachable.


well, if you have a service end-point that is advertised as /128 with
unreachable metric


metric > 0xfe00 is not "unreachable".  It's "no information".  You
have to continue in your SPF and use less specific prefixes if any are
available.  That's the entire point of this thread and/or the different
reading we have of 5305/5308.


if the "no information" results in unreachability, which is clear from 
the 5305/5308, we can use it to signal unreachability.


Anyway, we can keep arguing, but will hardly reach an agreement. The 
decision is on the WG.


What is important is that we will use the metric > 0xfe00 for 
signalling unreachability whether we add something on top of it or not.






and you expect your services to work, I would be very careful. We can
speculate whether that is something that is suppose to work or not,


As noted in an earlier mail, I'm not speaking speculatively.  Code
exists that does this.  The services work.  I have no information on how
common the pattern is, but I can positively affirm its existence.


well, I doubt such code has ever been deployed in production. And I can 
tell you it will likely break many implementations :)


Peter




[...]

If you introduce a new mechanism, routers not understanding the new
extension would still consider the prefix reachable.


... and routers not understanding the new extension will continue
blissfully ignoring the prefix, as they did before.  Why do you think
the prefix is suddenly considered reachable?  The prefix would still
have > 0xfe00 metric, is that the point of misunderstanding in this
thread?


you did not say that before, did you?


Bruno did, it's in a direct ancestor to this mail (parent to Acee's
mail); I assumed you had read it:

(I:)

I'd rather not do that and just add a sub-TLV for it.

(Bruno:)

I'm fine to use max_prefix as per RFC 5305 (prefix not considered during
SPF) as this allow for incremental deployment.
But in my opinion, advertising the unreachability semantic requires an
additional explicit signaling. (I'm proposing a prefix flag, but that seem
like a detail at this point)

(I:)

ACK


[...]

I wasn't clear on that in the first mail but Bruno clarified
that this would still be inside a high-metric prefix reachability TLV.
The only difference is that there is a flag/sub-TLV inside that triggers
UPA behavior.  However, prefixes with > 0xfe00 metric *without*
the UPA indicator MUST be ignored as they were before and MUST NOT
trigger UPA/PIC.


for me flagging something that is unreachable with a unreachable flag is
redundant. But I let the WG to decide. That would obviously push the
draft to standard track trajectory.


It would already need to be on standards track as it is, since it is
changing IS-IS behavior in an incompatible way.

Or, again, we need to errata 5305/5308.  The wording seems pretty clear
to me, but apparently the way I consider it to be clear in differs from
the way you consider it to be clear in.  That's the worst kind of
ambiguity, when the ambiguity itself is insidiously hidden... >
Sighing,


-David



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[David Lamparter]

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 are "obvious"; they are not.  Why are you
> > assuming that my /128 is not in fact used as a BGP next-hop?
> > 
> > My /128 is a routing no-op right now.  The /64 is what gives the nexthop
> > reachability.  With your change, the /128 takes precedence as a more
> > specific unreachable.
> 
> well, if you have a service end-point that is advertised as /128 with 
> unreachable metric

metric > 0xfe00 is not "unreachable".  It's "no information".  You
have to continue in your SPF and use less specific prefixes if any are
available.  That's the entire point of this thread and/or the different
reading we have of 5305/5308.

> and you expect your services to work, I would be very careful. We can
> speculate whether that is something that is suppose to work or not,

As noted in an earlier mail, I'm not speaking speculatively.  Code
exists that does this.  The services work.  I have no information on how
common the pattern is, but I can positively affirm its existence.

[...]
> >> If you introduce a new mechanism, routers not understanding the new
> >> extension would still consider the prefix reachable.
> > 
> > ... and routers not understanding the new extension will continue
> > blissfully ignoring the prefix, as they did before.  Why do you think
> > the prefix is suddenly considered reachable?  The prefix would still
> > have > 0xfe00 metric, is that the point of misunderstanding in this
> > thread?  
> 
> you did not say that before, did you?

Bruno did, it's in a direct ancestor to this mail (parent to Acee's
mail); I assumed you had read it:

(I:)
> > > I'd rather not do that and just add a sub-TLV for it.
(Bruno:)
> > I'm fine to use max_prefix as per RFC 5305 (prefix not considered during
> > SPF) as this allow for incremental deployment.
> > But in my opinion, advertising the unreachability semantic requires an
> > additional explicit signaling. (I'm proposing a prefix flag, but that seem
> > like a detail at this point)
(I:)
> ACK

[...]
> > I wasn't clear on that in the first mail but Bruno clarified
> > that this would still be inside a high-metric prefix reachability TLV.
> > The only difference is that there is a flag/sub-TLV inside that triggers
> > UPA behavior.  However, prefixes with > 0xfe00 metric *without*
> > the UPA indicator MUST be ignored as they were before and MUST NOT
> > trigger UPA/PIC.
> 
> for me flagging something that is unreachable with a unreachable flag is 
> redundant. But I let the WG to decide. That would obviously push the 
> draft to standard track trajectory.

It would already need to be on standards track as it is, since it is
changing IS-IS behavior in an incompatible way.

Or, again, we need to errata 5305/5308.  The wording seems pretty clear
to me, but apparently the way I consider it to be clear in differs from
the way you consider it to be clear in.  That's the worst kind of
ambiguity, when the ambiguity itself is insidiously hidden...

Sighing,


-David

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Peter Psenak]

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 of the BGP prefix.


Says who?  If I have an external BGP nexthop on a shared network (e.g.
IXP), my IS-IS may have a route for the IXP's IPv6 /64, and I may have
an additional /128 in IS-IS with 0x metric in IS-IS carrying
ancillary data.


as far as that /128 is not used as BGP next-hop (which obviously is not
the case),


You keep saying things are "obvious"; they are not.  Why are you
assuming that my /128 is not in fact used as a BGP next-hop?

My /128 is a routing no-op right now.  The /64 is what gives the nexthop
reachability.  With your change, the /128 takes precedence as a more
specific unreachable.


well, if you have a service end-point that is advertised as /128 with 
unreachable metric and you expect your services to work, I would be very 
careful. We can speculate whether that is something that is suppose to 
work or not, IMHO it is hardly something that we need to worry about.





UPA for such /128 is harmless.



The 5305/5308 text is - for me, quite clearly - saying this 0x
prefix I just arbitrarily stuck in there has no effect on routing
operation at all.  Now it suddenly does.


what is the difference you see? I see none.


The difference is that I already have a /128 with 0x metric in
my IS-IS domain, which with your draft enabled is now processed to tell
BGP that the nexthop is unreachable.  It didn't do that before.



the question is whether that matters or not, please see above.




Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
(IMHO) not a significant cost, and completely eliminates this issue.
The only reason against it (that I can think of) is that the
advertisement might be a little bit larger;  a new sub-TLV or flag bit
should be completely invisible to existing implementations (= I don't
see how this would create compatibility or rollout problems.)


I'm afraid, you forgot to consider an operational aspect of the solution.


Please elaborate what that operational aspect is?


metric > 0xfe00 will not result in prefix reachability on any
existing router.


It results in nothing, yes ...


If you introduce a new mechanism, routers not understanding the new
extension would still consider the prefix reachable.


... and routers not understanding the new extension will continue
blissfully ignoring the prefix, as they did before.  Why do you think
the prefix is suddenly considered reachable?  The prefix would still
have > 0xfe00 metric, is that the point of misunderstanding in this
thread?  


you did not say that before, did you?


I wasn't clear on that in the first mail but Bruno clarified
that this would still be inside a high-metric prefix reachability TLV.
The only difference is that there is a flag/sub-TLV inside that triggers
UPA behavior.  However, prefixes with > 0xfe00 metric *without*
the UPA indicator MUST be ignored as they were before and MUST NOT
trigger UPA/PIC.


for me flagging something that is unreachable with a unreachable flag is 
redundant. But I let the WG to decide. That would obviously push the 
draft to standard track trajectory.


Peter




Cheers,


-David



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[David Lamparter]

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 who?  If I have an external BGP nexthop on a shared network (e.g.
> > IXP), my IS-IS may have a route for the IXP's IPv6 /64, and I may have
> > an additional /128 in IS-IS with 0x metric in IS-IS carrying
> > ancillary data.
> 
> as far as that /128 is not used as BGP next-hop (which obviously is not 
> the case),

You keep saying things are "obvious"; they are not.  Why are you
assuming that my /128 is not in fact used as a BGP next-hop?

My /128 is a routing no-op right now.  The /64 is what gives the nexthop
reachability.  With your change, the /128 takes precedence as a more
specific unreachable.

> UPA for such /128 is harmless.
> 
> > 
> > The 5305/5308 text is - for me, quite clearly - saying this 0x
> > prefix I just arbitrarily stuck in there has no effect on routing
> > operation at all.  Now it suddenly does.
> 
> what is the difference you see? I see none.

The difference is that I already have a /128 with 0x metric in
my IS-IS domain, which with your draft enabled is now processed to tell
BGP that the nexthop is unreachable.  It didn't do that before.

> >>> Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
> >>> (IMHO) not a significant cost, and completely eliminates this issue.
> >>> The only reason against it (that I can think of) is that the
> >>> advertisement might be a little bit larger;  a new sub-TLV or flag bit
> >>> should be completely invisible to existing implementations (= I don't
> >>> see how this would create compatibility or rollout problems.)
> >>
> >> I'm afraid, you forgot to consider an operational aspect of the solution.
> > 
> > Please elaborate what that operational aspect is?
> 
> metric > 0xfe00 will not result in prefix reachability on any
> existing router.

It results in nothing, yes ...

> If you introduce a new mechanism, routers not understanding the new
> extension would still consider the prefix reachable.

... and routers not understanding the new extension will continue
blissfully ignoring the prefix, as they did before.  Why do you think
the prefix is suddenly considered reachable?  The prefix would still
have > 0xfe00 metric, is that the point of misunderstanding in this
thread?  I wasn't clear on that in the first mail but Bruno clarified
that this would still be inside a high-metric prefix reachability TLV.
The only difference is that there is a flag/sub-TLV inside that triggers
UPA behavior.  However, prefixes with > 0xfe00 metric *without*
the UPA indicator MUST be ignored as they were before and MUST NOT
trigger UPA/PIC.

Cheers,


-David

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Peter Psenak]

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
unreachable prefix, it's a prefix that doesn't have specific routing
information associated with it, which in turn allows sticking other data
into it that might be routing-related but not quite a reachability.


well, that is your interpretation. For me a prefix with metric >
0xfe00 is unreachable. Implementations use the max-metric today to
signal the prefix unreachability - to avoid reaching
local/leaked/redistributed prefixes in cases where OL-bit is set on the
originator. So we are not doing anything new here really.


That is my interpretation and our implementation.  If we are discovering
ambiguity in this, we seriously need to errata-fix it, as noted in my
original mail.  (And I'll happily fix our implementation too.)


- you can create an IS-IS prefix reachability for some arbitrary prefix,
and stick > 0xfe00 into the metric, and that won't have any effect
on the existing IS-IS domain

[...]

- any setup doing that would now suddenly have fresh "unreachable"
semantics attached to something that didn't have them before, which
breaks things (or rather: prevents enabling/deployment of the UPA
feature)


and why that would be a problem? Such prefix would never be used to for
resolution of the BGP prefix.


Says who?  If I have an external BGP nexthop on a shared network (e.g.
IXP), my IS-IS may have a route for the IXP's IPv6 /64, and I may have
an additional /128 in IS-IS with 0x metric in IS-IS carrying
ancillary data.


as far as that /128 is not used as BGP next-hop (which obviously is not 
the case), UPA for such /128 is harmless.




The 5305/5308 text is - for me, quite clearly - saying this 0x
prefix I just arbitrarily stuck in there has no effect on routing
operation at all.  Now it suddenly does.


what is the difference you see? I see none.





Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
(IMHO) not a significant cost, and completely eliminates this issue.
The only reason against it (that I can think of) is that the
advertisement might be a little bit larger;  a new sub-TLV or flag bit
should be completely invisible to existing implementations (= I don't
see how this would create compatibility or rollout problems.)


I'm afraid, you forgot to consider an operational aspect of the solution.


Please elaborate what that operational aspect is?


metric > 0xfe00 will not result in prefix reachability on any 
existing router. If you introduce a new mechanism, routers not 
understanding the new extension would still consider the prefix reachable.


thanks,
Peter


Thanks,


-David



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[David Lamparter]

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 doesn't have specific routing
> > information associated with it, which in turn allows sticking other data
> > into it that might be routing-related but not quite a reachability.
> 
> well, that is your interpretation. For me a prefix with metric > 
> 0xfe00 is unreachable. Implementations use the max-metric today to 
> signal the prefix unreachability - to avoid reaching 
> local/leaked/redistributed prefixes in cases where OL-bit is set on the 
> originator. So we are not doing anything new here really.

That is my interpretation and our implementation.  If we are discovering
ambiguity in this, we seriously need to errata-fix it, as noted in my
original mail.  (And I'll happily fix our implementation too.)

> > - you can create an IS-IS prefix reachability for some arbitrary prefix,
> >and stick > 0xfe00 into the metric, and that won't have any effect
> >on the existing IS-IS domain
[...]
> > - any setup doing that would now suddenly have fresh "unreachable"
> >semantics attached to something that didn't have them before, which
> >breaks things (or rather: prevents enabling/deployment of the UPA
> >feature)
> 
> and why that would be a problem? Such prefix would never be used to for 
> resolution of the BGP prefix.

Says who?  If I have an external BGP nexthop on a shared network (e.g.
IXP), my IS-IS may have a route for the IXP's IPv6 /64, and I may have
an additional /128 in IS-IS with 0x metric in IS-IS carrying
ancillary data.

The 5305/5308 text is - for me, quite clearly - saying this 0x
prefix I just arbitrarily stuck in there has no effect on routing
operation at all.  Now it suddenly does.

> > Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
> > (IMHO) not a significant cost, and completely eliminates this issue.
> > The only reason against it (that I can think of) is that the
> > advertisement might be a little bit larger;  a new sub-TLV or flag bit
> > should be completely invisible to existing implementations (= I don't
> > see how this would create compatibility or rollout problems.)
> 
> I'm afraid, you forgot to consider an operational aspect of the solution.

Please elaborate what that operational aspect is?

Thanks,


-David

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Peter Psenak]

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 (triggering BGP
PIC or other local action) , I can't see that there would be any case
where you wouldn’t want to take this action for an unreachable prefix.


The problem is that a prefix with metric > 0xfe00 isn't actually an
unreachable prefix, it's a prefix that doesn't have specific routing
information associated with it, which in turn allows sticking other data
into it that might be routing-related but not quite a reachability.


well, that is your interpretation. For me a prefix with metric > 
0xfe00 is unreachable. Implementations use the max-metric today to 
signal the prefix unreachability - to avoid reaching 
local/leaked/redistributed prefixes in cases where OL-bit is set on the 
originator. So we are not doing anything new here really.




I vaguely remember several years back we did indeed implement something
(seriously no memory on details) that resulted in the creation of a new
prefix reachability TLV with some experimental/local sub-TLVs.  These
prefixes did not exist in the IS-IS domain beforehand.  I have no idea
what the operational reality is on the existence of such things, but I
know that /some/ code exists that does this.

To boil this down into the core of the essence and be explicit,

- you can create an IS-IS prefix reachability for some arbitrary prefix,
   and stick > 0xfe00 into the metric, and that won't have any effect
   on the existing IS-IS domain
- this has in fact been done to carry custom bits of information that
   for one reason or another were decided to be routing-related and thus
   make sense to put there
- the assumption for the use case is that there are indeed less specific
   covering prefixes around, providing actual reachability
- any setup doing that would now suddenly have fresh "unreachable"
   semantics attached to something that didn't have them before, which
   breaks things (or rather: prevents enabling/deployment of the UPA
   feature)


and why that would be a problem? Such prefix would never be used to for 
resolution of the BGP prefix. So the presence of such unreachable prefix 
would never trigger any action even of the UPA processing was enabled on 
the receiver. I don't see a problem.



- (if those extra prefixes are created with 0x metric, a
   configurable >= limit for UPA does not help either.)


again, what is the problem?



Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
(IMHO) not a significant cost, and completely eliminates this issue.
The only reason against it (that I can think of) is that the
advertisement might be a little bit larger;  a new sub-TLV or flag bit
should be completely invisible to existing implementations (= I don't
see how this would create compatibility or rollout problems.)


I'm afraid, you forgot to consider an operational aspect of the solution.

thanks,
Peter



Cheers,


-David



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Peter Psenak]

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", the result will be that the prefix will become unreachable. I guess we 
can agree on that


Is NOT correct.

“the result will be that the specific prefix isn’t existing within the FIB, but 
not unreachable——-because there may be one less specific prefix covers it.”


and what exactly is the point? You can have a default route in your 
domain. Are you saying that in such case every destination is reachable? 
Obviously not.




Then, let’s stick on the original statements about the meaning of “LSInfinity”, 
no more explanations, no more confusion then.


we are not changing that in any way.

Peter



Aijun Wang
China Telecom


On Nov 9, 2022, at 12:06, Peter Psenak  
wrote:

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 metric larger
than MAX_V6_PATH_METRIC (0xFE00), this prefix MUST not be
considered during the normal Shortest Path First (SPF)
computation."
A prefix that is "not considered" is not an unreachable prefix.  It's a
prefix that is in the DB but ignored entirely, as if it wasn't there at
all.  A less specific prefix may cover it, and I would expect that to
work normally.


when a prefix is "not considered during the normal Shortest Path First (SPF) 
computation", the result will be that the prefix will become unreachable. I guess we 
can agree on that.

And I'm not sure what do you mean by "in the DB but ignored entirely". It will 
not be ignored, it will be maintained similarly in the DB as any other reachable prefix.


The UPA draft is changing this such that now some values may mean that
the prefix is in fact unreachable.  I'd rather not do that and just add
a sub-TLV for it.


We are not changing anything in terms of meaning of the prefix metric higher 
than 0xFE00 - and that is why this is backward compatible. If we would be 
changing the meaning of the metric it would not be.

Using a new Sub-TLV to signal unreachability makes the solution non backward 
compatible, and harder to deploy, for no good reason IMHO.

thanks,
Peter



(Alternatively, if I misunderstood 5305/5308 - I'm pretty sure I'm not
the only one to read it that way and that's a pretty important
errata?!?)
Cheers,
-David


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[David Lamparter]

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 action) , I can't see that there would be any case
> where you wouldn’t want to take this action for an unreachable prefix.

The problem is that a prefix with metric > 0xfe00 isn't actually an
unreachable prefix, it's a prefix that doesn't have specific routing
information associated with it, which in turn allows sticking other data
into it that might be routing-related but not quite a reachability.

I vaguely remember several years back we did indeed implement something
(seriously no memory on details) that resulted in the creation of a new
prefix reachability TLV with some experimental/local sub-TLVs.  These
prefixes did not exist in the IS-IS domain beforehand.  I have no idea
what the operational reality is on the existence of such things, but I
know that /some/ code exists that does this.

To boil this down into the core of the essence and be explicit,

- you can create an IS-IS prefix reachability for some arbitrary prefix,
  and stick > 0xfe00 into the metric, and that won't have any effect
  on the existing IS-IS domain
- this has in fact been done to carry custom bits of information that
  for one reason or another were decided to be routing-related and thus
  make sense to put there
- the assumption for the use case is that there are indeed less specific
  covering prefixes around, providing actual reachability
- any setup doing that would now suddenly have fresh "unreachable"
  semantics attached to something that didn't have them before, which
  breaks things (or rather: prevents enabling/deployment of the UPA
  feature)
- (if those extra prefixes are created with 0x metric, a
  configurable >= limit for UPA does not help either.)

Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
(IMHO) not a significant cost, and completely eliminates this issue.
The only reason against it (that I can think of) is that the
advertisement might be a little bit larger;  a new sub-TLV or flag bit
should be completely invisible to existing implementations (= I don't
see how this would create compatibility or rollout problems.)

Cheers,


-David

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Aijun Wang]

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 unreachability makes the solution non backward 
> compatible, and harder to deploy, for no good reason IMHO.
> 
> thanks,
> Peter
> 
> 
>> (Alternatively, if I misunderstood 5305/5308 - I'm pretty sure I'm not
>> the only one to read it that way and that's a pretty important
>> errata?!?)
>> Cheers,
>> -David
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Acee Lindem (acee)]

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 there would be any case where you wouldn’t want to 
take this action for an unreachable
prefix. 

Thanks,
Acee

On 11/9/22, 10:56 AM, "Lsr on behalf of bruno.decra...@orange.com" 
 wrote:

> 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,
> 
> ... "if a prefix is advertised with a metric larger
   > than MAX_V6_PATH_METRIC (0xFE00), this prefix MUST not be
   > considered during the normal Shortest Path First (SPF)
   > computation."
> 
> A prefix that is "not considered" is not an unreachable prefix.  It's a
> prefix that is in the DB but ignored entirely, as if it wasn't there at
> all.  A less specific prefix may cover it, and I would expect that to
> work normally.

+1

> The UPA draft is changing this such that now some values may mean that
> the prefix is in fact unreachable. 

+1


> 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 deployment.
But in my opinion, advertising the unreachability semantic requires an 
additional explicit signaling. (I'm proposing a prefix flag, but that seem like 
a detail at this point)

Thanks,
--Bruno

> 
> (Alternatively, if I misunderstood 5305/5308 - I'm pretty sure I'm not
> the only one to read it that way and that's a pretty important
> errata?!?)
> 
> Cheers,
> 
> 
> -David
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

Orange Restricted


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and 
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Aijun Wang]

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 unreachable. I 
> guess we can agree on that

Is NOT correct.

“the result will be that the specific prefix isn’t existing within the FIB, but 
not unreachable——-because there may be one less specific prefix covers it.”

Then, let’s stick on the original statements about the meaning of “LSInfinity”, 
no more explanations, no more confusion then.

Aijun Wang
China Telecom

> On Nov 9, 2022, at 12:06, Peter Psenak  
> wrote:
> 
> 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 metric larger
>>than MAX_V6_PATH_METRIC (0xFE00), this prefix MUST not be
>>considered during the normal Shortest Path First (SPF)
>>computation."
>> A prefix that is "not considered" is not an unreachable prefix.  It's a
>> prefix that is in the DB but ignored entirely, as if it wasn't there at
>> all.  A less specific prefix may cover it, and I would expect that to
>> work normally.
> 
> when a prefix is "not considered during the normal Shortest Path First (SPF) 
> computation", the result will be that the prefix will become unreachable. I 
> guess we can agree on that.
> 
> And I'm not sure what do you mean by "in the DB but ignored entirely". It 
> will not be ignored, it will be maintained similarly in the DB as any other 
> reachable prefix.
> 
>> The UPA draft is changing this such that now some values may mean that
>> the prefix is in fact unreachable.  I'd rather not do that and just add
>> a sub-TLV for it.
> 
> We are not changing anything in terms of meaning of the prefix metric higher 
> than 0xFE00 - and that is why this is backward compatible. If we would be 
> changing the meaning of the metric it would not be.
> 
> Using a new Sub-TLV to signal unreachability makes the solution non backward 
> compatible, and harder to deploy, for no good reason IMHO.
> 
> thanks,
> Peter
> 
> 
>> (Alternatively, if I misunderstood 5305/5308 - I'm pretty sure I'm not
>> the only one to read it that way and that's a pretty important
>> errata?!?)
>> Cheers,
>> -David
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Peter Psenak]

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 metric larger
than MAX_V6_PATH_METRIC (0xFE00), this prefix MUST not be
considered during the normal Shortest Path First (SPF)
computation."

A prefix that is "not considered" is not an unreachable prefix.  It's a
prefix that is in the DB but ignored entirely, as if it wasn't there at
all.  A less specific prefix may cover it, and I would expect that to
work normally.


when a prefix is "not considered during the normal Shortest Path First 
(SPF) computation", the result will be that the prefix will become 
unreachable. I guess we can agree on that.


And I'm not sure what do you mean by "in the DB but ignored entirely". 
It will not be ignored, it will be maintained similarly in the DB as any 
other reachable prefix.




The UPA draft is changing this such that now some values may mean that
the prefix is in fact unreachable.  I'd rather not do that and just add
a sub-TLV for it.


We are not changing anything in terms of meaning of the prefix metric 
higher than 0xFE00 - and that is why this is backward compatible. If 
we would be changing the meaning of the metric it would not be.


Using a new Sub-TLV to signal unreachability makes the solution non 
backward compatible, and harder to deploy, for no good reason IMHO.


thanks,
Peter




(Alternatively, if I misunderstood 5305/5308 - I'm pretty sure I'm not
the only one to read it that way and that's a pretty important
errata?!?)

Cheers,


-David



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[David Lamparter]

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 deployment.
> But in my opinion, advertising the unreachability semantic requires an
> additional explicit signaling. (I'm proposing a prefix flag, but that
> seem like a detail at this point)

ACK

(I was a bit muddy writing "sub-TLV", really meant just some type of
added explicit signal inside the max_prefix reachability.)


-David

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[bruno.decraene]

> 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,
> 
> ... "if a prefix is advertised with a metric larger
   > than MAX_V6_PATH_METRIC (0xFE00), this prefix MUST not be
   > considered during the normal Shortest Path First (SPF)
   > computation."
> 
> A prefix that is "not considered" is not an unreachable prefix.  It's a
> prefix that is in the DB but ignored entirely, as if it wasn't there at
> all.  A less specific prefix may cover it, and I would expect that to
> work normally.

+1
 
> The UPA draft is changing this such that now some values may mean that
> the prefix is in fact unreachable. 

+1


> 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 deployment.
But in my opinion, advertising the unreachability semantic requires an 
additional explicit signaling. (I'm proposing a prefix flag, but that seem like 
a detail at this point)

Thanks,
--Bruno

> 
> (Alternatively, if I misunderstood 5305/5308 - I'm pretty sure I'm not
> the only one to read it that way and that's a pretty important
> errata?!?)
> 
> Cheers,
> 
> 
> -David
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

Orange Restricted

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[David Lamparter]

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), this prefix MUST not be
   considered during the normal Shortest Path First (SPF)
   computation."

A prefix that is "not considered" is not an unreachable prefix.  It's a
prefix that is in the DB but ignored entirely, as if it wasn't there at
all.  A less specific prefix may cover it, and I would expect that to
work normally.

The UPA draft is changing this such that now some values may mean that
the prefix is in fact unreachable.  I'd rather not do that and just add
a sub-TLV for it.

(Alternatively, if I misunderstood 5305/5308 - I'm pretty sure I'm not
the only one to read it that way and that's a pretty important
errata?!?)

Cheers,


-David

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr