Hi Aijun, You have been repeatedly making this argument at different times and in different contexts (WGLC, complaint to AD, appeal to the IESG). However, since this was addressed to me once again in response to my ballot, I will answer again (hopefully for one last time).
Please read https://www.ietf.org/archive/id/draft-ietf-lsr-igp-ureach-prefix-announce-09.html#section-4.2 - this document extends the base OSPF protocol behavior specifically for UPAs alone to allow their propagation. Therefore, this is not in conflict with RFC2328. Thanks, Ketan PS: I will note that you have also copied the LSR WG on this email and it may be seen as repeatedly making the same arguments over and over again to the LSR WG. On Wed, Sep 24, 2025 at 4:52 AM Aijun Wang <[email protected]> wrote: > Hi, Ketan: > > I reviewed your discussions in detail and also interested that you raised > the role of UPA signal originator and UPA signal advertiser in different > areas(from access, to aggregate and core etc.) > > I know also you are the OSPF experts, and should be aware the description > in RFC 2328: > > “Else, if the routing table cost equals or exceeds the value LSInfinity, a > summary-LSA cannot be generated for this route.” > > > > Then, based on the above multi-areas scenarios, how the ABRs in aggregate > or core area can propagate the UPA signal further, via one kind of > summary-LSA? > > Doesn’t the behavior described in this document conflict with the above > design in RFC2328? > > Aijun Wang > China Telecom > > On Sep 23, 2025, at 18:55, Ketan Talaulikar <[email protected]> wrote: > > > 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] > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
