Thank you for reviewing this draft; I know it's not an easy read!
> Section 3.5.2. [3.4.2 in -03 rev] the word "EC" should be expanded when
> first used in the document.
Correct, will fix.
> Section 3.5.2. [3.4.2 in -03 rev] what's the purpose to advertise Extranet
> Source Extended Community? I understand the first PE receives the Extranet
> Source EC will allocate proper RT to the UMH-eligible route, but what will
> other PE do when receiving route with or without Extranet Source EC? Are
> they the same?
Good question.
We were concerned about the case where there is a multi-AS extranet MVPN
with "option (a) interconnect" (see RFC4364 section 10) somewhere. In an
option (a) interconnect, two PEs are connected via a VRF interface, and each
treats the other as if it were a CE. So VPN-IP routes are converted to IP
routes and then back again. So in a scenario like:
CE1---PE1---...---PE2---(option a)---PE3
The RTs that PE1 puts on a VPN-IP route are stripped off by PE2 when PE2
converts that VPN-IP route an IP route, before distributing it to PE3. If
CE1 put an Extranet Source extended community on that route, we wanted that
extended community carried all the way to PE3, so that PE3 can put on the
appropriate extranet RTs.
> Section 3.6. [3.5 in -03 rev] what is the requirement for "extranet
> separation", MAY, SHOULD or MUST be used in this draft? From my
> understanding, it SHOULD or MUST be used for I-PMSI or S-PMSI (C-*, C-*),
> otherwise, the egress PE does not know whether to do tunnel checking.
If extranet separation is used, I think that section makes it clear just
when the Extranet Separation extended community is needed.
I think the draft also makes it clear that extranet separation is "optional
to deploy". The draft doesn't state whether it is "optional to implement"
as well.
At least one of the authors believes that extranet separation is not of much
value at all, and is at best an optimization/complication whose
implementation should not be required. On the other hand, at least one of
the authors believes that there are circumstances in which extranet
separation may significantly reduce the amount of multicast traffic tunneled
to PEs that don't have receivers for that traffic.
> From my understanding, it SHOULD or MUST be used for I-PMSI or S-PMSI
> (C-*, C-*), otherwise, the egress PE does not know whether to do tunnel
> checking.
I assume that by "tunnel checking" you mean "discarding packets that arrive
on a tunnel other than the expected one".
The use of extranet separation is not a sufficient condition for avoiding
tunnel checking, because it does not eliminate the ambiguity described in
section 2.2. Also, if an implementation always does tunnel checking, it
doesn't have to determine whether tunnel checking is required in some
particular case. So I don't think extranet separation should be a MUST or
SHOULD, in which case the use of the Extranet Separation extended community
is not a MUST or a SHOULD either.
> Section 7.5
> It would be valuable to say explicitly when tunnel checking will be
> enabled.
Section 7.5 should have a pointer to section 2.2, which gives the conditions
under which tunnel checking can be omitted.
> Section 4.1.2.
"If VRF-S does not contain both extranet C-sources and non-extranet
C-sources, this condition holds automatically."
> Should the above be: If VRF-S does not contain extranet C-sources or
> non-extranet C-sources, this condition holds automatically.
The condition being referenced is:
"Traffic from extranet C-sources MUST NOT be carried in the same
P-tunnel as traffic from non-extranet C-sources."
I think it's okay as written; unless a VRF has both extranet C-sources and
non-extranet C-sources, it can't put both extranet C-flows and non-extranet
C-flows in a given tunnel.
> Section 5.2.2
"If it is desired to support extranet while also using IR to
instantiate the PMSIs, an alternative is to use (C-*,C-*) S-PMSIs
instead of I-PMSIs."
> Should the above "extranet" be "non-extranet"?
No, "extranet" is what is intended.
> If it is extranet, tunnel checking is still necessary, then there is still
> tunnel type restriction (MP2P LSP could not be used).
Please see draft-rosen-l3vpn-ir-00.txt ("Ingress Replication Tunnels in
Multicast VPN"), especially section 6. This explains how the tunnel
checking works when MP2P LSPs are used as the unicast tunnels.
Please let me know if I have misunderstood any of your questions (or if you
don't like any of my answers ;-)).
