Hi Aijun,
On 10/12/22, 9:58 AM, "Aijun Wang" <[email protected]> wrote:
Hi, Acee:
Let me give you one more concrete example:
The metric of one prefix P is set to 0xFFFFFE(not LSInfinity, it can also
be other large value), and this prefix is attached at one router that has the
link cost 1 to ABR, what the value for the ABR to advertise for this Prefixes P
into other attached area as one summary prefix?
It's obvious you wouldn’t configure metrics that large unless you were trying
to accomplish some prefix reachability scoping (which I wouldn't recommend by
the way).
Acee
Aijun Wang
China Telecom
> On Oct 12, 2022, at 18:22, Acee Lindem (acee)
<[email protected]> wrote:
>
>
>
> On 10/12/22, 2:31 AM, "Lsr on behalf of Aijun Wang" <[email protected]
on behalf of [email protected]> wrote:
>
> Hi, Acee:
>
> Let me state some points more clearly:
> 1) The LSInfinity is defined almost 30 years, but it is not
applied/deployed within the network about 30 years, why to deprecate it?
> 2) RFC8362 say nothing about LSInifinity, only RFC5340 says it
inherits the definition from RFC2328.
> 3) It is problematic to define again the LSInifinity within RFC8362,
as the value of 0xffffff, because the metric of the normal summary prefixes
advertised by ABR may reach this predefined value.
>
> This is not problematic. Only unreachable prefixes for an algorithm will
have a metric of LSInfinity and will, hence, be unreachable and will not
contribute to the cost of any summary prefixes.
>
> Thanks,
> Acee
>
> The most important point is that there is reasonable/sound reason to
define such value for its special handling.
>
> Best Regards
>
> Aijun Wang
> China Telecom
>
>
> -----Original Message-----
> From: [email protected] <[email protected]> On Behalf Of Acee
Lindem (acee)
> Sent: Tuesday, October 11, 2022 11:20 PM
> To: Peter Psenak (ppsenak) <[email protected]>; Aijun Wang
<[email protected]>; 'Ketan Talaulikar' <[email protected]>
> Cc: [email protected]
> Subject: Re: [Lsr] RFC 8362 and LSInfinity
>
> Hi Aijun,
>
> After almost 30 years, we're not going to deprecate OSPF LSInfinity
based on your opinion.
>
> Please be specific as to what you feel is problematic with usage in
the 24-bit metric in the E-Intra-Area-Prefix LSA.
>
> Thanks,
> Acee
>
> On 10/11/22, 12:09 AM, "Peter Psenak" <[email protected]> wrote:
>
> Aijun,
>
>> On 11/10/2022 05:44, Aijun Wang wrote:
>> Hi, Peter:
>>
>> Let's focus on OSPF itself then.
>>
>> In OSPFv2(RFC2328) and OSPFv3(RFC5340), the metric length for the link
or intra-area prefix is 16 bit; but the metric length for the summary
LSA/inter-area is 24bit.
>> There will be no problem to define the LSInfinity for the summary LSA as
0xFFFFFF( although the usages of such definition is doubtful and should be
revaluated----for example, is there any real deployment for the mentioned
possible usages?)
>>
>> But for OSPFv3(RFC8362), if you still define the LSInifiity as 0xFFFFFF,
there is possible the cost to some prefixes advertised by the ABR reach this
value, it is unreasonable to consider such prefixes are unreachable. Then,
rely on such value of the metric to determine the reachability is problematic.
>
> again, there is no problem. For RFC8362 0xFFFFFF already means
> LSInfinity for inter/external prefixes. All we propose is to
define the
> same meaning for that metric for intra-area prefixes as it is 24
bits as
> well.
>
> Peter
>
>>
>> We should decrease or abandon such unsound reliance.
>>
>> It is easy for the device to implement such special treatment, it is
difficult and complex for the operator to run the network based on such special
treatment.
>>
>>
>> Best Regards
>>
>> Aijun Wang
>> China Telecom
>>
>> -----Original Message-----
>> From: [email protected] <[email protected]> On Behalf Of Peter
Psenak
>> Sent: Monday, October 10, 2022 3:56 PM
>> To: Aijun Wang <[email protected]>; 'Acee Lindem (acee)'
<[email protected]>; 'Ketan Talaulikar' <[email protected]>;
'Peter Psenak' <[email protected]>
>> Cc: [email protected]
>> Subject: Re: [Lsr] RFC 8362 and LSInfinity
>>
>> Aijun,
>>
>>> On 09/10/2022 07:44, Aijun Wang wrote:
>>> 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.
>>
>> definition of LSInfinity is very exact - it means unreachability.
>>
>>>
>>> The reason for the above situations may be the definition within the
>>> RFC2328 is counterintuitive----the 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 0xffffff
>>>
>>> b)For IS-IS, the equivalent variable is MAX_PATH_METRIC, which is
>>> defined as 0xFE000000
>>
>> you are comparing apples to oranges. These are two different protocols.
>>
>>>
>>> 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?
>>
>> OSPFv3 inherits all the constants defined for OSPFv2, it's explicitly
mentioned in the OSPFv3 RFC. And LSInfinity is 24 bits 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
<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?
>>
>> 0xFFFFFFFF seems like a good candidate for the unreachable metric for
the IP flex-algo.
>>
>>>
>>> Won’t you think the above special rule complex the whole situation?
>>
>> not at all.
>>
>>>
>>> I think we should seek other methods to achieve the necessary goals.
>>
>> I do not see a problem
>>
>> thanks,
>> Peter
>>>
>>> Best Regards
>>>
>>> Aijun Wang
>>>
>>> China Telecom
>>>
>>> *From:* [email protected] <[email protected]> *On Behalf Of
>>> *Acee Lindem (acee)
>>> *Sent:* Saturday, October 8, 2022 4:03 AM
>>> *To:* Ketan Talaulikar <[email protected]>; Peter Psenak
>>> <[email protected]>
>>> *Cc:* [email protected]
>>> *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 <[email protected] <mailto:[email protected]>> on
>>> behalf of Ketan Talaulikar <[email protected]
>>> <mailto:[email protected]>>
>>> *Date: *Thursday, October 6, 2022 at 3:35 AM
>>> *To: *Peter Psenak <[email protected]
>>> <mailto:[email protected]>>
>>> *Cc: *"[email protected] <mailto:[email protected]>" <[email protected]
>>> <mailto:[email protected]>>
>>> *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
>>> <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
>>> <[email protected]
>>> <mailto:[email protected]>>
>>> wrote:
>>>
>>> Hi Folks,
>>>
>>> metric of LSInfinity (0xFFFFFF) 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:
0xffffff.
>>>
>>> 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
>>> [email protected] <mailto:[email protected]>
>>> https://www.ietf.org/mailman/listinfo/lsr
>>> <https://www.ietf.org/mailman/listinfo/lsr>
>>>
>>
>> _______________________________________________
>> Lsr mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>>
>
>
> _______________________________________________
> Lsr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lsr
>
> _______________________________________________
> Lsr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lsr
>
> _______________________________________________
> Lsr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
