Actually, the initial proposal for such solution is to signal unplanned unreachability. The planned unreachability is one very odd scenario. Until now, I don’t see the value for bothering the protocol extension to deal with such scenario. Then, these optional U/UP flags are unnecessary. Best Regards Aijun Wang China Telecom From: Peter Psenak [mailto:ppsenak@xxxxxxxxx]
Sent: Friday, June 27, 2025 3:45 PM
To: Aijun Wang <wangaijun@xxxxxxxxxxxxxxx>; 'Dale Worley' <worley@xxxxxxxxxxx>; gen-art@xxxxxxxx
Cc: draft-ietf-lsr-igp-ureach-prefix-announce.all@xxxxxxxx; last-call@xxxxxxxx; lsr@xxxxxxxx
Subject: Re: [Lsr] Re: draft-ietf-lsr-igp-ureach-prefix-announce-08 ietf last call Genart review On 27/06/2025 08:47, Aijun Wang wrote: Trim the unrelated contents, to reflect the key confusion: According to the following responses, the newly defined u/up flag is optional, and they indicate the “the reason why the unreachability was advertised” Then, if only the “U”flag is attached, what’s the reason for the unreachability?
loss of reachability that was not planned. Peter If I am correct, you want to define a term like "the protocol specific way of specifying unreachability". Then you want to state early in the document something like A router that implements UPA MUST attach the U-bit to any announcement that contains the protocol specific way of specifying unreachability. Conversely, any announcement with the U-bit MUST also include the protocol specific way of specifying unreachability. ##PP
advertisement of the prefix unreachability has been defined in the past and we
are not allowed to change it, as that would result in a backward compatibility issue.
So we can not mandate any new-bit for signaling the unreachability. We are just
indicating with the optional new flags the reason why the unreachbaility was advertised. Aijun Wang China Telecom
|
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
