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.
>
> A prefix that is advertised by a single node and without an AC-flag
> MUST be considered node specific prefix.
>
> What if a prefix is advertised by multiple nodes but w/o the AC-flag?
>
> 5. YANG Data Model
>
> module: ietf-ospf-anycast-flag
>
> 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?
>
> 5.2. YANG Data Model for OSPFv2 Anycast Property Advertisement
>
> The following is the YANG module:
>
> <CODE BEGINS> file "[email protected]"
> module ietf-ospf-anycast-flag {
> yang-version 1.1;
> namespace
> "urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag";
> 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.
>
> import ietf-routing {
> prefix rt;
> reference
> "RFC 8349: A YANG Data Model for Routing
> Management (NMDA Version)";
> }
> import ietf-ospf {
> prefix ospf;
> reference
> "RFC 9129: YANG Data Model for the OSPF Protocol";
> }
>
> identity ac-flag {
> base ospf:ospfv2-extended-prefix-flag;
> description
> "Anycast flag. When set, it indicates that the prefix
> is configured as anycast.";
> }
>
> /* Configuration */
> augment "/rt:routing/rt:control-plane-protocols/"
> + "rt:control-plane-protocol/ospf:ospf/"
> + "ospf:areas/ospf:area/ospf:interfaces/ospf:interface" {
> when "derived-from(/rt:routing/rt:control-plane-protocols/"
> + "rt:control-plane-protocol/rt:type, 'ospf:ospfv2')" {
> description
> "This augments the OSPFv2 interface configuration.";
> }
> description
> "This augments OSPFv2 interface configuration with anycast
> property advertisement.";
> leaf anycast-flag {
> type boolean;
> default "false";
> description
> "Sets the prefix as an anycast address.";
> }
> }
> }
>
> Thanks.
> Jeffrey
>
>
>
>
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
