Subject: [bess] John Scudder's No Objection on draft-ietf-bess-mvpn-msdp-sa-interoperation-06: (with COMMENT)

From: John Scudder via Datatracker <[email-masked]>
Date: Fri, 14 May 2021 07:29:38 -0700

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://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-msdp-sa-interoperation/

----------------------------------------------------------------------
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”

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 19 May 2021 18:51:26 +0000

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-masked]>
Sent: Friday, May 14, 2021 10:30 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Matthew Bocci <[email-masked]>; mankamana mishra <[email-masked]>; [email-masked]
Subject: John Scudder's No Objection on draft-ietf-bess-mvpn-msdp-sa-interoperation-06: (with COMMENT)

[External Email. Be cautious of content]

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$

1. Section 3

2. Section 3

“The receiving PE’s”

“The corresponding”

Juniper Business Use Only