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

From: "Lizhong Jin" <[email-masked]>
Date: Thu, 30 Jan 2014 01:11:59 +0800

Hi authors,

I review draft-ietf-l3vpn-mvpn-extranet-02, and have following questions. I
would appreciate if you could help to clarify.

Section 3.5.2. the word "EC" should be expanded when first used in the
document.

Section 3.5.2. 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?

Section 3.6. 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.

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.

Section 5.2.2

For IR P-Tunnel, the VRF-R needs to send I-PMSI A-D, and imported by VRF-S,
right?

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"? If it is extranet, tunnel
checking is still necessary, then there is still tunnel type restriction
(MP2P LSP could not be used).

Section 7.5

It would be valuable to say explicitly when tunnel checking will be enabled.
The C-flow with "extranet separation" EC should enable tunnel checking.

Regards

Lizhong