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
