|
Hi Ran, Please see
zzh> below.
Juniper Business Use Only From: chen.ran@xxxxxxxxxx
<chen.ran@xxxxxxxxxx> [External Email. Be cautious of content] Hi Jeffery, Many thanks for your review! Please see inline... BR, Ran From: ZhaohuiZhangviaDatatracker
<noreply@xxxxxxxx> To: rtg-dir@xxxxxxxx
<rtg-dir@xxxxxxxx>; Cc: draft-ietf-lsr-anycast-flag.all@xxxxxxxx
<draft-ietf-lsr-anycast-flag.all@xxxxxxxx>;last-call@xxxxxxxx <last-call@xxxxxxxx>;lsr@xxxxxxxx <lsr@xxxxxxxx>; Date: 2025年09月05日
04:20 Subject: [Last-Call] draft-ietf-lsr-anycast-flag-05
ietf last call Rtgdir review Document: draft-ietf-lsr-anycast-flag of this draft. Ran: Thank you for your suggestions. We've incorporated your feedback and made the following revisions. Please let us know if this addresses your concerns. [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 a prefix. Extensions related to the anycast property of prefixes have been specified for IS-IS [RFC9352] and OSPFv3 [RFC9513], even though those documents are related to Segment Routing over IPv6, the anycast property applies to any IP prefix advertisement. This document defines a flag to advertise the anycast property for a prefix advertisement in OSPFv2 in the Flags field of the OSPFv2 Extended Prefix TLV Flags (section 2.1 of [RFC7684]). Zzh> If this is just a parity feature for OSPFv2, then perhaps we don’t need the use-case section
😊
I have one in mind and could provide text if you would like to include it. Ran: Many thanks! Ketan provided a use case, which we authors have discussed. Please see if the following content is suitable. Zzh> Perhaps make it clear that two use cases are included here. Section 3.3 of [RFC8402] describes an IGP-Anycast Segment and its use with SR-MPLS. The use of an anycast segment as a waypoint in a SR TE path is a use-case that requires consistent use of labels both for the anycast segment but also the segment following it if that is an adjacency SID or binding SID allocated dynamically or from the SRLB. However, there is no indication available in OSPFv2 to convey to the entity performing path computation using the OSPF LSDB that specific prefix segments are anycast segments. Zzh> Perhaps remove “is a use-case that”. When computing TI-LFA [I-D.ietf-rtgwg-segment-routing-ti-lfa] repair paths using SR segments, the requirement is to pick specific nodes that need to be traversed to ensure loop free characteristics. This requires picking prefix segments of those nodes that uniquely identify those nodes. The selection of anycast prefix segments advertised by those nodes for the TI-LFA repair path may result in loops as the traffic may get rerouted to another node advertising the same anycast segment. Hence, only node segments (with or without the N-flag) and not anycast segments (with the AC-flag) are to be used for TI-LFA repair paths.
MUST be considered node specific prefix. Ran: This sentence wants be be changed to: A prefix that is advertised by a single node and without an AC-flag is considered node-specific prefix. What if a prefix is advertised by multiple nodes but w/o the AC-flag? Ran: A prefix advertised by multiple nodes without an AC-flag is considered an anycast prefix. Zzh> Then why do we need the AC-flag? Should we say that any prefix w/o the AC-flag must not be considered as anycast? Zzh> Thanks. Zzh> Jeffrey
may need the AC-flag? Ran：Yingzhen and Ketan are already handling the issue.
|
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
