Hi, Bruno: I agree with your thoughts on the solutions to this questions.
Actually, this is the reason that we brought up the thread “Convergence of Prefixes Unreachable Announcement Proposal” and I think you can review the discussion of this thread again. And, in the mail https://mailarchive.ietf.org/arch/msg/lsr/qZ87Kjc9RdSsNpXzpOu31g1dSR0/, we have the following statements: “ Anyway, to make the UPA mechanism take effect, you will also require the router be upgraded. And the “Max-Value” solution doesn’t necessarily indicate the prefix is lost. We should announce such information explicitly.” Whether defining a new flag or use the prefix originator information(as adopt by https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-09#section-4) to indicate explicitly the prefix is unreachable can be further discussed. Aijun Wang China Telecom > On Jun 15, 2022, at 22:09, bruno.decra...@orange.com wrote: > > > Hi Peter, authors, all > > Thanks for the draft. I find it a useful contribution to the problem space. > > IMHO the use of MAX_PATH_METRIC is a good idea in particular since it can be > made backward compatible and provides incremental benefits with incremental > deployment. > > I also have two disagreements on the current draft. Both are minor IMO, but > authors may have a different opinion. > > This draft defines a new signaling from an egress ABR to all ingress ABR/PE. > As such, this require all these nodes to agree on this signaling. So I’d call > for a STD track document. > IMO, the behavior defined in this draft is not backward compatible with the > specification of MAX_PATH_METRIC in an IP prefix. > > RFC5305 says: > If a prefix is advertised with a metric larger then MAX_PATH_METRIC > (0xFE000000, see paragraph 3.0), 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. > > As per the above, one (ABR) may (is allowed and free to do so) already > advertise both an aggregate prefix IP1/N with a regular metric and a more > specific prefix IP2/32 with MAX_PATH_METRIC. > With the above advertisement, all nodes compliant with RFC 5305 will install > IP1/N in their FIB and not consider IP2/32 during their SPF and as a > consequence not install it in their FIB. > In term of reachability, all nodes have IP reachability to all IP @ in IP1 > including IP2. > > If one node now implements the draft, it will remove reachability for IP2. > And hence all my BGP routes using IPv2 for next-hop will be removed. > This looks clearly like a change in behavior to me, plus one which introduce > loss of reachability in an existing network. > > 3) The solution that I would suggest is: > - advertise the “unreachable prefix” with metric MAX_PATH_METRIC > - define a new “Extended Reachability Attribute Flags” ([RFC 7794]) > explicitly signaling that the reachability to this prefix has been lost: > Unreachable Flag (U_flag). Set if this prefix is to be considered > unreachable. > > This would allow for explicit signaling of the reachability (vs implicit > currently) and would be backward compatible with existing specification and > deployments. > > Regards, > --Bruno > > _________________________________________________________________________________________________________________________ > > 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 > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
