Hi Peter, The text looks good to me. I'll clear my DISCUSS position once the updated version is posted.
Thanks, Ketan On Tue, 23 Sept, 2025, 4:07 pm Peter Psenak, <[email protected]> wrote: > Hi Keatn, > > please see inline (##PP3): > > On 22/09/2025 18:06, Ketan Talaulikar wrote: > > Hi Peter, > > Only one point remains. Please check inline below for KT2. > > > On Mon, Sep 22, 2025 at 9:21 PM Peter Psenak <[email protected]> wrote: > >> Hi Ketan, >> >> please see inline (##PP2): >> >> On 22/09/2025 15:43, Ketan Talaulikar wrote: >> >> Hi Peter, >> >> Thanks for your responses. Please check inline below for follow-ups. >> Skipping the ones where we have reached an agreement. >> >> >> On Mon, Sep 22, 2025 at 6:20 PM Peter Psenak <[email protected]> wrote: >> >>> Hi Ketan, >>> >>> thanks for the comments, please see inline (##PP): >>> >>> On 19/09/2025 19:49, Ketan Talaulikar via Datatracker wrote: >>> >>> 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? >>> >>> ##PP >>> >>> For originating routers, section 2 says: >>> >>> "UPA MAY be generated by the ABR or ASBR..". >>> >>> I added a text in section 2: >>> >>> "Generation of the UPA at the ABR or ASBR is optional and SHOULD be >>> controlled by >>> a configuration knob." >>> >> >> KT> This works for me, but consider "Generation and propagation of the >> UPA ..." to also cover the next part? >> >> ##PP2 >> >> done >> >> >> >> >>> I would leave the default behavior for the implementations to decide. I >>> see no reason why an RFC should mandate any specific default behavior. >>> >>> For propagation, I would think that if the ABR supports the UPA, it >>> should propagate it. Implementations are free to provide control if they >>> wish to, but I see no reason why an RFC should mandate that. >>> >> >> KT> Please see previous. I agree it is up to the implementation - most >> likely it is the same knob for UPA enablement as the propagating ABR might >> as well be the originating ABR for its local area. >> >> >> ##PP2 >> >> I added "propagation" >> >> For receiving routers, there is a text in section 7: >>> >>> "Processing of the received UPAs is optional and SHOULD be controlled by >>> the configuration at the receiver." >>> >>> 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? >>> >>> ##PP >>> Implementations are free to provide all sorts of control knobs, but from >>> the UPA specification the only one that are worth of specifying are the >>> ones at the originating and processing routers, which has been done. >>> >> >> KT> Section 2 has the following text: >> >> Implementations MAY limit the UPA generation to specific prefixes, e.g. >> host prefixes, SRv6 locators, or similar. Such filtering is optional and >> MAY be controlled via configuration. >> >> It is also RECOMMENDED that implementations limit the number of UPA >> advertisements which can be originated at a given time. >> >> I assume the reason for this is to ensure that in some pathological >> cases, there is not a storm of UPAs or a large number of UPAs being >> generated. If we consider access, aggregation, and core layers, then at >> each progressive level the propagation involves the UPAs of the lower level >> of hierarchy being sent towards the core. In this case, the propagating >> ABR/ASBRs are also kind of originating from the UPAs from the lower layer >> in its LSAs/LSPs. So, shouldn't the same controls/limits apply at those >> routers as well? Perhaps consider tweaking the language in the above text >> to cover both origination and propagation? I am not looking for mention of >> specific knobs. >> >> ##PP2 >> added propagation to the above text. >> >> >> >> >>> 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. >>> >>> ##PP >>> I'm not sure I understand the comment. Both extended LSAs and Locator >>> LSA are mentioned in the above quoted text. >>> The base OSPFv3 LSAs are NOT required, but if some deployment uses the >>> base LSAs only, they can be used to signal UPA. >>> >> KT> First, if only the base OSPFv3 LSAs are used, we cannot have the U/UP >> flags - if that is the intention, then please specify. I would >> assume/expect that we want to use the extended LSAs so those flags may be >> included. I also see it as another motivation for implementing the extended >> LSAs ;-) ... since there is no real reachability, we can safely avoid the >> duplicate advertisement of the base LSAs. >> >> ##PP2 >> we can still signal UPA for prefix advertised in legacy LSAs, if we >> signal U/UP flag in extended LSAs - e.g. sparse mode. >> > > KT2> My understanding of sparse mode is that the extended LSAs are used > for new functionality while the base LSAs are still used for the base > OSPFv3 routing. This allows for a deployment of new features where not all > routers need to support the extended LSAs. I consider UPA as a new > functionality and so it would work with just the extended LSAs. > > >> So your question is whether we need any base LSA or a Locator LSA in such >> case. Well, I guess we don't, but I would mandate them for consistency >> reasons - we mandate the presence of the parent TLV with the NU-bit and >> LSInfinity metric for these prefixes in section 5.2.2. >> > > KT2> Let's put aside the Locator LSA - it is completely a different thing. > The base LSAs and extended LSAs both have the metric (for LSInfinity) and > the PrefixOptions (for NU-bit) fields in them. Only the extended LSAs can > carry the U/UP flags. Therefore, I think it is unnecessary to carry double > the LSAs where the UPA could just be advertised using the extended LSAs. > This is different from OSPFv2 where the OSPFv2 Extended Prefix LSA didn't > have the metric and hence the base LSAs were necessary. > > > ##PP3 > I have updated the text: > > OLD: > > UPA in OSPFv3 is supported for Inter-Area-Prefix-LSA [RFC5340 > <https://www.rfc-editor.org/info/rfc5340>], AS-External-LSA [RFC5340 > <https://www.rfc-editor.org/info/rfc5340>], NSSA-LSA [RFC5340 > <https://www.rfc-editor.org/info/rfc5340>], E-Inter-Area-Prefix-LSA [ > RFC8362 <https://www.rfc-editor.org/info/rfc8362>], E-AS-External-LSA [ > RFC8362 <https://www.rfc-editor.org/info/rfc8362>], E-Type-7-LSA [RFC8362 > <https://www.rfc-editor.org/info/rfc8362>], and SRv6 Locator LSA [RFC9513 > <https://www.rfc-editor.org/info/rfc9513>]. > > > NEW: > > UPA in OSPFv3 is supported for prefix reachability advertised via > OSPFv3 E-Inter-Area-Prefix-LSA [RFC8362], E-AS-External-LSA > [RFC8362], E-Type-7-LSA [RFC8362], and SRv6 Locator LSA [RFC9513]. > > For prefix reachability advertised via Inter-Area-Prefix-LSA > [RFC5340], AS-External-LSA [RFC5340], NSSA-LSA [RFC5340], UPA is > signaled using their corresponding extended LSAs. This requires > support of the OSPFv3 Extended LSAs in a sparse mode as specified in > section 6.2 of [RFC8362]. > > thanks, > Peter > > > > Thanks, > Ketan > > >> >> >> >>> ---------------------------------------------------------------------- >>> 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? >>> >>> ##PP >>> >>> Changed to: >>> "This document specifies protocol mechanisms in IS-IS and OSPF, together >>> with >>> the two new flags, to advertise such prefix reachability loss." >>> >>> 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]? >>> >>> ##PP >>> done. >>> >>> 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? >>> >>> >>> ##PP >>> done >>> >>> 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? >>> >>> ##PP >>> I would prefer not to limit the UPA for the summarization use case, even >>> though that is the one we are targeting now. Maybe we can use it for >>> something else in the future. >>> >> >> KT> Sure, perhaps there may be such a use case in the future. However, >> having a check for summary (it can be optional), can help purge/remove a >> whole bunch of UPAs when the summary itself is gone. >> >> ##PP >> I would prefer not to mention all possible knobs in the specification. >> Such a knob is up to the implementation IMHO. >> >> >> >>> 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" ? >>> >>> ##PP >>> replaced with "consideration" >>> >>> 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. >>> >>> ##PP >>> it's latter, done. >>> >>> >>> 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: >>> >>> ##PP >>> done >>> >>> 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? >>> >>> ##PP >>> flooding is always limited to the area/level, so not sure we need to say >>> that. >>> >> >> KT> My concern was with "upgrades all nodes in a network" - network is >> broader than area/level and the ABRs/ASBR need to be updated to go across >> them in multi-area/level/domain network. >> >> ##PP >> ok, added "within the area" >> >> >> >> >>> 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? >>> >>> ##PP >>> done >>> >>> 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). >>> >>> ##PP >>> I'm not a fan of the deployment considerations in the RFCs, these >>> should be done by the individual vendors outside of the IETF. IETF's role >>> is to guarantee interoperability. >>> >> >> KT> I am not insisting on that. However, I will take this opportunity to >> make everyone aware of the work happening on >> https://datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/ that will be >> mandating an operational consideration section (similar to security >> considerations) for all specifications. >> >> >> ##PP2 >> wrong move IMHO, but this is not the right place to debate that :) >> >> thanks, >> Peter >> >> >> Thanks, >> Ketan >> >> >>> >>> 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. >>> >>> ##PP >>> sure, done. >>> >>> >>> 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., >>> >>> ##PP >>> done >>> >>> 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 ..." ? >>> >>> ##PP >>> done >>> >>> 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 >>> >>> ##PP >>> Changed MUST to "need to" >>> >>> >>> 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 ? >>> >>> ##PP >>> done >>> >>> >>> 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 ..." >>> >>> ##PP >>> I guess it should be "Prefix Extended Flags Sub-TLV >>> <https://www.rfc-editor.org/rfc/rfc9792.html#name-ospfv2-prefix-extended-flag> >>> s" >>> >>> >>> 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" >>> >>> ##PP >>> shoudl be "OSPFv2 Prefix Extended Flags Sub-TLV >>> <https://www.rfc-editor.org/rfc/rfc9792.html#name-ospfv2-prefix-extended-flag>" >>> I suppose. >>> >>> 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? >>> >>> ##PP >>> I feel having it here may be useful for people implementing it. >>> >>> 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 ... >>> >>> ##PP >>> done >>> >>> 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. >>> >>> ##PP >>> I feel like this text is redundant. It was requested by the earlier >>> review comments, but I feel the meaning of the U/UP flags is well covered >>> in section 5. >>> I have removed this text. >>> >>> 496 This document adds two new bits in the "OSPFv2 Prefix Extended Flags" >>> 497 and "OSPFv3 Prefix Extended Flags" registres: >>> >>> <nit> registries >>> >>> ##PP >>> done >>> >>> thanks, >>> Peter >>> >>> <EoRv09> >>> >>> >>> >>> >>> >>> >>> >> >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
