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?
/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.
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.
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 "ietf-ospf-anycast-flag@xxxxxxxxxxxxxxx"
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
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
