Subject: Re: Review of draft-ietf-l3vpn-mvpn-extranet-02

From: Eric Rosen <[email-masked]>
Date: Mon, 10 Feb 2014 11:38:49 -0500

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 ;-)).

---

From: "Lizhong Jin" <[email-masked]>
Date: Wed, 12 Feb 2014 23:37:39 +0800

Hi Eric,
Thank you for the explanation, now I understand better.
Then I have two text suggestions, and try to make the draft to be more clear.
1. Could we have the "tunnel checking condition" context at the end of section 2.2 in another separate section after section 2. Because this mechanism is both valid for case of section 2.1 and 2.2.
2. Move section 4 before section 3. Because section 3, 5, 6, and 7 are signaling related, while section 4 gives out solution related.
Others, see inline below.

Regards
Lizhong

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Tuesday, February 11, 2014 12:39 AM
> To: Lizhong Jin
> Cc: [email-masked]; Thomas Morin;
> [email-masked]; [email-masked]
> Subject: Re: Review of draft-ietf-l3vpn-mvpn-extranet-02
> 
> 
[Lizhong] got it, thanks.

> is not a MUST or a SHOULD either.
[Lizhong] OK, now I understand it better.

> C-flows in a given tunnel.
[Lizhong] understand, and suggest to change: If VRF-S contains only extranet C-sources or non-extranet C-sources, this condition holds automatically.

> don't like any of my answers ;-)).
[Lizhong] thanks.