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 <ppse...@cisco.com> 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 tohttps://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.

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.


    ----------------------------------------------------------------------
    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 -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org

Reply via email to