Hi,
Please find below my review of the document. Nits: Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Section 3: s/no longer “known to down”/no longer “known to be down”/ ? Section 3.1.1: As the document is standard track, could you introduce normative language in the expected behavior description ? Section 3.1.2: As the document is standard track, could you introduce normative language in the expected behavior description ? “This method should not be used”. Wouldn’t this be a normative statement ? Section 3.1.4: As the document is standard track, could you introduce normative language in the expected behavior description ? s/(I or S , depending)/(I-PMSI or S-PMSI) It is not crystal clear which branch exactly is the “upstream one-hop branch of the tunnel from P to PE” ? Do you refer to the PEreceiver-P branch ? or P – PE_source branch ? Section 3.1.5: As the document is standard track, could you introduce normative language in the expected behavior description ? “it is recommended to provide a reasonable default value for this timer.” Why not providing it in this document ? “In cases where this mechanism is used in conjunction with Hot leaf standby » Can you add the section reference for the Hot leaf standby ? Section 3.1.6: As the document is standard track, could you introduce normative language in the expected behavior description ? Could you use the right spacing in “BGP- BFD attribute” ? Would “BFD discriminator” attribute or just “BFD” attribute be a better name ? we know that it is BGP 😊 >From a wider perspective, do you foresee other use case of signaling BFD >information in BGP ? I’m just wondering if we may need something extensible >for future use or not. Even in this use case, I’m wondering if the BFD session type should be included as part of the attribute rather than being deduced from the fact that the attribute is attached to an x-PMSI route. I would be glad to hear your feedback on that. Section 3.1.6.2: s/Then The/ Then the/ “A different p2mp BFD session MAY monitor the state of the Standby Upstream PE. » This is not fully clear to me. I thought that this BFD session was used as part of the UMH selection process, which means that there is no UMH selected yet. Do you mean monitoring an alternate P tunnel rooted at a different upstream PE ? Section 3.1.7 This is not clear to me. Are you using BFD only to signal a Down state without really “probing” ? Section 4 “This non-revertive behavior can also be optionally supported by an implementation and would be enabled through some configuration.” Is it a “MAY also be supported” ? What if there are more than two PEs connected to the source ? Section 4.1: “The normal and the standby C-multicast routes must have their Local” Is it a “MUST” ? It would be great to add a text talking about what happens if an implementation does not understand the standby community. “Note that, when a PE advertises such a Standby C-multicast join for an (C-S, C-G) it must join the corresponding P-tunnel.” Is it a “MUST” ? Section 4.2 How does it determine that C-S is not reachable through some other PE ? Section 4.4.2: Please you normative language. Security section: Please add some text/ IANA considerations: You need a request for the BFD attribute. You need to be more precise on the community request (from which registry is it taken from). I suppose that you are requested a Well-Known community. Please use upper case for the community name, it is more compliant with other name used.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
