*Co= nsider carefully whether you should click on any links, open any attachment= s or reply.* *Fo= r information regarding* · This message originates from outside our organ= isation, either from an external partner or the internet.

Although Virtual Private Multicast Service (VPMS)<=
o:p>
   [VPMS] or Point-to-Multipoint=
 (P2MP) multicast is a somewhat
   simplif=
ied version of this service, in fact, there is no exact<=
/pre>=0A&nb=
sp;  corresponding terminology in IETF yet.<=
/pre>=0A=
I could not understand why you say the "terminology" here refer to E-Tree.=
=0A[JY2]=0A To be clea=
r, rewrite the 2^nd part as =E2=80=9C=E2=80=A6, in fact, they ar=
e both multicast services and are different from an E-Tree service which m=
ay include both=0A unicast and multicast traffic=E2=80=9D.
=0A
=0A=0A6.<=
/span>    &=
nbsp; =0ASection3: =
=E2=80=9CThough th=
ere were proposals on using PW control word or PWs to indicate the root/le=
af attribute of an E-Tree frame, both methods are limited in that=0A they =
are only applicable to "VPLS only" networks.=E2=80=9D You should have reference for other proposals. But I don=E2=
=80=99t think you need to list these proposals, inste=
ad only say the motivation of the VLAN based solution.
=0A[JY] Both references were listed in the older versions of=
 this draft indeed. Since there=0A had been quite a lot of emails exchange=
d over these proposals before the WG adoption of this draft, this sentence=
 simply reflects a summary of the conclusions. We can remove it in the nex=
t revision if the WG thinks it appropriate.
=0A[Lizhong] OK.
=0A 
=0A7.      =0ASection4.1: =
=E2=80=9CFig. 1 and Fig. 2 (both figures are extracte=
d from [RFC6246])=E2=80=9D. You should switch =
the number of Fig1 and Fig2, since Fig1=0A is a detail description of Fig2=
.
=0A[JY] Not exactly, Fig.1 is not just a=
 block of Fig. 2, it also describes CE access which=0A is not shown in fig=
.2. Moreover, the order of CEs, the bridge and the VSI as they appear in F=
ig.1 and Fig.2 is also more consistent with their network topology. Howeve=
r, if we swap Fig.1 with Fig.2, then Fig.1 will forward reference to Fig.2=
, and this would=0A be another disadvantage. 
=0A[Lizhong] Please refer=
 to RFC6246. And let WG to decide. Thanks.
=0A <=
/p>=0A
8.  =
    =0ASection4.1: =E2=80=9CTherefore, the association between an AC port and a PW on a VSI is d=
ifficult, sometimes even impossible.=E2=80=9D =
Could not understand=0A what=E2=80=99s the pur=
pose of this sentence here?
=0A[JY] It is=
 proposed to update it with:
=0A"Therefore, the association between an AC=
 port and a PW on a VSI without using any VLAN=0A is difficult, sometimes =
even impossible."
=0A[Lizhong] still not agree. VLAN is not mandotary for=
 the association. There are many implementations=0A for VPLS to have the a=
ssociation without VLAN, e.g., virtual/physical port. I could not see the =
"difficult" here.
=0A[JY2] To resolve the concern, it is proposed to remo=
ve =E2=80=9C, sometimes even impossible=E2=80=9D from the sentence.
=0A(It should be noted that this paragraph does not man=
date anything; and in Ethernet, a virtual port itself is usually implement=
ed as VLAN;  using=0A physical ports for internal connections in a de=
vice is not a common practice).
=0A 
=0A9.=
      =0ASection4.1: =E2=80=9C<=
span lang=3D"EN-US">Assuming this mechanism is implemented in the bridge m=
odule, it is quite straightforward to infer a VPLS PE model with two VSIs =
to support the E-Tree=0A (as shown in Fig. 3).=E2=80=9D Could move the analysis to motivation section, or removed. And=
 the logic here is not right. The leaf/root VLAN indication is only for fi=
ltering, not bridging. So it is not accurate to have Root/Leave S-VLAN=0A =
here to get the enhanced model.
=0A[JY] So=
rry, I am not sure I understand your reasoning here. It is already a stand=
ardized=0A mechanism to encapsulate and switch an E-Tree service into two =
VLANs by a bridge according to IEEE 802.1Q-2011. Here is the only enhancem=
ent: a root VLAN is connected to a root VSI and all the root VSIs in peer =
PEs constitute one VPLS instance (with one mesh=0A of PWs), and a leaf VLA=
N is connected to a leaf VSI and all the leaf VSIs constitute another VPLS=
 instance (with another mesh of PWs), both VPLS instances are transparent =
to the E-Tree traffic, and all the filtering operations are done on the br=
idge according=0A to the IEEE 802.1Q mechanism (that is, VSIs do not need =
to filter any leaf traffic).
=0A[Lizhong] I mean your inferring is not ri=
ght. In RFC6246,=0A it says:<=
/span>=0A=
The bridge
=0A   module has a single "Emulated LAN" interface over which it
=0A   communicates with all VPLS forwarders, and each VPLS=
 instance is
=0A   represented by a unique S-=
VLAN tag.
=0AThat is the S-VLAN is used to indentify VLAN instan=
ce. But now S-VLAN=0A is used to only identify E-Tree attribute, then it is =
not right to apply 802.1ad bridge mode to illustrate E-Tree mode.
=0A[JY2=
] I think there is some misunderstanding here, S-VLANs for E-Tree is not d=
ifferent from S-VLANs for other services (for example, E-LAN). In=0A IEEE =
802.1, the only requirement is that two unique S-VLAN values are used (one=
 used for root traffic forwarding, and the other used for leaf traffic for=
warding); and the two unique S-VLAN values aforementioned can each represe=
nt a VPLS instance (just as described=0A in RFC 6246). It is also noted in=
 the document =E2=80=9Cboth these VSIs have to share their learned MAC add=
resses=E2=80=9D in page 7. VSIs forward E-Tree traffic just like a normal =
VPLS service and all E-Tree filtering happens in the bridge module.
=0A 
=0A10.  =0ASection4.2: =E2=80=9Cand optionally MAY be added with another ro=
ot S-VLAN.=E2=80=9D When and why add another r=
oot S-VLAN here? And why use terminology=0A=E2=80=9Croot S-VLAN=E2=80=9D, not root VLAN as i=
ndicated in Figure4?
=0A[JY] Figure 4 is=
 a generalized diagram, where VLAN may be a C-VLAN, S-VLAN or B-VLAN, the=
=0A texts in Section 4.2 describe each cases of specific VLANs respectivel=
y.=
=0AIt is proposed to update the 1st sentence "In order to support the =
E-Tree in a more scalable=0A way..." in Section 4.2 with:
=0A"In order =
to support the E-Tree in a more generic and more scalable way..."
=0A[Liz=
hong] A word "generic" does not solve the problem. Since you lis=
t the possibility to=0A add one root C-VLAN and another root S-VLAN, I nee=
d to understand the scenario why we need that. The strange thing is, at th=
e end of this section:
=0AIn all cases, the out=
ermost VLAN in the resulted Ethernet header is=0A<=
pre style=3D"margin: 0cm 0cm 0.0001pt; page-break-before: always; font-siz=
e: 12pt; font-family: =E5=AE=8B=E4=BD=93;">  =
 used to indicate the E-Tree attribute of an Ethernet frame; this
=0A   document uses VLAN to refer to this oute=
rmost VLAN for simplicity in
=0A   the latter=
 sections.
=0AThen why we should add the first =
root C-VLAN?<=
/span>
=0AAnd you should use same terminology across the document. =
And what's the different among=0A "Root VLAN", "Root C-VLAN", "Root S-VLAN=
", "Root B-VLAN", and same question to leaf?
=0A[JY2] Similar to the I=
EEE terminology (a generic VLAN may be a C-VLAN, S-VLAN or B-VLAN),=0A a Root VLAN may be a "Root C-VLA=
N", "Root S-VLAN", or "Root B-VLAN", the same applies to leaf VLAN. We wil=
l further clarify it in the terminology section by adding =E2=80=9Cit=0A may be a C-VLAN, an =
S-VLAN or a B-VLAN=E2=80=9D to the definition of =E2=80=9CRoot VLAN=
=E2=80=9D and =E2=80=9CLeaf VLAN=E2=80=9D, that is:=0A=0A
=0A=E2=80=9C  =0ARoot VLAN: a VLAN ID used to indicate all the frames that are=
=0A  =0Ao=
riginated at a root AC, it may be a C-VLAN, an S-VLAN or a B-VLAN=E2=80=9D<=
/span>
=0APlease note that an 802.1ad bridge module may co-exist wi=
th 802.1Q bridge modules in the same PE (as shown in Fig.2 in RFC 6246), a=
nd both root=0A C-VLAN and root S-VLAN may be used at the same time, so th=
at seamless convergence can be realized (e.g., when 802.1Q bridges co-exis=
t with 802.1D bridges in the same customer network and be attached to this=
 PE).=0A
=0ATo be clear, it is proposed to replac=
e the 2^nd paragraph in Section 4.2 with:=
=0A=E2=80=9CFor an untagged port (frames over this port are untagged) =
or VLAN-unaware port (VLAN tags in the frames are ignored),=0Awhen the bridge module is a C-=
VLAN bridge, the Ethernet frames received from the root ACs SHOULD =
be tagged with a root C-VLAN=0Aand optionally MAY be added with another=
 root S-VLAN; w=
hen the bridge module is an 802.1ad bridge, the Ethernet frames received f=
rom the root ACs SHOULD be tagged with a root S-VLAN (it can be added=0A w=
ith a root C-VLAN firstly but this is out of the scope of this document). =E2=80=9C
=0A =
=0A11.  =
=0ASection4.2: =E2=80=9CFor an S-VLAN tagg=
ed port, the S-VLAN tag in the Ethernet frames received from the root ACs =
SHOULD be translated to the root S-VLAN in the VPLS network=0A domain=E2=80=9D. The description of S-VLAN tagged port is=
 not accurate here. I think here, you want to refer to a port receiving a =
packet with both S-VLAN & C-VLAN. So it is better to say,=0A=E2=
=80=9Cwhen receiving a packet with both S&C VLAN<=
/span>=E2=80=A6=E2=80=9D. Same suggestion to previous=
 paragraphs.=0A
=0A[JY] This is not what =
we want. There are implementations in the industry that supports encapsula=
tion=0A of all traffics from a port into an S-VLAN (BBF TR-101 also specif=
ies such a behavior). So no change is needed here.
=0A 
=0AIf S-VLAN only packet received, still translate S-VLAN to=
 root S-VLAN?
=0A<=
span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:"Calibri&qu=
ot;,"sans-serif";color:#1F497D">[JY]  Yes, some SPs may pre=
fer to use such an S-VLAN translation in their networks for ease=0A of man=
agement. This was also discussed in the L2VPN WG before and a consensus wa=
s reached.
=0A[Lizhong] Then I could not agree you use "SHOULD" to mand=
atory the translation. It is not=0A necessary to do translation for S-VLAN=
 only packet in many cases. Could WG chair confirm the consensus Yuanlong =
refers to.
=0A[JY2]  Maybe the previous L2VPN chairs has something=
 to say since all those details were discussed in L2VPN WG as early as in =
2012. I have no strong=0A opinion to change =E2=80=9CSHOULD=E2=80=9D to =
=E2=80=9CMAY=E2=80=9D, but it would be better to give a preference when se=
veral options are given.
=0A 
=0A12.&nbs=
p; =0ASection4.2: <=
/span>=E2=80=9Cthe E-Tree=
 attribute may also be indicated with two I-SID tags in the bridge module<=
/span>=E2=80=9D. Suggest to remove since it is not=0A=
 part of this document.
=0A[JY] As I rem=
ember, this note was added to resolve a comment raised in the L2VPN WG mai=
ling=0A list, and it was accepted into the document with no objection. Thi=
s note is totally informational, and I am not sure it is appropriate to de=
lete it.
=0A[Lizhong] You describe the brief method, but does not provide=
 the detail. My concern is,=0A if there is future document to describe E-T=
ree for PBB-VLAN, and basic method is different with this document, then t=
here will be conflict. 
=0A[JY2] Both Don & Dave mentioned =
this approach as a valid option (in=0Ahttp://www.ietf.org/mail-archive/web/l2vpn/current/msg03433.=
html=0A and http://www.ietf.org/mail-ar=
chive/web/l2vpn/current/msg03365.html respectively),=0A and this parag=
raph was added in the E-Tree I-D before the WG adoption. IMO, this is info=
rmational and is useful, but let the WG decide it.=0A=
=0A=

=0A13.  =0ASection5.2: =E2=80=9CFor both methods, VLAN mapping parameters from a remote PE can be =
provisioned or determined by a signaling protocol as described in Section =
6 when=0A a PW is being established=E2=80=9D. =
For the global method, why we need signaling?=
=0A[JY] Just as the sentence says, the global VLAN method does not rel=
y on signaling for its=0A work.
=0ABut the SPs may prefer to use one meth=
od (e.g., global VLAN based) in scenario A and the=0A other method (e.g., =
local VLAN based) in scenario B, and they would like to keep both methods =
work in a similar way, so the signaling protocol was designed to be applic=
able in both methods to give them a similar operation experience (if signa=
ling is supported).=
=0A[Lizhong] I don't agree, what if deploying only gl=
obal mode? You are talking about the operational=0A experience, but I am t=
alking about the technology. It is very confusing for the readers.<=
span lang=3D"EN-US" style=3D"color:black">
=0A[JY=
2] Firstly, signaling for global method is not mandatory. Secondly, when c=
ontrol plane is needed, it is simple to implement if the same signaling=0A=
 can be used in both cases. BTW, even in the global mode, we may save some=
 work in configuration if we have signaling capability (thus we only need =
to configure two VLAN values per router).=0A
=0A<=
o:p> 
=0A14.  =0ASection5.3.1: =E2=80=9Ci.e., the local leaf VLAN in a frame is translated to the remot=
e leaf VLAN; the local root VLAN in a frame is translated to the remote ro=
ot VLAN=E2=80=9D.=0A Here you should refer bac=
k to section 4.
=0A[JY] At the end of Sec=
tion 4, it already says:=
=0A"  In all cases, the outermost VLAN in t=
he resulted Ethernet header is
=0A   used to indicate the E-Tre=
e attribute of an Ethernet frame; this
=0A=
   document uses VLAN=
 to refer to this outermost VLAN for simplicity in
=0A   the la=
tter sections."
=0ASince there are dozens of "VLAN"s in section 5 & 6=
 ("the latter sections" aforementioned),=0A referring to Section 4 for eac=
h use of VLAN is thus both unnecessary and cumbersome.  =0A
=0A=
[Lizhong] But here is "local leaf VLAN" and "remote leaf VLAN", if I expan=
d, they will change=0A to "local lea=
f outermost VLAN" and "remote leaf outermost VLAN". Then questio=
n is what is the "remote leaf outermost VLAN"?
=0A[=
JY2] No, we did not hint such a expansion. The E-Tree VLAN is generic (it =
may be C-VLAN, S-VLAN or B-VLAN), and actually indicated by the outermost=
=0A VLAN. See comment 10 for the terminology clarification.
=0A 
=0A15.  =0ASection5.3.2: =
=E2=80=9CUpon receiving frames on the PW, add a VLAN =
tag with a value of the local root VLAN to the frames.=E2=80=9D Not understand here.=0A Does that mean all receiving fra=
mes will be considered to be from root? Then how to isolate traffic betwee=
n two leaves?
=0A[JY] Yes, all the rece=
ived frames from the PW will be from roots. As the 1st paragraph in=0A thi=
s section already says:"the VPLS PE with a traditional VSI can only be att=
ached with root nodes."<=
o:p>
=0A[Lizhong] OK.
=0A =
=0A16.  =
=0ASection5.3.3: =
=E2=80=9CIf a PE is in th=
e Optimized Mode for a PW, upon transmit=E2=80=9D. Suggest to: If a PE is in the Optimized Mode for a PW, upon=0A transm=
it to leaf only nodes.
=0A[JY] As it alrea=
dy says in the 1st paragraph of Section 5.3.3, a PE works in Optimized Mod=
e=0A for a PW only when its peer PE is attached with only leaf nodes. Why =
add this condition again (in implementation, you need an extra data plane =
operation to determine whether this condition is met, furthermore, it is d=
ifficult to determine whether a destination=0A node is a root or leaf in t=
he data plane)?
=0A[Lizhong] no, by signaling, the dataplane should know =
the remote PE is leaf only or not.=0A What I mean is, the drop operation i=
s only valid for leaf-only nodes.
=0A[JY2] this is always true, so the co=
ndition is not needed in the data plane. To be clear, it is proposed to up=
date the 1st sentence in Section=0A 5.3.3 =E2=80=9DWhen two PEs (both have=
 E-Tree capability) are inter-connected =0Awith a PW =E2=80=A6=E2=80=A6its peer PE (e.=
g., PE1) should then work in the optimized mode=0Afor this PW.=E2=80=9D
=0A 
=0A17.  =0ASection6.1: =E2=
=80=9CIf the bit V is set, and the PE is capable of V=
LAN mapping, then the PE with the minimum IP address MUST set VLAN-Mapping=
-Mode to TRUE;=E2=80=9D=0A Which IP address? T=
he address in the LDP IP header? 
=0A[JY]=
 Yes.<=
/p>=0A
[Lizhong] you should explicitly say that. But I personaly sugges=
t to compare the LDP ID=0A in LDP signaling.
=0A[JY2] To be consistent wi=
th BGP section, suggest to keep it as is (in both cases, IP addresses used=
 for comparison are extracted from their respective=0A IP sessions).<=
/o:p>
=0A&=
nbsp;
=0A 
=0A18.=
  =0ASection6.1: =E2=80=9C2) If the P bit is set, then:=
=E2=80=9D If above is pseudo code, then the code form=
at should be more formal, to make it clear and=0A neat.<=
/span>
=0A[JY] Thanks, we will remove the character ":" in the next=
 revision. Does this resolve your=0A concerns?
=0A[Lizhong] you could re=
fer to RFC4379 section 4.4.
=0A[JY2] thanks, we will.=0A
=0A 
=0A19.  =0ASection6.1: =E2=
=80=9CIf the PE is a leaf-only node itself, then a la=
bel release message with a status code "Leaf to Leaf PW released" is sent =
to the peer PE and exit the=0A process;=E2=80=9D When both PE release the mapping. Then when one PE1 change the setting =
to have both root&leaf, and send label mapping to PE2, will PE2 be tri=
ggered to send label mapping to PE1? According to RFC5036, I think the ans=
wer is=0A no. You need additional mechanism here.=
=0A[JY] Why PE2 cannot be triggered to send label mapping to PE1? =
IMO, we don't need any additional=0A mechanism here. If the configuration =
is changed for a failed PW establishing session, then a new round of PW ne=
gotiations can take place between PE1 and PE2. Furthermore, the PW negotia=
tion process is standardized in RFC 4447 rather than RFC 5036, and you=0A =
can find answers there.<=
o:p>
=0A[Lizhong] You should give out the technical re=
ason. There is no configuration changing on=0A PE2, and PE1 release the ma=
pping from PE2, then the PE2 will not send mapping again since DU mode is =
used for PW signaling. BTW, the PW signaling RFC4447 is based on RFC5036, =
and also updated by RFC6723. One method is, like RFC6723, PE1 need LDP req=
uest message=0A to reestablish the PW.
=0A=
[JY2] this is similar to commen=
t 20 since it deals with topology and TLV parameter updates.
=0A 
=0A20.  =0ASection6.1: the E-Tree Sub-TLV parameters updating=
 should be also mentioned in this section.
=0A[JY=
] Could you elaborate more on the specific requirements and scenarios in y=
our mind? Are=0A you suggesting to support versions for this TLV? I am not=
 sure we need such a complex mechanism.
=0A[Lizhong] The most simple up=
dating mechanims is to LDP withdraw and mapping again. If you=0A want to b=
e simple, it is better to explictly say that.
=0A[JY2] Please note that=
 RFC 7152 which specifies the requirements for E-Tree does not have such a=
 requirement. Definitely, LDP withdrawal and mapping=0A (both have already=
 been defined in RFC 4447) can be used in updating PW labels and TLVs in L=
DP VPLS, but scenarios and requirements are also needed. Maybe a new I-D i=
s better to serve this purpose. The guidance from the WG chairs is needed.=
=0A 
=0A21.=
  =0ASection6.2: =E2=80=9CData plane in the VPLS is the same as=
 described in Section 4.2 of [RFC4761], and data plane processing for a PW=
 is the same as described at the end=0A of Section 6.1.=E2=80=9D Why same as RFC4761 here? Don=E2=80=99t you have VLAN-Mapping-Mode and other mode data plane operatio=
n?
=0A[JY] Please see the end of section 6=
.1, it says:<=
/span>
=0A"   Data plane processing for this PW is as fol=
lowing:
=0A   If Optimized-Mode is TRUE, then data plane proces=
sing as described
=0A   in Section 5.3.3 applies.
=0A &nb=
sp; If VLAN-Mapping-Mode is TRUE, then data plane processing as
=0A&nbs=
p;  described in Section 5.3.1 applies.
=0A   If Compat=
ible-Mode is TRUE, then data plane processing is as
=0A   des=
cribed in Section 5.3.2."=0A
=0A   These sub-sections defi=
nitely deal with E-Tree specific data plane operations such as=0A VLAN map=
ping.<=
/p>=0A
[Lizhong] You should say that, like: except described in section=
 6.1, other dataplane behavior=0A is same as .....
=0A[JY2] They are on d=
ifferent topic: the end of Section 6.1 covers PW processing, while Section=
 4.2 of [RFC4761] covers VPLS data plane.
=0ATo b=
e clear, it is proposed to say:=E2=80=9DData plane in the VPLS is the same=
 as described in Section 4.2 of [RFC4761], and data plane processing for=
=0A a PW is the same as described at the end of Section 6.1 =0Ain this document.=E2=80=
=9D=0A

=0A=
22.  =0ASection8: This section is too simple to remove it. Or please =
add more detail.
=0A[JY] The details are already =
covered in Section 4 and Appendix A, so this section is just=0A a summary =
of the application scenarios it can work.
=0A[Lizhong] since covered, why=
 we need summary here? Let WG decide.
=0A<=
span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:"Calibri&qu=
ot;,"sans-serif";color:#7030A0">[JY2] Please note that RFC 7152 =
Section 5.2 has such a requirement.
=0A =
;
=0A23.  =0ASecti=
on9: New security concern will include: since the outmost VLAN is leaf or =
root, it is easy to parse the leaf and root VLAN information.
=0A[JY] It is unclear to me what is the security hole you ar=
e trying to indicate and what security=0A measure is in your mind. Could y=
ou elaborate a little more on it? In my opinion, VLANs in this document ar=
e not more vulnerable compared with the VLANs in a tagged PW (see RFC 4448=
) and the security measures as proposed in RFC 4762 and RFC 4448 are suffi=
cient.=
=0A[Lizhong] compared with VPLS, parse the VLAN could get the E-Tr=
ee topology for the E-tree=0A VPLS. Topology information leaking is the co=
ncern.=
=0A[JY2] yes, an intruder inside a carrier network may get the inf=
ormation on the 2 E-Tree VLAN values used by the carrier, but is it worse =
than a=0A single VLAN value in the case of a traditional VPLS? Are there a=
ny security measures different? I am still in doubt.=
=0A 
=0A24. &nb=
sp;=0ASection10: The all=
ocated value should be=0A=E2=80=9CTBD=E2=80=9D.
=0A[JY] Sorry, I failed to understand the point. But all t=
he values have already been allocated=0A officially by IANA, why do you su=
ggest to use "TBD" instead?
=0A[Lizhong] I think IANA is pre-allocated, =
not final. Let WG decide.
=0A 
=0ARegards
=0ALizhong
=0A
Alth=
ough Virtual Private Multicast Service (VPMS)
=C2=A0=C2=A0 [VPMS] or Point-to-Multipoint (P=
2MP) multicast is a somewhat
=C2=A0=C2=A0 simplified version of this service, in fact, there is=
 no exact
=C2=A0=C2=A0 corresponding terminology in IETF yet.<=
/span>
I could not understand why you say the &quo=
t;terminology" here refer to E-Tree.
The =
bridge
=C2=A0=C2=A0 module has a single "Emulated LAN" interfac=
e over which it
=C2=A0=C2=A0 communicates with all VPLS forwarders, and each VPLS =
instance is
=C2=A0=C2=A0 represented by a unique S-VLAN tag.
In a=
ll cases, the outermost VLAN in the resulted Ethernet header is
=C2=A0=C2=A0 used to indicate the E-Tree attribute of an Ethernet =
frame; this
=C2=A0=C2=A0 document uses VLAN to refer to this outermost VLAN fo=
r simplicity in
=C2=A0=C2=A0 the latter sections.
Using the PWid FEC, each of the two pseudowire endp=
oints
   independently initiates the setup of a unidirectional LSP.  An
   outgoing LSP and an incoming LSP are bound together into a single
   pseudowire if they have the same PW ID and PW type.
Although Virtual Private Multicast Service (VPMS)=

=C2=A0=C2=A0 [VPMS] or Point-to-Multipoint (P2MP) multicast is a some=
what=

=C2=A0=C2=A0 simplified version of this ser=
vice, in fact, there is no exact
=C2=A0=C2=A0 corresponding terminology in I=
ETF yet.
I could not understa=
nd why you say the "terminology" here refer to E-Tree.
The bridge
=C2=A0=C2=A0 module has a single "Emul=
ated LAN" interface over which it
=C2=A0=C2=A0 communicates with all VPLS for=
warders, and each VPLS instance is
=C2=A0=C2=A0 represented by a unique S-VLAN=
 tag.
In all cases, the outermost VLAN in the resulted Etherne=
t header is=

=C2=A0=C2=A0 used to indicate the E-Tree at=
tribute of an Ethernet frame; this
=C2=A0=C2=A0 document uses VLAN to refer to=
 this outermost VLAN for simplicity in
=C2=A0=C2=A0 the latter sections.
Using=
 the PWid FEC, each of the two pseudowire endpoints=0A   independently =
initiates the setup of a unidirectional LSP.  An
=0A   outgoing LSP and an incoming LSP are bound to=
gether into a single
=0A   pseudowire if they have the same PW ID and PW=
 type.
=0A
Although Virtual Private Multicast Service (VPMS)
   [VPMS] or Point-to-Multipoint (P2MP) multicast is a somewhat
   simpl=
ified version of this service, in fact, there is no exact
   corresponding termin=
ology in IETF yet.
The bridge
   module has a single "Emulated LAN=
" interface over which it=0A   communicates with all VPLS forwarders, and each VPLS=
 instance is
=0A&n=
bsp;  represented by a unique S-VLAN tag.=
=0A=0AThat is the S-VLAN is used to indentify VLAN instance. Bu=
t now S-VLAN=0A is used to only identify E-Tree attribute, then it is not ri=
ght to apply 802.1ad bridge mode to illustrate E-Tree mode.
=0A=
=0A[JY2] I think there is some =
misunderstanding here, S-VLANs for E-Tree is not different from S-VLANs fo=
r other services (for example, E-LAN). In IEEE 802.1, the only=0A requirem=
ent is that two unique S-VLAN values are used (one used for root traffic f=
orwarding, and the other used for leaf traffic forwarding); and the two un=
ique S-VLAN values aforementioned can each represent a VPLS instance (just=
 as described in RFC 6246).=0A It is also noted in the document =E2=80=9Cb=
oth these VSIs have to share their learned MAC addresses=E2=80=9D in page =
7. VSIs forward E-Tree traffic just like a normal VPLS service and all E-T=
ree filtering happens in the bridge module.
=0A=0A =
=0A=0A10.=
  =0ASection4.=
2: =E2=80=9Cand optionally MAY be added with another root S-VLAN.=E2=80=9D=
 When and why add another root S-VLAN here? And why use terminology =E2=80=
=9Croot S-VLAN=E2=80=9D, not root VLAN as indicated in Figure4?
=0A=0A[JY] Figure 4 is a genera=
lized diagram, where VLAN may be a C-VLAN, S-VLAN or B-VLAN, the texts in =
Section 4.2 describe each cases of specific VLANs respectively.
=0A=0AIt is proposed to update =
the 1st sentence "In order to support the E-Tree in a more scalable way...=
" in Section 4.2 with:=
=0A=0A"In order to support the E-Tree in a more generic and more scala=
ble way..."
=0A=0A[=
Lizhong] A word "generic" does not solve the problem. Since you =
list the possibility to add one root C-VLAN and another root S-VLAN, I nee=
d to understand the scenario=0A why we need that. The strange thing is, at=
 the end of this section:=0A
In all cases, the outermost VLAN in the resulted Ethernet header is=
=0A   use=
d to indicate the E-Tree attribute of an Ethernet frame; this
=0A   document uses VL=
AN to refer to this outermost VLAN for simplicity in
=0A   the latter sections.
=0A=0AThen why we shou=
ld add the first root C-VLAN?
=0A=0AAnd you should use same terminology across the document. =
And what's the different among "Root VLAN", "Root C-VLAN", "Root S-VLAN", =
"Root B-VLAN", and same question=0A to leaf?
=0A=0A[JY2] Similar to the IEEE terminology (a gen=
eric VLAN may be a C-VLAN, S-VLAN or B-VLAN),  a Root VLAN may be a "=
Root C-VLAN", "Root S-VLAN", or "Root B-VLAN", the=0A same applies to leaf=
 VLAN. We will further clarify it in the terminology section by adding =E2=
=80=9Cit may be a C-VLAN, an S-VLAN or a=
 B-VLAN=E2=80=9D to the definition of =E2=80=9CRoot VLAN=E2=80=9D a=
nd =E2=80=9CLeaf VLAN=E2=80=9D, that is:=0A
=0A=0A=E2=80=9C   Root VLAN: a VLAN ID us=
ed to indicate all the frames that are
=0A=0A   originated at a root AC, it may be a C-VLAN, an S-VLAN or a B-VLAN=E2=
=80=9D
=0A=0APlease =
note that an 802.1ad bridge module may co-exist with 802.1Q bridge modules=
 in the same PE (as shown in Fig.2 in RFC 6246), and both root C-VLAN and =
root S-VLAN=0A may be used at the same time, so that seamless convergence =
can be realized (e.g., when 802.1Q bridges co-exist with 802.1D bridges in=
 the same customer network and be attached to this PE).=0A
=0A=
=0ATo be clear, it is proposed =
to replace the 2^nd paragraph in Section 4.2 with:
=0A=
=0A=E2=80=9CFor an untagged por=
t (frames over this port are untagged) or VLAN-unaware port (VLAN tags in =
the frames are ignored),=0Awhen the brid=
ge module is a C-VLAN bridge, the Ethernet frames received from the=
 root ACs SHOULD be tagged with a root C-VLAN=0Aand optionally MAY be a=
dded with another root S-VLAN; when =
the bridge module is an 802.1ad bridge, the Ethernet frames received from =
the root ACs SHOULD be tagged with a root S-VLAN (it can be added with a r=
oot C-VLAN=0A firstly but this is out of the scope of this document). =E2=80=9C
=0A=0A&=
nbsp;
=0A=0A11.  =0ASection4.2: =E2=80=9CFor an S-VLAN ta=
gged port, the S-VLAN tag in the Ethernet frames received from the root AC=
s SHOULD be translated to the root S-VLAN in the VPLS network domain=E2=80=
=9D. The description of S-VLAN tagged port=0A is not accurate here. I thin=
k here, you want to refer to a port receiving a packet with both S-VLAN &a=
mp; C-VLAN. So it is better to say, =E2=80=9Cwhen receiving a packet with =
both S&C VLAN=E2=80=A6=E2=80=9D. Same suggestion to previous paragraph=
s.=0A
=0A=0A[JY] Th=
is is not what we want. There are implementations in the industry that sup=
ports encapsulation of all traffics from a port into an S-VLAN (BBF TR-101=
 also specifies=0A such a behavior). So no change is needed here.
=0A=0A 
=0A=0AIf S-VLAN only packet recei=
ved, still translate S-VLAN to root S-VLAN?
=0A=0A[JY]  Yes, some SPs may prefer to use su=
ch an S-VLAN translation in their networks for ease of management. This wa=
s also discussed in the L2VPN WG before and a consensus=0A was reached.
=0A=0A[Lizhong] Then I=
 could not agree you use "SHOULD" to mandatory the translation. It is not =
necessary to do translation for S-VLAN only packet in many cases. Could WG=
=0A chair confirm the consensus Yuanlong refers to.
=0A=0A[JY2]  Maybe the previous L2VPN =
chairs has something to say since all those details were discussed in L2VP=
N WG as early as in 2012. I have no strong opinion to change=0A =E2=80=9CS=
HOULD=E2=80=9D to =E2=80=9CMAY=E2=80=9D, but it would be better to give a =
preference when several options are given.
=0A=0A <=
/span>
=0A=0A12.&=
nbsp; =0ASection4.2=
: =E2=80=9Cthe E-Tree attribute may also be indicated with two I-SID tags =
in the bridge module=E2=80=9D. Suggest to remove since it is not part of t=
his document.
=0A=0A[=
JY] As I remember, this note was added to resolve a comment raised in the =
L2VPN WG mailing list, and it was accepted into the document with no objec=
tion. This note=0A is totally informational, and I am not sure it is appro=
priate to delete it.=0A<=
p class=3D"MsoNormal" style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; =
font-family: =E5=AE=8B=E4=BD=93;">=0A[Lizhong] You describe the brief method, but does not provide the de=
tail. My concern is, if there is future document to describe E-Tree for PB=
B-VLAN, and basic method=0A is different with this document, then there wi=
ll be conflict. =0A=
=0A[JY2] Both Don & Dave mentioned this approach as a valid o=
ption (in=0A=0Ahttp://www.=
ietf.org/mail-archive/web/l2vpn/current/msg03433.html and http://www.ietf.org/mail-archive/web/l=
2vpn/current/msg03365.html=0A respectively), and this paragraph was ad=
ded in the E-Tree I-D before the WG adoption. IMO, this is informational a=
nd is useful, but let the WG decide it.=0A
=0A=0A <=
/span>
=0A=0A13.&=
nbsp; =0ASection5.2=
: =E2=80=9CFor both methods, VLAN mapping parameters from a remote PE can =
be provisioned or determined by a signaling protocol as described in Secti=
on 6 when a PW is being established=E2=80=9D. For the global method,=0A wh=
y we need signaling?=0A<=
p class=3D"MsoNormal" style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; =
font-family: =E5=AE=8B=E4=BD=93;">=0A[JY] Just as the sentence says, the global VLAN method does not rely=
 on signaling for its work.<=
/p>=0A=0ABut the SPs may prefer to use one method (e.g., global VLAN b=
ased) in scenario A and the other method (e.g., local VLAN based) in scena=
rio B, and they would like to=0A keep both methods work in a similar way, =
so the signaling protocol was designed to be applicable in both methods to=
 give them a similar operation experience (if signaling is supported).
=0A=0A[Lizhong] I don'=
t agree, what if deploying only global mode? You are talking about the ope=
rational experience, but I am talking about the technology. It is very con=
fusing=0A for the readers.=0A
=0A[JY2] Firstly, signaling for global method is not mandatory. S=
econdly, when control plane is needed, it is simple to implement if the sa=
me signaling can be used in=0A both cases. BTW, even in the global mode, w=
e may save some work in configuration if we have signaling capability (thu=
s we only need to configure two VLAN values per router).=0A
=0A=
=0A 
=0A=0A14.  =0ASection5.3.1: =E2=80=9Ci.e., the local leaf VLAN in a frame is tra=
nslated to the remote leaf VLAN; the local root VLAN in a frame is transla=
ted to the remote root VLAN=E2=80=9D. Here you should refer back to sectio=
n 4.
=0A=0A[JY] At th=
e end of Section 4, it already says:
=0A=0A"  In all cases, the outermost VLAN in the resu=
lted Ethernet header is=
=0A=0A   used to indicate the E-Tree attribute of an Etherne=
t frame; this
=0A=0A&=
nbsp;  document uses VLAN to refer to this outermost VLAN for simplic=
ity in
=0A=0A &=
nbsp; the latter sections."<=
/p>=0A
=0ASince there are dozens of "VLAN"s in section 5 & 6 ("the =
latter sections" aforementioned), referring to Section 4 for each use of V=
LAN is thus both unnecessary and=0A cumbersome.   
=0A=
=0A[Lizhong] But here is "local=
 leaf VLAN" and "remote leaf VLAN", if I expand, they will change to =
"local leaf outermost VLAN" and "remote=
=0A leaf outermost VLAN". Then question is what is the "rem=
ote leaf outermost VLAN"?
=0A=0A[JY2] No, we did not hint such a expansion. Th=
e E-Tree VLAN is generic (it may be C-VLAN, S-VLAN or B-VLAN), and actuall=
y indicated by the outermost VLAN. See comment=0A 10 for the terminology c=
larification.
=0A=0A&=
nbsp;
=0A=0A15.  =0ASection5.3.2: =E2=80=9CUpon receiving=
 frames on the PW, add a VLAN tag with a value of the local root VLAN to t=
he frames.=E2=80=9D Not understand here. Does that mean all receiving fram=
es will be considered to be from root? Then=0A how to isolate traffic betw=
een two leaves?
=0A=0A[JY] Yes, all the received frames from the PW will be from roots. As the =
1st paragraph in this section already says:"the VPLS PE with a traditional=
 VSI can only be=0A attached with root nodes."=
=0A=0A[Lizhong] OK.=
=0A=0A 
=0A=0A16.  =0ASecti=
on5.3.3: =E2=80=9CIf a PE is in the Optimized Mode for a PW, upon transmit=
=E2=80=9D. Suggest to: If a PE is in the Optimized Mode for a PW, upon tra=
nsmit to leaf only nodes.=0A
=0A[JY] As it already says in the 1st paragraph of Section 5.3.3, =
a PE works in Optimized Mode for a PW only when its peer PE is attached wi=
th only leaf nodes. Why add=0A this condition again (in implementation, yo=
u need an extra data plane operation to determine whether this condition i=
s met, furthermore, it is difficult to determine whether a destination nod=
e is a root or leaf in the data plane)?
=0A=0A[Lizhong] no, by signaling, the dataplane should =
know the remote PE is leaf only or not. What I mean is, the drop operation=
 is only valid for leaf-only nodes.=
=0A=0A[JY2] this is always true, so the condition is not ne=
eded in the data plane. To be clear, it is proposed to update the 1st sent=
ence in Section 5.3.3 =E2=80=9DWhen two PEs (both=0A have E-Tree capabilit=
y) are inter-connected with a PW =
=E2=80=A6=E2=80=A6its peer PE (e.g., PE1) should then work in the optimize=
d mode=0Afor this PW.=E2=80=9D
=0A=0A 
=0A=0A17.  =0ASection6.1: =E2=80=9CIf the bit V is set, and the =
PE is capable of VLAN mapping, then the PE with the minimum IP address MUS=
T set VLAN-Mapping-Mode to TRUE;=E2=80=9D Which IP address? The address in=
 the LDP IP header?=0A=
=0A=0A[JY] Yes.
=0A=0A[Lizhong] you should explicitly say that. But I personaly suggest to =
compare the LDP ID in LDP signaling.
=0A=0A[JY2] To be consistent with BGP section, suggest to =
keep it as is (in both cases, IP addresses used for comparison are extract=
ed from their respective IP sessions).
=0A=0A 
=0A=0A =
=0A=0A18.  =
;=0ASection6.1: =E2=80=
=9C2) If the P bit is set, then:=E2=80=9D If above is pseudo code, then th=
e code format should be more formal, to make it clear and neat.
=0A=0A[JY] Thanks, we will remo=
ve the character ":" in the next revision. Does this resolve your concerns=
?
=0A=0A[Lizhong] you=
 could refer to RFC4379 section 4.4.
=0A=0A[JY2] thanks, we will.=0A
=0A=0A 
=0A=0A19.  =0ASecti=
on6.1: =E2=80=9CIf the PE is a leaf-only node itself, then a label release=
 message with a status code "Leaf to Leaf PW released" is sent to the peer=
 PE and exit the process;=E2=80=9D When both PE release the mapping. Then=
=0A when one PE1 change the setting to have both root&leaf, and send l=
abel mapping to PE2, will PE2 be triggered to send label mapping to PE1? A=
ccording to RFC5036, I think the answer is no. You need additional mechani=
sm here.
=0A=0A[JY] W=
hy PE2 cannot be triggered to send label mapping to PE1? IMO, we don't nee=
d any additional mechanism here. If the configuration is changed for a fai=
led PW establishing=0A session, then a new round of PW negotiations can ta=
ke place between PE1 and PE2. Furthermore, the PW negotiation process is s=
tandardized in RFC 4447 rather than RFC 5036, and you can find answers the=
re.
=0A=0A[Lizhong] =
You should give out the technical reason. There is no configuration changi=
ng on PE2, and PE1 release the mapping from PE2, then the PE2 will not sen=
d mapping=0A again since DU mode is used for PW signaling. BTW, the PW sig=
naling RFC4447 is based on RFC5036, and also updated by RFC6723. One metho=
d is, like RFC6723, PE1 need LDP request message to reestablish the PW.
=0A=0A[JY2] this is si=
milar to comment 20 since it deals with topology and TLV parameter updates=
.
=0A=0A =
=0A=0A20.  =0ASection6.1: the E-Tree Sub-TLV parameters updatin=
g should be also mentioned in this section.
=0A=0A[JY] Could you elaborate more on the specific=
 requirements and scenarios in your mind? Are you suggesting to support ve=
rsions for this TLV? I am not sure we need such=0A a complex mechanism.
=0A=0A[Lizhong] The mo=
st simple updating mechanims is to LDP withdraw and mapping again. If you =
want to be simple, it is better to explictly say that.
=0A=0A[JY2] Please note that RFC 7152 wh=
ich specifies the requirements for E-Tree does not have such a requirement=
. Definitely, LDP withdrawal and mapping (both have already=0A been define=
d in RFC 4447) can be used in updating PW labels and TLVs in LDP VPLS, but=
 scenarios and requirements are also needed. Maybe a new I-D is better to =
serve this purpose. The guidance from the WG chairs is needed.
=0A=0A 
=0A=0A21.  =0ASection6.2: =E2=80=9CData plane in the VPLS is the same as descr=
ibed in Section 4.2 of [RFC4761], and data plane processing for a PW is th=
e same as described at the end of Section 6.1.=E2=80=9D Why same as RFC476=
1 here? Don=E2=80=99t you=0A have VLAN-Mapping-Mode and other mode data pl=
ane operation?
=0A=0A=
[JY] Please see the end of section 6.1, it says:
=0A=0A"   Data plane processing for =
this PW is as following:=
=0A=0A   If Optimized-Mode is TRUE, then data plane processi=
ng as described
=0A=0A   in Section 5.3.3 applies.
=0A=0A   If VLAN-Mapping-Mode is TRUE, then d=
ata plane processing as=
=0A=0A   described in Section 5.3.1 applies.
=0A=
=0A   If Compatible-M=
ode is TRUE, then data plane processing is as<=
o:p>
=0A=0A   described in Section 5.3.2."=
=0A
=0A=0A &nbs=
p; These sub-sections definitely deal with E-Tree specific data plane=
 operations such as VLAN mapping.
=0A=0A[Lizhong] You should say that, like: except described i=
n section 6.1, other dataplane behavior is same as .....
=0A=0A=
[JY2] They are on different top=
ic: the end of Section 6.1 covers PW processing, while Section 4.2 of [RFC=
4761] covers VPLS data plane.
=0A=0ATo be clear, it is proposed to say:=E2=80=9DData plane in=
 the VPLS is the same as described in Section 4.2 of [RFC4761], and data p=
lane processing for a PW is the same as described=0A at the end of Section=
 6.1 in this document.=E2=80=9D
=0A=0A 
=0A=0A22.  =0ASection8: This section is too simple to remove it.=
 Or please add more detail.<=
/p>=0A
=0A[JY] The details are already covered in Section 4 and Appendi=
x A, so this section is just a summary of the application scenarios it can=
 work.
=0A=0A[Lizhon=
g] since covered, why we need summary here? Let WG decide.
=0A=
=0A[JY2] Please note that RFC 7=
152 Section 5.2 has such a requirement.
=0A=0A 
=0A=0A23.&nbs=
p; =0ASection9: New=
 security concern will include: since the outmost VLAN is leaf or root, it=
 is easy to parse the leaf and root VLAN information.
=0A=0A[JY] It is unclear to me what is th=
e security hole you are trying to indicate and what security measure is in=
 your mind. Could you elaborate a little more on it? In=0A my opinion, VLA=
Ns in this document are not more vulnerable compared with the VLANs in a t=
agged PW (see RFC 4448) and the security measures as proposed in RFC 4762 =
and RFC 4448 are sufficient.=
=0A=0A[Lizhong] compared with VPLS, parse the VLAN could get the E=
-Tree topology for the E-tree VPLS. Topology information leaking is the co=
ncern.
=0A=0A[JY2] y=
es, an intruder inside a carrier network may get the information on the 2 =
E-Tree VLAN values used by the carrier, but is it worse than a single VLAN=
 value in=0A the case of a traditional VPLS? Are there any security measur=
es different? I am still in doubt.<=
/span>
=0A=0A =0A
=0A24. &nb=
sp;=0ASection10: The all=
ocated value should be =E2=80=9CTBD=E2=80=9D.<=
o:p>
=0A=0A[JY] Sorry, I failed to understand the po=
int. But all the values have already been allocated officially by IANA, wh=
y do you suggest to use "TBD" instead?
=0A=0A[Lizhong] I think IANA is pre-allocated, not final=
. Let WG decide.
=0A=0A 
=0A=0ARegard=
s
=0A=0ALizhong
=0A
4.1.  Backwards Compatibili=
ty with Reply via Specified Path (5) Reply
      Mode

   [RFC7110] has introduced the "Reply via Specified path (5)" Re=
ply
   Mode, and defined that usage of the "Reply via Specified path (5)&q=
uot;
   Reply Mode without also including the "Reply Path TLV" to be i=
nvalid.
   This document relaxes this semantic by defining the use of the "Rep=
ly
   via Specified path (5)" Reply Mode without the "Reply via Spec=
ified
   path (5)" to indicate the reverse LSP.  In other words, what was
   considered invalid is now valid.  If the initiator LSR, which sent an
   MPLS echo request message with the "Reply via Specified path (5)&qu=
ot;
   Reply Mode but without including the "Reply Path TLV", receive=
s back
   an MPLS echo reply message with the return code being "Malformed ec=
ho
   request received", then the initiator LSR SHOULD assume that the
   responder LSR does not support the mechanism defined in this=C2=A0document.
   Section =
2 described the problems which increases the complexity with
   respect to operations and implementations.  In order to to simplify
   operations and to allow for the LSP Ping/Traceroute to function
   efficiently whilst preserving the code simplicity, it is RECOMMENDED
   that implementations allow devices to have configuration options to
   set operator preferred Reply Modes.  For example:

   o  For those operators who are more interested in MPLS echo reply
      packets reaching back to the initiator LSR:

      1.  Reply via an IPv4/IPv6 UDP packet (2)

      2.  Reply via application level control channel (4)

      3.  Reply via Specified Path (5)

   o  For those operators who are more interested in MPLS echo reply
      packets testing the paths related to the forward LSP:

      1.  Reply via Specified Path (5)

      2.  Reply via application level control channel (4)

      3.  Reply via an IPv4/IPv6 UDP packet (2)

MIB summary – using = top-level structure

Editorial = Comments

MIB Editorial (page = numbers only)