Re: [Lsr] RFC 8362 and LSInfinity

[Aijun Wang]

Hi, Acee, Peter and Ketan:

 

I propose we limit the usage of LSInfinity within the network. That is to say, 
we should depreciate its usages, not enhance it.

 

As defined in RFC2328, the sole purpose of LSInfinity is to let the receiver 
bypass the SPF calculation for the associated LSA:

a) In case the advertisement of LSA for some special aim.

b) Another is for the premature aging the LSA (which is not encouraged). 

There is few application for the a) usage until now, same situation for b) 
usage.

 

The reason for the above situations may be the definition within the RFC2328 is 
counterintuitivethe maximum value of the metric should be used for the last 
resort of the reachability, no other more meanings. Or else, it will complex 
the implementation and deployment, for example:

a) For OSPFv2, the LSInfinity is defined as 0xff

b) For IS-IS, the equivalent variable is MAX_PATH_METRIC, which is defined 
as 0xFE00

c) For OSPFv3, which value will you be defined, especially for the 
Intra-Area-Prefix? Considering the metric for the intra-area and inter-area are 
all 24-bit long?

d) And, for the metric in ”IP Algorithm Prefix Reachability” , 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-6.3, 
its length is again 32-bit, will you define another LSInfinity value later?

Won’t you think the above special rule complex the whole situation?

 

I think we should seek other methods to achieve the necessary goals.

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org  On Behalf Of Acee Lindem 
(acee)
Sent: Saturday, October 8, 2022 4:03 AM
To: Ketan Talaulikar ; Peter Psenak 

Cc: lsr@ietf.org
Subject: Re: [Lsr] RFC 8362 and LSInfinity

 

Hi Peter, Ketan, 

 

We’ll do another WG last call on the updated IP Flex Algo document and it will 
update RFC 8362. As you probably surmised, this is useful for OSPFv3 IP Flex 
Algorithm when you want don’t want to use the prefix with the base algorithm. 

 

From: Lsr mailto:lsr-boun...@ietf.org> > on behalf of 
Ketan Talaulikar mailto:ketant.i...@gmail.com> >
Date: Thursday, October 6, 2022 at 3:35 AM
To: Peter Psenak mailto:ppsenak=40cisco@dmarc.ietf.org> >
Cc: "lsr@ietf.org  " mailto:lsr@ietf.org> >
Subject: Re: [Lsr] RFC 8362 and LSInfinity

 

Hi Peter,

 

I support this "update" - not sure if it qualifies as a "clarification". Also, 
this obviously is doable only when the network has migrated to use only 
Extended LSAs (i.e., legacy LSAs are removed) as indicated in 
https://www.rfc-editor.org/rfc/rfc8362.html#section-6.1

 

In sparse-mode, the legacy LSAs are used. So if you want a prefix to be 
unreachable with the base algorithm, simply omit it from the legacy 
Intra-Area-Prefix LSA. 

 

Thanks,
Acee

 

Thanks,

Ketan

 

 

On Wed, Oct 5, 2022 at 3:01 PM Peter Psenak mailto:40cisco@dmarc.ietf.org> > wrote:

Hi Folks,

metric of LSInfinity (0xFF) has been defined in RFC2328:

LSInfinity
 The metric value indicating that the destination described by an
 LSA is unreachable. Used in summary-LSAs and AS-external-LSAs as
 an alternative to premature aging (see Section 14.1). It is
 defined to be the 24-bit binary value of all ones: 0xff.

RFC5340 inherited it from RFC2328:

Appendix B.  Architectural Constants

Architectural constants for the OSPF protocol are defined in Appendix
B of [OSPFV2].  The only difference for OSPF for IPv6 is that
DefaultDestination is encoded as a prefix with length 0 (see
Appendix A.4.1).

Both RFC2328 and RFC5340 used 16 bits metric for intra-area prefix 
reachability, so the LSInfinity was not applicable for intra-area prefixes.

RFC8362 defines 24-bit metric for all prefix reachability TLVs -
Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, External-Prefix TLV.
Although it is silent about the LSInfinity as such, it is assumed that 
such metric means unreachability for Inter-Area-Prefix TLV and 
External-Prefix TLV. Given that Intra-Area-Prefix TLV now has 24 bits 
metric as well, it would make sense to define the LSInfinity as 
unreachable for Intra-Area-Prefix TLV as well.

Would anyone object such a clarification in RFC8362?

thanks,
Peter

___
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] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Christian Hopps]

Christian Hopps  writes:

I simply turned your question around and asked: should conforming



implementations be penalized?


[LES:] Are you claiming that the absence of an explicit statement
regarding support of MP for a given TLV  is equivalent to a
prohibition against sending them (which fails basic logic)?


Why did we explicitly define multi-part TLVs?

I agree we appear to not making any progress here. Perhaps it would be more 
productive to have a discussion in a different forum like an interim or 
something similar.

Thanks,
Chris.
[as wg-chair]


Gah, I meant "as wg-member"! However, the suggestion of a different forum could 
probably come from the chair hat as well. :)

Thanks,
Chris.

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

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Christian Hopps]

"Les Ginsberg (ginsberg)"  writes:


Chris -



I am a bit concerned that this is degenerating into a
non-constructive argument. We can disagee but hopefully each post
helps move the discussion along in some way.

Please see inline.




-Original Message-



From: Christian Hopps 



Sent: Saturday, October 8, 2022 2:48 PM



To: Les Ginsberg (ginsberg) 



Cc: Christian Hopps ; Tony Li ;

Peter


Psenak (ppsenak) ; Robert Raszuk



; Henk Smit ; lsr@ietf.org



Subject: Re: [Lsr] New Version Notification for

draft-pkaneria-lsr-multi-tlv-


01.txt











I simply turned your question around and asked: should conforming



implementations be penalized?




[LES:] Are you claiming that the absence of an explicit statement
regarding support of MP for a given TLV  is equivalent to a
prohibition against sending them (which fails basic logic)?


Why did we explicitly define multi-part TLVs?

I agree we appear to not making any progress here. Perhaps it would be more 
productive to have a discussion in a different forum like an interim or 
something similar.

Thanks,
Chris.
[as wg-chair]


If not, I do not understand what it is that you think implementations
which are NOT supporting MP for a given TLV are conforming to.








I can't imagine why you are explaining IS-IS TLVs to me, and I have

never


advocated for nor even mentioned changing the encoding of TLVs so I

don't


know what you're talking about with the rest of it. I found this

very


distracting.








[LES:] A couple of quotes from previous emails you have sent:





... I think a stronger case might be made for actually having the
router capability be used *operationally* (i.e., if you don't see the
capability advertised then that router in fact doesn't send multi-tlv
tlvs and they should be seen as replacements of each other)...





This proposes making it illegal to send MP-TLVs unless a capability
is advertised network-wide.





If things would have been done correctly (i.e., documented) we also
would have had the option to add a sub-tlv to the TLVs in question
that indicated they were part of a set rather than replacements.





This proposes adding a sub-TLV into existing TLVs to indicate they
are part of a set of MP-TLVs.



??



   Les






Chris.



[as wg-member]







"Les Ginsberg (ginsberg)"  writes:







> Chris -



>



> There are two different topics under discussion - one has to do

with TLV


encoding - the other has to do with partial deployment issues. We

need to


be careful that we keep the two distinct.



>



> TLVs necessarily have to unambiguously define the object followed

by


attributes of that object.



> If multiple TLVs are required to advertise all the attributes of

an object, the


encoding requirements are the same: unambiguously define the object

in


each TLV and then include attributes.



> IS-IS advertisements have never had any "ordering' requirements

i.e.,


attributes can be advertised in any order within a given TLV and it

makes no


difference whether a TLV is advertised in LSP#2 or LSP#200.



> This means that when MP is used, there is no notion as to whether

a TLV is


the first in a set or the last in a set - they are simply

complementary.


>



> When I say that implementations which have added support for

MP-TLVs


for



> neighbor/prefix advertisement have done the "right thing" I am

simply


saying



> they are using base protocol encoding rules as discussed above.



>



> There is another discussion that has to do with partial

deployment issues


and



> legitimate concerns about how a network might behave when not all



routers



> support MP for a given TLV. But altering TLV encoding to address

that issue


does



> not solve a problem - it simply creates a new one.



> Further, introducing a new rule that prohibits advertisement of

existing


TLVs



> unless some yet to be defined feature support advertisement is

present


> network-wide also does not solve a problem - it introduces a new

one.


>



> Whether advertising features supported is useful and how it

should be


done is a discussion that should continue - but it MUST NOT alter

the format


of TLVs or the rules as to when TLVs can be advertised.



>



>Les



>



>> -Original Message-



>> From: Lsr  On Behalf Of Christian Hopps



>> Sent: Friday, October 7, 2022 4:17 PM



>> To: Les Ginsberg (ginsberg) 



>> Cc: Tony Li ; Christian Hopps <

cho...@chopps.org>;


Peter



>> Psenak (ppsenak) ; Robert Raszuk



>> ; Henk Smit ;

lsr@ietf.org


>> Subject: Re: [Lsr] New Version Notification for

draft-pkaneria-lsr-multi-tlv-


>> 01.txt



>>



>>



>> "Les Ginsberg (ginsberg)"  writes:



>>



>> > Tony -



>> >



>> >



>> >>



>> >> Your summarization is incorrect.



>> >>



>> >> The proposal is to advertise a advisory message that

indicates that a


node



>> is



>> >> ready to receive MP-TLVs. It prohibits nothing.



>> >



>> > [LES:] 

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Les Ginsberg (ginsberg)]

Chris -



I am a bit concerned that this is degenerating into a non-constructive 
argument. We can disagee but hopefully each post helps move the discussion 
along in some way.

Please see inline.



> -Original Message-

> From: Christian Hopps 

> Sent: Saturday, October 8, 2022 2:48 PM

> To: Les Ginsberg (ginsberg) 

> Cc: Christian Hopps ; Tony Li ; Peter

> Psenak (ppsenak) ; Robert Raszuk

> ; Henk Smit ; lsr@ietf.org

> Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-

> 01.txt

>

>

> I simply turned your question around and asked: should conforming

> implementations be penalized?



[LES:] Are you claiming that the absence of an explicit statement regarding 
support of MP for a given TLV  is equivalent to a prohibition against sending 
them (which fails basic logic)?

If not, I do not understand what it is that you think implementations which are 
NOT supporting MP for a given TLV are conforming to.



>

> I can't imagine why you are explaining IS-IS TLVs to me, and I have never

> advocated for nor even mentioned changing the encoding of TLVs so I don't

> know what you're talking about with the rest of it. I found this very

> distracting.

>



[LES:] A couple of quotes from previous emails you have sent:





... I think a stronger case might be made for actually having the router 
capability be used *operationally* (i.e., if you don't see the capability 
advertised then that router in fact doesn't send multi-tlv tlvs and they should 
be seen as replacements of each other)...





This proposes making it illegal to send MP-TLVs unless a capability is 
advertised network-wide.





If things would have been done correctly (i.e., documented) we also would have 
had the option to add a sub-tlv to the TLVs in question that indicated they 
were part of a set rather than replacements.





This proposes adding a sub-TLV into existing TLVs to indicate they are part of 
a set of MP-TLVs.



??



   Les





> Chris.

> [as wg-member]

>

> "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>> 
> writes:

>

> > Chris -

> >

> > There are two different topics under discussion - one has to do with TLV

> encoding - the other has to do with partial deployment issues. We need to

> be careful that we keep the two distinct.

> >

> > TLVs necessarily have to unambiguously define the object followed by

> attributes of that object.

> > If multiple TLVs are required to advertise all the attributes of an object, 
> > the

> encoding requirements are the same: unambiguously define the object in

> each TLV and then include attributes.

> > IS-IS advertisements have never had any "ordering' requirements i.e.,

> attributes can be advertised in any order within a given TLV and it makes no

> difference whether a TLV is advertised in LSP#2 or LSP#200.

> > This means that when MP is used, there is no notion as to whether a TLV is

> the first in a set or the last in a set - they are simply complementary.

> >

> > When I say that implementations which have added support for MP-TLVs

> for

> > neighbor/prefix advertisement have done the "right thing" I am simply

> saying

> > they are using base protocol encoding rules as discussed above.

> >

> > There is another discussion that has to do with partial deployment issues

> and

> > legitimate concerns about how a network might behave when not all

> routers

> > support MP for a given TLV. But altering TLV encoding to address that issue

> does

> > not solve a problem - it simply creates a new one.

> > Further, introducing a new rule that prohibits advertisement of existing

> TLVs

> > unless some yet to be defined feature support advertisement is present

> > network-wide also does not solve a problem - it introduces a new one.

> >

> > Whether advertising features supported is useful and how it should be

> done is a discussion that should continue - but it MUST NOT alter the format

> of TLVs or the rules as to when TLVs can be advertised.

> >

> >Les

> >

> >> -Original Message-

> >> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
> >> Christian Hopps

> >> Sent: Friday, October 7, 2022 4:17 PM

> >> To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>

> >> Cc: Tony Li mailto:tony...@tony.li>>; Christian Hopps 
> >> mailto:cho...@chopps.org>>;

> Peter

> >> Psenak (ppsenak) mailto:ppse...@cisco.com>>; Robert 
> >> Raszuk

> >> mailto:rob...@raszuk.net>>; Henk Smit 
> >> mailto:henk.i...@xs4all.nl>>; 
> >> lsr@ietf.org

> >> Subject: Re: [Lsr] New Version Notification for 
> >> draft-pkaneria-lsr-multi-tlv-

> >> 01.txt

> >>

> >>

> >> "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>> 
> >> writes:

> >>

> >> > Tony -

> >> >

> >> >

> >> >>

> >> >> Your summarization is incorrect.

> >> >>

> >> >> The proposal is to advertise a advisory message that indicates that a

> node

> >> is

> >> >> ready to receive MP-TLVs. It prohibits nothing.

> >> >

> >> 

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Christian Hopps]

I simply turned your question around and asked: should conforming 
implementations be penalized?

I can't imagine why you are explaining IS-IS TLVs to me, and I have never 
advocated for nor even mentioned changing the encoding of TLVs so I don't know 
what you're talking about with the rest of it. I found this very distracting.

Chris.
[as wg-member]

"Les Ginsberg (ginsberg)"  writes:


Chris -

There are two different topics under discussion - one has to do with TLV 
encoding - the other has to do with partial deployment issues. We need to be 
careful that we keep the two distinct.

TLVs necessarily have to unambiguously define the object followed by attributes 
of that object.
If multiple TLVs are required to advertise all the attributes of an object, the 
encoding requirements are the same: unambiguously define the object in each TLV 
and then include attributes.
IS-IS advertisements have never had any "ordering' requirements i.e., 
attributes can be advertised in any order within a given TLV and it makes no 
difference whether a TLV is advertised in LSP#2 or LSP#200.
This means that when MP is used, there is no notion as to whether a TLV is the 
first in a set or the last in a set - they are simply complementary.

When I say that implementations which have added support for MP-TLVs for
neighbor/prefix advertisement have done the "right thing" I am simply saying
they are using base protocol encoding rules as discussed above.

There is another discussion that has to do with partial deployment issues and
legitimate concerns about how a network might behave when not all routers
support MP for a given TLV. But altering TLV encoding to address that issue does
not solve a problem - it simply creates a new one.
Further, introducing a new rule that prohibits advertisement of existing TLVs
unless some yet to be defined feature support advertisement is present
network-wide also does not solve a problem - it introduces a new one.

Whether advertising features supported is useful and how it should be done is a 
discussion that should continue - but it MUST NOT alter the format of TLVs or 
the rules as to when TLVs can be advertised.

   Les


-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: Friday, October 7, 2022 4:17 PM
To: Les Ginsberg (ginsberg) 
Cc: Tony Li ; Christian Hopps ; Peter
Psenak (ppsenak) ; Robert Raszuk
; Henk Smit ; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-
01.txt


"Les Ginsberg (ginsberg)"  writes:

> Tony -
>
>
>>
>> Your summarization is incorrect.
>>
>> The proposal is to advertise a advisory message that indicates that a node
is
>> ready to receive MP-TLVs. It prohibits nothing.
>
> [LES:] That is what you are proposing - but others in the thread have
proposed other ideas. For example, in an earlier post Chris stated:
>
>>> Once we have this info I think a stronger case might be made for actually
>>> having the router capability be used *operationally* (i.e., if you don't
see the
>>> capability advertised then that router in fact doesn't send multi-tlv tlvs
and
>>> they should be seen as replacements of each other),
>
> What I am trying to highlight is that the existing implementations of MP-
TLVs
> for the "implicit" cases should not be penalized for sending MP-TLVs that
are
> encoded consistent with how MP-TLVs for the "explicit" cases have been
done.
> They are actually doing the right thing.

And I disagree with the word "right" here. They are doing the advantageous
thing as long as one has the correct routers and software that allows you to
advertise more than fits in a single TLV. It certainly won't be the "right" 
thing
if a standards conforming implementation out there doesn't expect or deal
with one of these multi-part "implicit MP-TLV" advertisements.

Are you saying implementations that only handle a single-part TLV are non-
conforming? To turn your question around, why should they be penalized?

Thanks,
Chris.

>
> If we are in agreement on that - great!
>
>Les
>
>>
>> Tony
>>


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

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Les Ginsberg (ginsberg)]

Chris -

There are two different topics under discussion - one has to do with TLV 
encoding - the other has to do with partial deployment issues. We need to be 
careful that we keep the two distinct.

TLVs necessarily have to unambiguously define the object followed by attributes 
of that object.
If multiple TLVs are required to advertise all the attributes of an object, the 
encoding requirements are the same: unambiguously define the object in each TLV 
and then include attributes.
IS-IS advertisements have never had any "ordering' requirements i.e., 
attributes can be advertised in any order within a given TLV and it makes no 
difference whether a TLV is advertised in LSP#2 or LSP#200.
This means that when MP is used, there is no notion as to whether a TLV is the 
first in a set or the last in a set - they are simply complementary.

When I say that implementations which have added support for MP-TLVs for 
neighbor/prefix advertisement have done the "right thing" I am simply saying 
they are using base protocol encoding rules as discussed above.

There is another discussion that has to do with partial deployment issues and 
legitimate concerns about how a network might behave when not all routers 
support MP for a given TLV. But altering TLV encoding to address that issue 
does not solve a problem - it simply creates a new one.
Further, introducing a new rule that prohibits advertisement of existing TLVs 
unless some yet to be defined feature support advertisement is present 
network-wide also does not solve a problem - it introduces a new one.

Whether advertising features supported is useful and how it should be done is a 
discussion that should continue - but it MUST NOT alter the format of TLVs or 
the rules as to when TLVs can be advertised.

   Les

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Friday, October 7, 2022 4:17 PM
> To: Les Ginsberg (ginsberg) 
> Cc: Tony Li ; Christian Hopps ; Peter
> Psenak (ppsenak) ; Robert Raszuk
> ; Henk Smit ; lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-
> 01.txt
> 
> 
> "Les Ginsberg (ginsberg)"  writes:
> 
> > Tony -
> >
> >
> >>
> >> Your summarization is incorrect.
> >>
> >> The proposal is to advertise a advisory message that indicates that a node
> is
> >> ready to receive MP-TLVs. It prohibits nothing.
> >
> > [LES:] That is what you are proposing - but others in the thread have
> proposed other ideas. For example, in an earlier post Chris stated:
> >
> >>> Once we have this info I think a stronger case might be made for actually
> >>> having the router capability be used *operationally* (i.e., if you don't
> see the
> >>> capability advertised then that router in fact doesn't send multi-tlv tlvs
> and
> >>> they should be seen as replacements of each other),
> >
> > What I am trying to highlight is that the existing implementations of MP-
> TLVs
> > for the "implicit" cases should not be penalized for sending MP-TLVs that
> are
> > encoded consistent with how MP-TLVs for the "explicit" cases have been
> done.
> > They are actually doing the right thing.
> 
> And I disagree with the word "right" here. They are doing the advantageous
> thing as long as one has the correct routers and software that allows you to
> advertise more than fits in a single TLV. It certainly won't be the "right" 
> thing
> if a standards conforming implementation out there doesn't expect or deal
> with one of these multi-part "implicit MP-TLV" advertisements.
> 
> Are you saying implementations that only handle a single-part TLV are non-
> conforming? To turn your question around, why should they be penalized?
> 
> Thanks,
> Chris.
> 
> >
> > If we are in agreement on that - great!
> >
> >Les
> >
> >>
> >> Tony
> >>

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