Ketan Talaulikar has entered the following ballot position for draft-ietf-lsr-igp-ureach-prefix-announce-09: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-announce/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks to the authors and the WG for their work on this document. I believe this is a useful feature in specific deployment use cases where summarization is used for scaling purposes. I have a few points that I would like to discuss. discuss#1: Feature Enablement - I believe that UPA is an optional feature of IGPs and not a core IGP functionality. Therefore, it should be disabled by default. While there is text in the document about various control knobs and parameters for implementations, I was not able to find anything about enablement (at originating, propagating, and receiving routers?) which I believe is required? discuss#2: Limit/control at ABR/ASBR - Just like the ABR/ABSR that are originating UPAs, is some control and limit expected at an ABR/ASBR that is propagating UPAs? Is there some check required that those UPAs are covered by a summary that is being also propagated (or originated) by that ABR/ASBR? discuss#3: section 4 says: "UPA in OSPFv3 is supported for Inter-Area-Prefix-LSA [RFC5340], AS-External-LSA [RFC5340], NSSA-LSA [RFC5340], E-Inter-Area-Prefix-LSA [RFC8362], E-AS-External-LSA [RFC8362], E-Type-7-LSA [RFC8362], and SRv6 Locator LSA [RFC9513]." I would like to understand why the base OSPFv3 LSAs are required for UPA and why it cannot be done with just the extended LSAs (operating in sparse mode) and the SRv6 Locator LSA. It is likely that I am missing something and hence asking for clarification. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please find below some comments provided in the idnits output of the v09 of the document. Please look for <EoRv09> at the end of the email. If that is not present then likely the email has been truncated by your email client. 24 This document describes how to use the existing protocol mechanisms 25 in IS-IS and OSPF, together with the two new flags, to advertise such 26 prefix reachability loss. <minor> Perhaps remove "existing" from the above sentence in view of sections 3.2 and 4.2? 126 IS, or by setting high metric on all-links and prefixes advertised by 127 the node in OSPF. When prefixes from such node are summarized by the <minor> For OSPF, is the reference here to MaxLinkMetric in RFC6987 and LSInfinity? Perhaps also the H-bit for v2 [RFC8870] and R-bit for v3 [RFC5340]? 151 This document defines two new flags in IS-IS, OSPF, and OSPFv3. 152 These flags, together with the existing protocol mechanisms, provide <minor> Perhaps remove "existing" here as well for the same reasons as previous comment? 160 2. Generation of the UPA 162 UPA MAY be generated by the ABR or ASBR for a prefix that is 163 summarized by the summary address originated by the ABR or ASBR in 164 the following cases: <major> Should we also call out that UPA MUST NOT be generated unless it is covered by a summary? 204 In OSPF and OSPFv3, each inter-area and external prefix is advertised 205 in it's own LSA, so the above optimisation does not apply to OSPF. <minor> s/optimisation/consideration ? ... or perhaps "constraint" ? 207 It is also RECOMMENDED that implementations limit the number of UPA 208 advertisements which can be originated at a given time. <major> Is the intention here about how many can be originated in one go OR how many UPAs would be present (active) in that routers LSAs/LSPs at any given point of time? I am assuming it is the latter and if so please clarify. 210 3. Supporting UPA in IS-IS 212 [RFC5305] defines the encoding for advertising IPv4 prefixes using 4 213 octets of metric information. Section 4 specifies: <minor> For clarity, suggest: [RFC5305] defines the encoding for advertising IPv4 prefixes using 4 octets of metric information and its Section 4 specifies: 234 3.1. Advertisement of UPA in IS-IS 236 Existing nodes in a network that do not suport UPA will not use UPAs 237 during the route calculation, but will continue to flood them. This 238 allows flooding of such advertisements to occur without the need to 239 upgrade all nodes in a network. <minor> Should "will continue to flood them" be qualified as "will continue to flood them within the level" or something on similar lines? 241 Recognition of the advertisement as UPA is only required on routers 242 which have a valid use case for this information. Those ABRs or 243 ASBRs, which are responsible for propagating UPA advertisements into 244 other areas or domains MUST also recognize UPA advertisements. <major> Perhaps s/domains MUST also recognize/domains are also expected to recognize ... or word it differently since this is more like an operational/deployment guideline for UPA feature? If providing operational or deployment considerations, then suggest to introduce a new section named as such and describe which routers are expected to be UPA-aware (or this could be done in section 2 with a title change that covers not just generation but other aspects as well). 251 UPA in IS-IS is supported for all IS-IS Sub-TLVs registered in the 252 IS-IS Sub-TLVs Advertising Prefix Reachability registry, which was 253 initially defined in [RFC7370], e.g.,: <major> For clarity, I would suggest: [RFC7370] introduced the IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability registry which lists TLVs for advertising different types of prefix reachability (that list at the time of publication of this document is below). UPA in IS-IS is supported for all such TLVs identified by that registry. 272 level 1 and level 2. Propagation is only done if the prefix is 273 reachable in the source level, e.g., prefix is only propagated from a <nit> s/e.g.,/i.e., 315 UPA in OSPFv2 is supported for OSPFv2 Summary-LSA [RFC2328], AS- 316 external-LSAs [RFC2328], NSSA AS-external LSA [RFC3101], and OSPFv2 317 IP Algorithm Prefix Reachability Sub-TLV [RFC9502]. <minor> I think the intention here is to say that "UPA in OSPFv2 is supported for prefix reachability advertised via ..." ? 333 4.2. Propagation of UPA in OSPF 335 OSPF ABRs or ASBRs, which would be responsible for propagating UPA 336 advertisements into other areas MUST recognize such advertisements. <major> This is more of a deployment guideline. Please see similar comment in section 3.1 352 set in PrefixOptions, for various reasons. Even though in all cases 353 the treatment of such metric, or NU-bit, is specified for IS-IS, OSPF 354 and OSPFv3, having an explicit way to signal that the prefix was 355 advertised in order to signal unreachability is required to <minor> perhaps s/unreachability/UPA ? 382 5.2. Signaling UPA in OSPF 384 A new Prefix Attributes Sub-TLV has been defined in 385 [I-D.ietf-lsr-ospf-prefix-extended-flags] for advertising additional 386 prefix attribute flags in OSPFv2 and OSPFv3. <minor> please update reference to RFC9792 and also "OSPFv2 and OSPFv3 Prefix Attributes sub-TLVs have been ..." 403 5.2.1. Signaling UPA in OSPFv2 405 In OSPFv2 the Prefix Attributes Sub-TLV is a Sub-TLV of the OSPFv2 406 Extended Prefix TLV [RFC7684]. <minor> The name is "OSPFv2 Prefix Attributes Sub-TLV" 428 metric set to a value LSInfinity. For default algorithm 0 prefixes, 429 the LSInfinity MUST be set in the parent TLV. For IP Algorithm 430 Prefixes [RFC9502], the LSInfinity MUST be set in OSPFv3 IP Algorithm 431 Prefix Reachability sub-TLV. If the prefix metric is not equal to 432 LSInfinity, both of these flags MUST be ignored. <major> For OSPFv3, RFC9502 is clear about what metric is in operation. Is this text on default and IP algo needed? 444 prefix. As a result, depending on which ABR or ASBR the traffic is 445 using to enter a partitioned area, the traffic could be dropped or be 446 delivered to its final destination. UPA does not make the problem of <nit> could be either dropped or delivered ... 460 7. Processing of the UPA 462 The setting of the U-Flag signals that the prefix is unreachable. If 463 the U flag is set, the setting of the UP flag signals that the 464 unreachability is due to a planned event. <minor> Suggest to move the above paragraph at the end of section 5 and just before section 5.1 where the semantics of the flags would be introduced before their protocol encodings are specified. 496 This document adds two new bits in the "OSPFv2 Prefix Extended Flags" 497 and "OSPFv3 Prefix Extended Flags" registres: <nit> registries <EoRv09> _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
