Hi Gunter, Thanks for the review.
> On Dec 17, 2024, at 10:22 AM, Gunter van de Velde (Nokia) > <[email protected]> wrote: > > # Gunter Van de Velde, RTG AD, comments for draft-ietf-lsr-ospf-admin-tags-22 > > # The referenced line numbers are derived from the idnits tool: > https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-lsr-ospf-admin-tags-22.txt > > # Many thanks for this write-up. The document is well written and was a > pleasure to read. > > # idnits tool comes up clean > > # Many thanks to Christian Hopps for the Shepherd write-up, Russ White for > the RTGDIR review and Qiufang Ma for the YANGDOCTORS review > > #DETAILED COMMENTS > #================== > > 139 Type A 16-bit field set to TBD. > > GV> From readability, maybe call out that there is a: > TBD1: "OSPF Extended Prefix TLV Sub-TLV" Registry > TBD2: "OSPFv3 Extended-LSA Sub-TLV" Registry > TBD3: "OSPFv3 SRv6 Locator LSA Sub-TLVs" Registry I've added and updated the "IANA Considerations" although I'm not sure if it is more readable. > > 210 action. Whether or not tag A precedes or succeeds tag B SHOULD NOT > 211 change the meaning of the tag set. The number of tags supported MAY > > GV> the "tag set" wording may be unclear and confusing. Is it the "tag that > is set" or the "set of tags". > What about: I don't see it as confusing as the former would be "set tag" rather than "tag set". > > " > Regardless of whether tag A precedes or follows tag B, the meaning of the tag > SHOULD NOT be affected. I don't see this as confusing but I've replaced "tag set" with "tags". > " > > 211 change the meaning of the tag set. The number of tags supported MAY > 212 limit the number of tags that are propagated. When propagating > > GV> I suspect that this is referencing to the number of tags on the ABR > and/or the router originating the prefix with its associated tags? > Is this something that can be further accurately explained? What about: > > " > The number of supported tags on the router originating the prefix or on an > ABR MAY limit the number of tags that are ultimately propagated. I've added ABR as that is what this statement pertains. > " > > 217 For configured area ranges, NSSA ranges, and configured aggregation > 218 of redistributed routes, tags from component routes SHOULD NOT be > 219 propagated to the summary. Implementations SHOULD provide a > 220 mechanism to configure multiple tags for area ranges, NSSA ranges, > 221 and redistributed route summaries. > > GV> Why is this a SHOULD NOT instead of a MUST NOT? What breaks or causes > issues if tags would be propagated to a summary? The fact that a summary could represent a single prefix or a 1000, make propagating tags unwieldy and hard to specify. I don't think this needs to be a MUST NOT as summarization is a local matter. > > 226 these LSAs will all have different tags. In this situation, the OSPF > 227 router MUST associate the tags from one of the LSAs contributing a > 228 path and, if the implementation supports multiple tags, MAY associate > 229 tags from multiple contributing LSAs up to the maximum number of tags > 230 supported. It is RECOMMENDED that tags from LSAs are added to the > > GV> It displays "multiple tags supported", however it is unclear by which > router this observation must be applied I've clarified that this done by the ABR. > > 247 However, the default behavior SHOULD be to advertise or propagate the > 248 lesser number of all the tags associated with the prefix or the > 249 maximum number of tags supported by the implementation. > > GV> I managed to get confused with what the "lesser number" exactly means? is > this the number of tags according to the policy? It applies to the number of tags advertised - no matter whether they are propagated or it done via policy. > > GV> Would it be allowed for ABRs to impose additional tags upon prefixes for > management reasons? Or can only the router that originates a specific prefix > set one or multiple tags Yes - but we don't want to precisely specify this. I changed "filter" to "modify". > > 251 Both the support of this specification and the number of tags > 252 supported by OSPF routers within an OSPF routing domain will limit > 253 the usefulness and deployment of applications utilizing tags. > > GV> Is it expected that all routers in the routing domain support the same > number of tags? I don't see how we could enforce this - it will depend on future requirements. The implementations that I'm familiar support 1 or 2 (one implementation) and I added the additional, aka, application tag in the one supporting 2. > > 742 9. IANA Considerations > 743 > 744 The following values should be allocated from the "OSPF Extended > 745 Prefix TLV Sub-TLV" Registry [RFC7684]: > 746 > 747 * TBD - Administrative Tag Sub-TLV > 748 > 749 The following values should be allocated from the "OSPFv3 Extended- > 750 LSA Sub-TLV" Registry [RFC8362]: > 751 > 752 * TBD - Administrative Tag Sub-TLV > 753 > 754 The following values should be allocated from the "OSPFv3 SRv6 > 755 Locator LSA Sub-TLVs" Registry [RFC9513]: > 756 > 757 * TBD - Administrative Tag Sub-TLV > > GV> maybe call out that there are three TBDs (TBD1, TBD2 and TBD3) as seen > from section 2 Yup. Again - thanks of for the review. Acee > > Brgds, > G/ > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
