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 protected]] > Sent: Tuesday, February 11, 2014 12:39 AM > To: Lizhong Jin > Cc: [email protected]; Thomas Morin; > [email protected]; [email protected] > Subject: Re: Review of draft-ietf-l3vpn-mvpn-extranet-02 > > > 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. [Lizhong] got it, thanks. > > > 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. [Lizhong] OK, now I understand it better. > > > 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. [Lizhong] understand, and suggest to change: If VRF-S contains only extranet C-sources or non-extranet C-sources, this condition holds automatically. > > > 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 ;-)). [Lizhong] thanks. > > > >
