Hi Aijun, I shall make sincere efforts to provide rationale and explanations to convince people. I do not expect to be able to convince everyone. Some may convince me of their point of view while others may remain unconvinced.
If you are unconvinced on this particular topic, I will leave it at that. Thanks, Ketan On Wed, Sep 24, 2025 at 12:38 PM Aijun Wang <[email protected]> wrote: > . I look forward to hear your convincible questions > > > Should be updated to: > > I look forward to hear your convincible answer. > > Aijun Wang > China Telecom > > On Sep 24, 2025, at 14:54, Aijun Wang <[email protected]> wrote: > > Hi, Ketan: > > I think you should know the so-called UPA message is not different from > the other LSA with the metric set to LSInfinity, right? > > Then, if the ABR filters the LSA with metric set to LSInfinity, according > to the base OSPF standard(RFC2328), it will certainly filter UPA. > > That is to say, what you said “ this document extends the base OSPF > protocol behavior specifically for UPAs alone to allow their propagation.” > is NOT possible. > > The current document is definitely conflict with the RFC2328. > > The reason that I stick to this question and ask again and again, is that > no any experts gives the explicit answer until now. > > You are the first expert try to face this fundamental question directly. I > look forward to hear your convincible questions. > > Or else, the LSR, the IESG and the IETF will produce another problematic > RFC document again. > > Aijun Wang > China Telecom > > On Sep 24, 2025, at 12:42, Ketan Talaulikar <[email protected]> wrote: > > > 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] > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
