Hi Erik, please see inline:
On 06/10/2022 02:32, Erik Kline via Datatracker wrote:
Erik Kline has entered the following ballot position for draft-ietf-lsr-flex-algo-24: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Internet AD comments for {draft-ietf-lsr-flex-algo-24} CC @ekline ## Comments ### S6.4, S7.4 * Is it safer to perhaps say that the M-flag is not only "not applicable" for SRv6 locators but add some kind of "MUST NOT be sent" and "MUST be ignored" ~type clauses?
Added following text to both 6.4 and 7.4": "M-flag MUST not be used when calculating prefix reachability for SRv6 Locator prefix."
S8 has this kind of language and I think it may help grab the attention of an implementer. ### S9 * Should there be any qualifications here for SRv6 locator prefixes?
"OSPF Flexible Algorithm Prefix Metric Sub-TLV" is defined for - OSPFv2 Extended Prefix TLV [RFC7684] and Inter-Area Prefix TLV and External Prefix TLV from [RFC8362]. SRv6 locator is advertised in a newly defined Locator LSA and Locator TLV, so the "OSPF Flexible Algorithm Prefix Metric Sub-TLV" is not applicable to SRv6 locator.
thanks, Peter
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
