[bess] Benjamin Kaduk's No Objection on draft-ietf-bess-mvpn-msdp-sa-interoperation-07: (with COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 20 May 2021 01:25 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: bess@ietf.org
Delivered-To: bess@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6733A27AF; Wed, 19 May 2021 18:25:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org, bess-chairs@ietf.org, bess@ietf.org, Matthew Bocci <matthew.bocci@nokia.com>, mankamana mishra <mankamis@cisco.com>, mankamis@cisco.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.29.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <162147391648.3369.16543587448597687209@ietfa.amsl.com>
Date: Wed, 19 May 2021 18:25:17 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/TFLOU0uu7Vj4CCPD3GSapVZPzSE>
Subject: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-mvpn-msdp-sa-interoperation-07: (with COMMENT)
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 May 2021 01:25:17 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-bess-mvpn-msdp-sa-interoperation-07: 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: ---------------------------------------------------------------------- This looks like a nice, simple way to improve the interoperation scenarios. All my comments are relatively minor (and most are explicitly classified as nits). Section 2 Section "14. Supporting PIM-SM without Inter-Site Shared C-Trees" of [RFC6514] specifies the procedures for MVPN PEs to discover (C-S,C-G) via MVPN Source Active A-D routes and then send (C-S,C-G) C-multicast routes towards the ingress PEs, [...] Just to check my understanding: when we say "send (C-S,C-G) C-multicast routes toward the ingress PEs", does that refer to the "Source Tree Join C-multicast route"s that RFC 6514 describes? Would it be helpful to write it out using the same terminology? Section 3 When an MVPN PE advertises an MVPN SA route following procedures in [RFC6514] for the "spt-only" mode, it SHOULD attach an "MVPN SA RP- address Extended Community". [...] I don't really understand why this is only a "SHOULD". If the whole point of this document is to let MVPN S-A announcements get propagated out to MSDP, it seems required, and people who don't care about that scenario can ignore the document entirely; they don't need SHOULD vs MUST to get out of it. In addition to procedures in [RFC6514], an MVPN PE may be provisioned to generate MSDP SA messages from received MVPN SA routes, with or When would something that implements the rest of this document not be expected to generate MSDP SA messages in such a manner? (That is, why use "may be"?) Section 4 I'm always a little wary of claims of "no additional security considerations", though in many cases there are no *significant* new security considerations, even if there are some considerations that are new. In this case, we have the option of using the local RP address for the C-G when constructing a MSDP SA message (when the EC is not present in the MVPN SA NRLI), and since this causes different nodes in the MVPN to see different RPs for the group, it's not immediately clear that there are no relevant security considerations from having different views of the RP. What is the behavior when different nodes are using different RPs? (There is also the fact that the address of the RP is now sent to a larger population by virtue of being in the new BCP EC, which should cause us to consider if there are any privacy considerations from the broadedend information distribution. I don't see anything noteworthy, though.) RFC 6514's security considerations section mentions (by section number, not name) that for the spt-only mode implementations should have an upper bound on the number of SA A-D routes. IIUC, the mechanisms in this document do not change relative resource consumption in a way that might require the specific value of the upper bound to change, but please confirm. The security considerations for RFC 3618 mandate implementation of TCP-MD5, which is a bit dated. Should we say anything about TCP-AO (RFC 5925) here? Section 7.2 While RFC 3618 is not specifically cited in any location that would require it to be classified as normative, I think that it should be classified as normative, and thus presumably that more references to it should also be added where the normative use of MSDP is mentioned in the text. NITS Section 1 Familiarity with MVPN and MSDP protocols and procedures is assumed. Some terminologies are listed below for convenience. References for MVPN and MSDP would go well here. Section 2 similar to MSDP Source-Active messages [RFC3618]. For a VPN, one or more of the PEs, say PE1, either act as a C-RP and learn of (C-S,C-G) via PIM Register messages, or have MSDP sessions with some MSDP peers and learn (C-S,C-G) via MSDP SA messages. [...] Since we specified "say PE1", we should probably take the "one" branch of "one or more" and use "has" and "learns" for singular/plural agreement. corresponding (C-*,C-G) state learnt from its CE. PE2 may also have MSDP sessions for the VPN with other C-RPs at its site, but [RFC6514] does not specify that it advertises MSDP SA messages to those MSDP I suggest s/it/PE2/ just to avoid any doubt. which are redundant and unnecessary. Also notice that the PE1-PE2 MSDP session is VPN-specific, while the BGP sessions over which the MVPN routes are advertised are not. I suggest s/VPN-specific/used only for a single MVPN/ o VPN extranet mechanisms can be used to propagate (C-S,C-G) information across VPNs with flexible policy control. Is RFC 7900 a good reference for "VPN extranet"? I had to look it up... contain the source and group. MSDP requires the RP address information in order to perform peer-RPF. Therefore, this document I'd suggest expanding RPF on first use. Section 3 attach the EC), the local RP address for the C-G is used. In that case, it is possible that the receiving PE's RP for the C-G is actually the MSDP peer to which the generated MSDP message is I suggest s/receiving PE's RP/RP inserted into the MSDP SA message/. from before. The previously advertised MSDP SA message with the older RP address will be timed out. I guess technically it's the state that the older message induced that times out, not the message itself. direction - upon receiving an MVPN SA route in a VPN generate corresponding MSDP SA and advertise to MSDP peers in the same VPN. "generate a"; "advertise it"
- [bess] Benjamin Kaduk's No Objection on draft-iet… Benjamin Kaduk via Datatracker
- Re: [bess] Benjamin Kaduk's No Objection on draft… Jeffrey (Zhaohui) Zhang