Hi Jeffrey,

The N flag indicates that this prefix "sort of" identifies the node
uniquely. E.g., like a router-id. The Node SID in SR-MPLS is an example of
this. That is why it is normally selectively used generally for the
loopback interface as Yingzhen indicated in her reply.

And note that we are talking about prefixes and not addresses (as in /32 or
/128). So, using prefixes assigned to interfaces are not necessarily unique
and are quite often shared by routers on that link.

Thanks,
Ketan


On Fri, Sep 5, 2025 at 5:30 PM Jeffrey (Zhaohui) Zhang <[email protected]>
wrote:

> Hmm … I am curious why we even need an interface-level node-flag in the
> YANG model.
>
> Shouldn’t all local addresses on an interface carry the N-flag?
>
> Or is there a good reason to not signal the N-flag for all local addresses?
>
>
>
> Jeffrey
>
>
>
> Juniper Business Use Only
>
> *From:* Ketan Talaulikar <[email protected]>
> *Sent:* Thursday, September 4, 2025 11:46 PM
> *To:* Yingzhen Qu <[email protected]>
> *Cc:* Jeffrey (Zhaohui) Zhang <[email protected]>; [email protected];
> [email protected]; [email protected]; [email protected]
> *Subject:* Re: draft-ietf-lsr-anycast-flag-05 ietf last call Rtgdir review
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> < as a WG member and co-author >
>
>
>
> Hi Yingzhen,
>
>
>
> I agree with you that the ac-flag is similar to the node-flag in RFC9129.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Fri, Sep 5, 2025 at 4:59 AM Yingzhen Qu <[email protected]>
> wrote:
>
> Hi Jeffrey,
>
> Thanks for the review.
>
> I will answer only the questions to the data model and leave the rest to
> the authors.
>
> "
>      augment /rt:routing/rt:control-plane-protocols
>                /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
>                /ospf:interfaces/ospf:interface:
>        +--rw anycast-flag?   boolean
>
> Should it be part of the interface or prefix configuration?
> An interface could have multiple addresses, and maybe only one/some of them
> may need the AC-flag?
> "
> I thought about this. When a prefix is configured as an anycast address,
> most likely it's a prefix on a loopback interface, that's why I have this
> configuration on an interface. Otherwise we can have it in the router mode
> with a prefix. Please let me know what you think.
>
> "
>      prefix ospf-anycast-flag;
>
> What does "prefix ospf-anycast-flag" mean here? Is it an interface or
> prefix
> property?
> The following mentions both interface and prefix.
> "
> This is just a YANG model's prefix.
>
> Thanks,
> Yingzhen
>
> On Thu, Sep 4, 2025 at 1:19 PM Zhaohui Zhang via Datatracker <
> [email protected]> wrote:
>
> > Document: draft-ietf-lsr-anycast-flag
> > Title: OSPFv2 Anycast Property Advertisement
> > Reviewer: Zhaohui Zhang
> > Review result: Has Nits
> >
> > For the following two paragraphs:
> >
> >    [RFC7684] defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV)
> >    tuples that can be used to associate additional attributes with
> >    prefixes or links.  The OSPFv2 Extended Prefix TLV that is contained
> >    in the OSPFv2 Extended Prefix Opaque LSA is used to advertise
> >    additional attributes associated with an IPv4 prefix, but the
> >    definition of anycast flag to identify the IPv4 prefix as anycast has
> >    not yet been defined.
> >
> >    The flags field of the OSPFv2 Extended Prefix TLV (Section 2.1 of
> >    [RFC7684]) can be found in "OSPFv2 Extended Prefix TLV Flags" IANA
> >    registry [IANA-OSPFv2-EPF].
> >
> > They could be combined into the following:
> >
> >    [RFC7684] defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV)
> >    tuples that can be used to associate additional attributes with
> >    prefixes or links.  The OSPFv2 Extended Prefix TLV that is contained
> >    in the OSPFv2 Extended Prefix Opaque LSA is used to advertise
> >    additional attributes associated with an IPv4 prefix, including a
> flags
> >    field (Section 2.1 of [RFC7684]) with an "OSPFv2 Extended Prefix TLV
> > Flags"
> >    IANA registry [IANA-OSPFv2-EPF].
> >
> > This would match the changes in the abstract (between the -04 and -05
> > revision)
> > of this draft.
> >
> > 2.  Use-case
> >
> >    In the absence of the N-flag, the node specific prefixes need to be
> >    identified from the anycast prefixs.  A prefix that is advertised by
> >    a single node and without an Anycast Flag (AC-flag) MUST be
> >    considered node specific.
> >
> > The above is not a use case, and the content is present below anyway.
> > I would suggest to remove the section, or give a real use case example.
> > I have one in mind and could provide text if you would like to include it
>
>
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to