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 [email protected]" <[email protected] on behalf of [email protected]> wrote: > From: Lsr <[email protected]> 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 (0xFE000000), 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 > [email protected] > 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
