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 <ketant.ietf@xxxxxxxxx>
Sent: Thursday, September 4, 2025 11:46 PM
To: Yingzhen Qu <yingzhen.ietf@xxxxxxxxx>
Cc: Jeffrey (Zhaohui) Zhang <zzhang@xxxxxxxxxxx>; rtg-dir@xxxxxxxx; draft-ietf-lsr-anycast-flag.all@xxxxxxxx; last-call@xxxxxxxx; lsr@xxxxxxxx
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 >
I agree with you that the ac-flag is similar to the node-flag in RFC9129.
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 <
noreply@xxxxxxxx> 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
|
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
