Comments on draft-ietf-l3vpn-mvpn-bidir-06

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Eric,

Please see comments below. Some are just editorial nits.

1.2.2. Reasons for Using Bidirectional P-tunnels

   (It must be noted though that this
   particular use of bidirectional P-tunnels is not compatible with the
   duplicate prevention scheme of [MVPN] section 9.1.1, and thus would
   only be used if the duplication prevision schemes of [MVPN] sections
   9.1.2 or 9.1.3 are suitable.)

The concept of using PE Distinguisher label to create an inner tunnel that is on top of the outer bidir tunnel is introduced later in the sections. Before then, it is better not to say the above, because with the PE Distinguisher label it can use [MVPN] section 9.1.1 to discard duplicate traffic.

   These two reasons for using bidirectional P-tunnels are somewhat in
   conflict with each other, since ...

s/are/seem to be/ ? They are not really conflicting, for the reason you gave.

   An SP may decide to use bidirectional P-tunnels for either or both of
   these reasons.
   ...
   Note that even if the reason for using bidirectional P-tunnels is to
   provide C-BIDIR support, the same P-tunnels can also be used to carry
   unidirectional C-flows, if that is the choice of the SP.

The above two separate paragraphs would go better if together.

       The Partitioned Method is a pre-requisite for implementing the
       "Partitioned Sets of PEs" technique of supporting C-BIDIR, as
       discussed in [MVPN] section 11.2.

       The Flat Partitioned Method is a pre-requisite for implementing
       the "Partial Mesh of MP2MP P-tunnels" technique for carrying
       customer bidirectional (C-BIDIR) traffic, as discussed in [MVPN]
       Section 11.2.3.

Perhaps add the following two paragraphs to between the above two paragraphs?

       The Partitioned Method is a pre-requisite for implementing the
       "Discarding Packets from Wrong PE" technique as discussed in
       [MVPN] Section 9.1.1.

       The Hierarchical Partitioned Method is a pre-requisite for
       Implementing the "Using PE Distinguisher Labels" technique for carrying
       customer bidirectional (C-BIDIR) traffic, as discussed in [MVPN]
       Section 11.2.2.

----------------

   The Flat Partitioned Method may be used to instantiate the following
   types of PMSI: I-PMSI, (C-*,C-*) S-PMSI, (C-*,C-BIDIR) S-PMSI, or
   (C-*,C-G) S-PMSI where C-G is a bidirectional C-group.

Why not (C-*,C-G) where C-G is unidir? Why not (C-S,C-G) and (C-S,C-*) S-PMSIs? Imagine a provider that only uses PIM-Bidir in its core?

   I-PMSI, a PE MUST originate an Intra-AS I-PMSI A-D route if one if
   its VRF interfaces is the next hop interface on its best path to the
   C-RPA of any bidirectional C-group of the MVPN.

s/one if/one of/

Perhaps it is good to define a (C-*,C-G-BIDR) term. Currently you say "(C-*,C-G) S-PMSI where C-G is a bidirectional C-group" but the "where..." part is not always included, even when it should be. For example:

   When the Flat Partitioned Method is used to instantiate a (C-*,C-*)
   S-PMSI, a (C-*,C-BIDIR) S-PMSI, or a (C-*,C-G) S-PMSI, a PE that
   originates the corresponding S-PMSI A-D route MUST include in that
   route a PTA specifying a bidirectional P-tunnel.  Per the procedures
   of [MVPN] and [MVPN-BGP], a PE will originate such an S-PMSI A-D
   route only if one of the PE's VRF interfaces is the next hop
   interface of the PE's best path to the C-RPA of a C-BIDIR group that
   is to be carried on the specified S-PMSI.

It would be easier to simply say (C-*,C-G-BIDR).

3.2.1.2. When an I-PMSI is a 'Match for Transmission'

   ...
   Note that if a VRF is configured to provide C-BIDIR support using the
   Flat Partitioned Method, but there is no matching S-PMSI A-D route
   (according to section 3.2.1.1) and there is no such I-PMSI A-D route
   meeting the conditions of this section, then a provisioning error has
   occurred, and the C-flow will not be transmitted.

Maybe the above paragraph can be simplified as:

   If there is no I-PMSI A-D route meeting the above conditions, the C-flow
   must not be transmitted.

The reason are the following:

- The omitted text is basically the context here. Listing them explicitly actually adds burden for people to digest/correlate.
- it may not be a provisioning error but simply that such I-PMSI A-D route has not been received (transient condition).

Same with the last paragraph of 3.2.2.3.

3.2.1.3. When an S-PMSI is a 'Match for Reception'

   ...
   If there is an S-PMSI A-D route matching (C-*,C-G), according to
   these rules, its PTA must specify a bidirectional P-tunnel.

Does the "must" in the above paragraph indicates a fact or a requirement? If it's a fact, maybe change "must specify" to "must have specified". If it's a requirement, it should be put into the individual rules like in the transmit case, so that we don't pick a route that does not specify a bidir tunnel.

3.2.1.4 seems to be just an add-on situation after failing to find a (C-*,C-*) S-PMSI A-D route. Separating into two sections instead of just doing a single "When a PMSI is a match for reception" adds burden for people to follow.

Same question on the transmission side (3.2.1.1 and 3.2.1.2).

3.2.2. Hierarchical Partitioning
   ...
   The PEs that are required to originate the routes mentioned in the
   previous paragraph are those that satisfy one of the following
   conditions:
     ...
     - The PE might have to transmit customer multicast traffic on the
       PMSI identified in the route,

s/multicast traffic/unidirectional multicast traffic/

   The Hierarchical Partitioned Method may be used to instantiate an
   I-PMSI, a (C-*,C-*) S-PMSI, or a (C-*,C-BIDIR) S-PMSI. ...

   If (and only if) C-G is a C-BIDIR group, the Hierarchical Partitioned
   method may be used to instantiate the (C-*,C-G) S-PMSI.  In this
   case, when a (C-*,C-G) S-PMSI A-D route is originated, it is
   originated only by a PE whose best path to the C-RPA for C-G is via a
   VRF interface, and that PE MUST be the root node of the MP2MP LSP
   identified in the PTA of the A-D route.

(C-*,C-BIDIR) and (C-*,C-G-BIDIR) should be the same, but why are they separated in the text? The text before the above paragraph allows that a different PE could be the root of the mp2mp tunnel, but why is the same not allowed for (C-*,C-G-BIDIR)? In fact, 3.2.2.4 seems to allow that.

Why can't (C-*,C-G-UNIDIR) PMSI be instantiated with Hierarchical Partitioned method?

   As in [MVPN] and [MVPN-BGP], an S-PMSI A-D route does not need to be
   originated by a particular PE, say PE1, until PE1 has received a
   "join" indicating that some other PE is interested in receiving
   customer multicast traffic forwarded from PE1.

In bidir case, traffic may not be from PE1 at all, so may be rewording the last two lines of the above paragraph to the following:

   "join" from some other PE.

--------------

   The Hierarchical Partitioned method MUST NOT be used to instantiate a
   (C-S,C-G) or a (C-S,C-*) S-PMSI.

Why is the above restriction put in place? If there is a bidirectional tunnel whose leave set happen to match (or just slightly over cover) the (C-S,C-G) or (C-S,C-*) receiver PEs, why can't that tunnel be used?

   If the "partitioned sets of PEs" method of supporting C-BIDIR is
   used, as discussed in section 11.2 of [MVPN] and section 3.6 of
   [RFC6517], C-BIDIR flows MUST NOT be carried on a P-tunnel specified
   in the PTA of a (C-S,C-G) or a (C-S,C-*) S-PMSI.

This should be moved out of this section (hierarchical partitioned) because it applies to both partitioned method. I also wonder if the restriction applies to unpartitioned method - the spec does not say. Is it because C-BIDIR forwarding is never based on source (hence the restriction applies to unpartitioned method as well) or does it have anything to do with the methods?

   The PE Distinguisher Labels attribute specifies a set of <MPLS label,
   IP address> bindings.  Each IP address is the IP address of a PE
   router that is expected to receive the route that contains the
   attribute.

It really is that "Each IP address is that of a PE router that may be a Distinguished PE", right?

   When a PE Distinguisher Labels attribute is included in a given
   I-PMSI or S-PMSI A-D route, it MUST assign a label to the IP address
   of each of the following sets of PEs:

     - The root node of the MP2MP LSP identified in the PTA of the
       route,

     - Any PE that may need to transmit non-C-BIDIR traffic on the MP2MP
       LSP identified in the PTA of the route.  This requirement can be
       met by assigning a label to every PE that has originated an
       Intra-AS I-PMSI A-D route. However, if it is known apriori that
       all the non-C-BIDIR sources are in sites attached to only a
       subset of the PEs, PE Distinguisher labels can be specified for
       that subset alone.

What about the Upstream PEs wrt C-BIDIR C-RPAs, especially in the case of (C-*,C-BIDIR) S-PMSI?

3.2.2.3. When an I-PMSI is a 'Match for Transmission'

For c-bidir, in S-PMSI case, a matching S-PMSI originated by any PE can be used; in I-PMSI case, only the one advertised by the upstream PE wrt C-RPA can be used. Why? I think S-PMSI should also require that the one from the upstream PE is used - otherwise an S-PMSI from a different partition may be picked.

3.2.2.5. When an I-PMSI is a 'Match for Reception"

   ...  When
   the Hierarchical Partitioned Method is used, each Intra-AS I-PMSI A-D
   routes of the MVPN will have a PTA, and all such PTAs will specify
   the same bidirectional P-tunnel.

The above text should be moved to section 3.2.2 (before the subsections), and change "will" to SHOULD/MUST.

Or could we delete it entirely? We discussed before that all such PTAs SHOULD specify the same tunnel to simplify the forwarding logic on the receiving PEs. But now I don't even see how it complicates forwarding logic if they don't specify the same tunnel. For a particular unidir c-flow we use the tunnel advertised in the upstream PE's I-PMSI and program the forwarding logic accordingly; for a particular c-g-bidir we use the tunnel advertised in the I-PMSI from the upstream PE wrt the C-RPA and program the forwarding logic accordingly (this matches 3.2.2.3) - no multiple choices.


3.2.3.1. When an S-PMSI is a 'Match for Transmission'
   ...
     - Otherwise, if there is an S-PMSI A-D route currently originated
       by PE1, whose NLRI contains (C-*,C-BIDIR), and if C-G is a BIDIR
       group, the (C-S,C-G) C-flow matches that route.

For a C-G-BIDIR, an implementation may not know about C-S at all, so saying (C-S,C-G) is not accurate.

Additionally, the rules require that the S-PMSI A-D route originated by the transmitting PE is used. I don't see why a route originated by another PE cannot be used for C-G-BIDIR, especially when we're using procedures of [MVPN] section 11.1? In fact, the rules for 'Match for Reception', which are the rules in 3.2.2 of [MVPN-WILDCARD] with the last paragraph modified, show that any (C-*,C-G-BIDIR) S-PMSI A-D route can be used, and that may not be the transmitting PE.

3.2.3.2. When an S-PMSI is a 'Match for Reception'
   ...
   This is changed to:

       "If (C-*,C-G) does not match a (C-*,C-G) S-PMSI A-D route from
       PE2, but C-G is a BIDIR group and PE1 has an installed
       (C-*,C-BIDIR) S-PMSI A-D route, then (C-*,C-G) matches that
       route. ...

This also shows that any (C-*,C-BIDIR) S-PMSI A-D route can be a match.

Thanks.
Jeffrey