Bruno, inline From: Bruno Decraene <bruno.decra...@orange.com> Date: Wednesday, June 15, 2022 at 12:27 PM To: Dan Voyer <daniel.vo...@bell.ca>, "lsr@ietf.org" <lsr@ietf.org> Subject: [EXT]RE: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce
Hi Daniel, I agree that the draft-ppsenak-lsr-igp-ureach-prefix-announce, is presented as “a use case”/informational. My point is that IMO the draft changes the behavior defined in RFC5305/RFC5308. Indeed, as per those two RFC, I’m allowed, today, to advertise a prefix with MAX_PATH_METRIC for a purposes other than building the normal IP routing table.. - As per RFC5305/RFC5308, my reading is that such advertisement does not change the reachability of this prefix. IOW it’s reachable if there is an aggregate prefix. - draft-ppsenak-lsr-igp-ureach-prefix-announce would change that and hence would change existing behavior in my network. i.e. the existing prefixes advertised with MAX_PATH_METRIC would become unreachable, breaking existing services. [DV] but if MAX_PATH_METRIC gets triggered, it means an existing service got broken or else MAX_PATH_METRIC doesn’t get triggered. The trigger could that that a PE is going on maintenance or .. just crashed – nonetheless that PE vanished and with summarization other PEs from other area won’t get notified resulting in “breaking” service if MAX_PATH_METRIC is not triggered – “in this proposal”. We are just reusing an existing idea. I don’t see the big deal of defining a new flag for advertising this unreachability: the use case defined in draft-ppsenak-lsr-igp-ureach-prefix-announce requires a new implementation on all (ingress) PEs and ABRs. Given this, what’s the cost having those new implementation also advertising a sub-TLV/flag? [DV] it only requires support for RFC5305/RFC5308 – hence why I am asking what’s missing in those 2 RFC ? Basically, if I ignore “draft-ppsenak-lsr-igp-ureach-prefix-announce” since it’s only informational, and wanted to do these RFCs – what’s missing ? Thanks, Cheers, --Bruno Orange Restricted From: Voyer, Daniel <daniel.vo...@bell.ca> Sent: Wednesday, June 15, 2022 6:06 PM To: DECRAENE Bruno INNOV/NET <bruno.decra...@orange.com>; lsr@ietf.org Subject: RE: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce Hi Bruno, Thanks for your comment on the draft. I too, have a minor disagreement on your disagreement. The draft-ppsenak-lsr-igp-ureach-prefix-announce, is really presented as “a use case”/informational. In this case, a PE being hidden from other area due to route summarization. The draft is not meant to “invent” something new, hence the reference to RFC5305/RFC5308. If you jump to RFC5308 (as we are looking at IPv6 here), the advertising mechanism is well describe. What’s missing from RFC5308 from your view point ? Thanks Dan From: Lsr <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> on behalf of Bruno Decraene <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> Date: Wednesday, June 15, 2022 at 10:09 AM To: "lsr@ietf.org<mailto:lsr@ietf.org>" <lsr@ietf.org<mailto:lsr@ietf.org>> Subject: [EXT][Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce 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. 1) 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. 2) 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. _________________________________________________________________________________________________________________________ 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. ________________________________ External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
