Re: [Lsr] Comments on draft-ppsenak-lsr-igp-ureach-prefix-announce

[Shraddha Hegde <[e-mail]>]

>It only mandates that this prefix not be used in SPF computation, and leave the possibility of using it for other purposes,
>where "indicating the prefix is unreachable" could be one of the possible use cases

I totally agree with that statement.
An indication of unreachability in the prefix-attribute flags in ISIS is useful.
In OSPF, we could use extended prefix opaque LSA to achieve it.

Rgds
Shraddha


Juniper Business Use Only
From: Lsr <[e-mail]> On Behalf Of Dongjie (Jimmy)
Sent: Friday, July 29, 2022 10:24 AM
To: Ketan Talaulikar <[e-mail]>; [e-mail]
Cc: lsr <[e-mail]>
Subject: Re: [Lsr] Comments on draft-ppsenak-lsr-igp-ureach-prefix-announce

[External Email. Be cautious of content]

Hi authors, WG,

I also have some comments which aligns with Ketan's first and third points as below:

Firstly, both RFC 5305 and 5308 say that:

"If a prefix is advertised with a metric larger then MAX_PATH_METRIC (call it infinite metric), 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."

It only mandates that this prefix not be used in SPF computation, and leave the possibility of using it for other purposes, where "indicating the prefix is unreachable" could be one of the possible use cases.

According to these RFCs, a node which receives such a prefix with a metric larger than MAX_PATH_METRIC will not take it into consideration for SPF computation, but if there is another summary prefix which covers this one, this prefix will still be reachable based on the summary prefix.

To indicate this prefix is unreachable even if there is a summary prefix exist, additional behavior is required on the receiving node, and this needs to be indicated with some additional information in the prefix advertisement.

Secondly, section 2.1 of this document says

"...Such an advertisement can be interpreted by the receiver as a UPA."

And

 "Optionally, an implementation may use local configuration to limit the set of metric values which will be interpreted as UPA."

This shows that such an advertisement may be interpreted by the receiver as something else, and it is expected that not all of the metric values larger then MAX_PATH_METRIC will be interpreted as "prefix is unreachable".

To avoid possible mis-interpretation of the purpose of this prefix advertisement, and to save the effort of local configuration, a protocol mechanism is needed to carry the accurate indication of the purpose of this advertisement.

In summary,


1)       Treating such a prefix as unreachable is not the behavior defined in the existing RFCs, a standard track document would be needed for it.

2)       Additional information in the advertisement is needed to accurately reflect the purpose and the required behavior.

Hope this helps.

Best regards,
Jie

From: Lsr [mailto:[e-mail]] On Behalf Of Ketan Talaulikar
Sent: Thursday, July 28, 2022 2:27 PM
To: [e-mail]<mailto:[e-mail]>
Cc: lsr <[e-mail]<mailto:[e-mail]>>
Subject: [Lsr] Comments on draft-ppsenak-lsr-igp-ureach-prefix-announce

Hello Authors,

Sharing some comments upfront on this draft given the packed LSR agenda.

1) There is currently no change in protocol encoding (see also further comment), however, there are protocol procedures at the ABR being specified using normative language. Specifically, the text related to the propagation of UPA across levels/areas/domains. Therefore, I believe that this draft should be moved to the standards track.

2) The document refers to "prefix reachability" in a generic sense. My understanding is that this refers to the "base" prefix reachability in the IGPs - i.e., Extended IP Reachability (TLV 135) and its MT & IPv6 siblings in ISIS, the OSPFv2 Type 3 LSA, and the OSPFv3 Inter-Area Prefix LSA (and its Extended LSA sibling). It would be good to specify these for clarity.

3) I also prefer (like some other WG members) that there is an explicit indication that is carried along with the UPAs. E.g., a UPA flag. This will help in more accurate monitoring and handling of these updates. It will also help differentiate the usual/existing max/infinite metric advertisements that may be triggered for other reasons from a UPA.

Thanks,
Ketan