Hi John, You're spot on with all the points below. I have submitted -07 to address them: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-msdp-sa-interoperation-07.txt.
Thanks! Jeffrey -----Original Message----- From: John Scudder via Datatracker <[email protected]> Sent: Friday, May 14, 2021 10:30 AM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; Matthew Bocci <[email protected]>; mankamana mishra <[email protected]>; [email protected] Subject: John Scudder's No Objection on draft-ietf-bess-mvpn-msdp-sa-interoperation-06: (with COMMENT) [External Email. Be cautious of content] John Scudder has entered the following ballot position for draft-ietf-bess-mvpn-msdp-sa-interoperation-06: 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://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!NEt6yMaO-gk!S3O1rDSfiOzjUlEizB2V6P3TeJuNxlVD9pA4uWm2DWVtPn_h4lKifL7ETNjcI3OG$ for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-msdp-sa-interoperation/__;!!NEt6yMaO-gk!S3O1rDSfiOzjUlEizB2V6P3TeJuNxlVD9pA4uWm2DWVtPn_h4lKifL7ETGT9wxQb$ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this short document! I have a few questions and comments, below. 1. Section 3 The MVPN PEs that act as customer RPs or have one or more MSDP sessions in a VPN (or the global table in case of GTM) are treated as an MSDP mesh group for that VPN (or the global table). In the rest of the document, it is referred to as the PE mesh group. It MUST NOT include other MSDP speakers, and is integrated into the rest of MSDP On first reading I had difficulty following “it MUST NOT include other MSDP speakers“. You mean, MSDP speakers from another VPN, right? It didn’t come together for me until I reread it and realized the referent of “it“ is “the PE mesh group“. Anyway, this confused at least one reader, it might stand a little rewording. (Replacing “it” with “The PE mesh group” in the last sentence would do the trick.) 2. Section 3 In addition to procedures in [RFC6514], an MVPN PE may be provisioned to generate MSDP SA messages from received MVPN SA routes, with or without local policy control. If a received MVPN SA route is to trigger MSDP SA message, There are a couple things wrong with the preceding clause. First, it’s either missing an article before “MSDP” as in “trigger an MSDP SA message” or possibly “message” is supposed to be pluralized as in “trigger MSDP messages”. Second and more troublesome, that “if... is to trigger” seems wrong, that’s normally a construct which would introduce a precondition but that’s not what happens. Can you reword this? Do you mean “if a received MVPN SA route triggers an MSDP SA message”? it is treated as if a corresponding MSDP SA message was received from within the PE mesh group and normal MSDP procedure is followed (e.g. an MSDP SA message is advertised to other MSDP peers outside the PE mesh group). Your use of “e.g.”, meaning “for example”, implies other things could happen instead as a result of normal MSDP procedure, and this is just a for-instance. Right? Just checking. The (S,G) information comes from the (C-S,C-G) encoding in the MVPN SA NLRI and the RP address comes from the "MVPN SA RP-address EC" mentioned above. If the received MVPN SA route does not have the EC (this could be from a legacy PE that does not have the capability to attach the EC), the local RP address for the C-G is used. In that case, it is possible that receiving PE's RP for the C-G is actually the MSDP peer to which “The receiving PE’s” the generated MSDP message is advertised, causing the peer to discard it due to RPF failure. To get around that problem the peer SHOULD use local policy to accept the MSDP SA message. That sounds pretty gross considering the MSDP state is built dynamically (isn’t it?) but ok. An MVPN PE MAY treat only the best MVPN SA route selected by BGP route selection process (instead of all MVPN SA routes) for a given “The BGP route selection process” (C-S,C-G) as a received MSDP SA message (and advertise corresponding MSDP message). In that case, if the selected best MVPN SA route does “The corresponding” Juniper Business Use Only _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
