Subject: RE: Comments on draft-key-l2vpn-vpls-etree-02

From: Raymond Key <[email-masked]>
Date: Mon, 10 May 2010 16:58:29 +1000

Hi Jim,

-snipped-

[Jim U>] Two distinct issues. The first is Leaf-to-Leaf traffic.. 
The vendors approach will be to group leafs together and then 
prohibit Leaf-to-Leaf traffic.

[RK] By "The vendors approach", which vendors are you referring to?

-snipped-

[Jim U>] The notion of multiple VSIs is used to create a topology.. 
When using BGP we have the tools to set up PWs between VSIs based 
on the import/export RTs. In this way topology is defined via the 
control plane and does not rely on the data plane ( CW ) to dictate 
traffic patterns. How do you want to proceed? This requirement is 
central to our approach..

[RK] There are many LDP-VPLS [RFC4762] in operation without BGP. 
My opinion is be liberal in requirement and allow more freedom for 
innovative solutions. I think BGP is not a requirement but well be 
part of a potential solution.

-snipped-

[RK] It's perfectly fine to have different opinions. I have expressed 
mine. Let's see what other people think.

Thanks,
Raymond Key

> UTTARO, JAMES (ATTLABS) <[email-masked]> wrote:
> 
> Comments In-Line..
> 
> Jim Uttaro
> 
> -----Original Message-----
> From: Raymond Key [mailto:[email-masked]] 
> Sent: Saturday, May 01, 2010 4:31 AM
> To: UTTARO, JAMES (ATTLABS)
> Cc: Delregno, Christopher N (Nick DelRegno); [email-masked]
> Subject: RE: Comments on draft-key-l2vpn-vpls-etree-02
> 
> Hi Jim,
> 
> The functional requirement is to prohibit communication between any two 
> Leaf ACs in a VPLS instance. When both ingress AC and egress AC are on 
> the same PE, 'split horizon' mechanism enforced locally on the PE would 
> be sufficient and such mechanism is commonly available on equipment from
> 
> different vendors. Only when ingress AC and egress AC are on different 
> PEs, there is a small problem and we propose to use a bit in the PW CW 
> to carry a "frame from Leaf or Root" indicator. We believe the proposed 
> solution fulfils the functional requirement. Some people from service 
> providers think this solution will work well in their environments.
> [Jim U>] Two distinct issues. The first is Leaf-to-Leaf traffic.. The
> vendors approach will be to group leafs together and then prohibit
> Leaf-to-Leaf traffic. Why as an SP do I need separate solutions if Leafs
> are on the same or different PEs. Operations/Provisioning etc.. will all
> have two be aware of the multiple solutions based on different vendors
> implementation. I am not in favor of this and do not believe it
> satisfies the functional requirement.  The second issue is if a Leaf on
> a PE forwards traffic to a Root on a PE. The root will see this traffic
> as native ethernet traffic an forward to all external interfaces and all
> PWs to other PEs.. Doesn't this mean there is a possibility of
> Leaf-to-Leaf traffic as the traffic will not have the CW bit set???
> 
> I consider "a PW semantic for intra-PE traffic between two ACs" more 
> as a possible solution approach, rather than as a requirement.
> [Jim U>] I do not agree. We want standards to lay a groundwork for
> vendors to create the most interoperable solutions.. Lack of definition
> will create multiple vendor specific solutions that most likely will be
> less than optimal in terms of interoperability. 
> 
> One point may have caused confusion. The proposed solution in this draft
> 
> uses one VSI for all ACs on a PE (the same way as the current standard 
> VPLS). Using one VSI for Root ACs and a separate VSI for Leaf ACs is a 
> possible solution approach but different from the one proposed in this 
> draft.
> [Jim U>] The notion of multiple VSIs is used to create a topology.. When
> using BGP we have the tools to set up PWs between VSIs based on the
> import/export RTs. In this way topology is defined via the control plane
> and does not rely on the data plane ( CW ) to dictate traffic patterns.
> How do you want to proceed? This requirement is central to our
> approach..
> 
> Appendix B. Data Forwarding Scenarios in the draft
> (http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-02#appendix-B) 
> describes in details how the proposed solution works, covers forwarding 
> various types of Ethernet frame: unicast known and unknown, broadcast 
> and multicast.
> 
> We recently posted a draft "Requirements for MEF E-Tree Support in VPLS"
> (http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-00)
> to facilitate a "solution-neutral" discussion on whether there is a
> valid 
> requirement to enhance VPLS or not. Any comments on that draft?
> 
> Regards,
> Raymond
> 
> 
> > UTTARO, JAMES (ATTLABS) <[email-masked]> wrote:
> > 
> > Raymond,
> > 
> > Comments In-Line..
> > 
> > Jim Uttaro
> > 
> > -----Original Message-----
> > From: Raymond Key [mailto:[email-masked]] 
> > Sent: Monday, April 26, 2010 11:11 PM
> > To: UTTARO, JAMES (ATTLABS)
> > Cc: Delregno, Christopher N (Nick DelRegno); [email-masked]
> > Subject: RE: Comments on draft-key-l2vpn-vpls-etree-02
> > 
> > Hi Jim,
> > 
> > Thanks for your questions.
> > 
> > I have attempted to address these in section 4.3 in the draft - 
> > Additional Action in Data Forwarding 
> > (http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-02#section-4.3)
> > 
> > a) If Leafs are on the same PE how will the CW function? Will we need
> to
> > rely 
> > on some other mechanism to prevent Leaf<>Leaf traffic on the same PE ?
> > 
> > [RK] Leaf AC -> Leaf AC Same PE : Rule 6 in Table 1
> > [Jim U>] This rule does not specify how the decision is made to drop.
> So
> > we have to have two mechanisms one if traffic came over a PW from a
> > remote PE ( CW ) and another if the traffic came from a leaf that is
> on
> > the same PE as the Leaf that originated the traffic ( ? ). The
> solution
> > is not complete if we need two mechanisms.. As a SP we want
> > specifications that are the same.
> > 
> > [RK] When both ingress AC and egress AC are on the same PE, PW is not 
> > involved and hence CW is not applicable.
> > [Jim U>] But that forces a different solution.. If not a PW then a PW
> > semantic for intra-PE traffic between two ACs.. 
> > 
> > b) Leaf->Root traffic on the same PE? We don't want the Root to simply
> > forward 
> > the traffic directly to another Leaf either on the PE or via a PW to a
> > remote PE.. 
> > How is this accomplished?
> > 
> > [RK] Leaf AC -> Root AC Same PE : Rule 1 in Table 1
> > 
> > [RK] Root AC -> Leaf AC Same PE : Rule 5 in Table 1
> > 
> > [RK] Root AC -> Leaf AC Remote PE
> >           Ingress PE (Root AC -> PW) : Rule 2 and Rule 3 in Table 1
> >           Egress PE (PW -> Leaf AC) : Rule 7 and Rule 8 in Table 1
> > 
> > [Jim U>] I guess I do not understand the table.. Referring to the
> > figure.. Assume ingress traffic from Leaf AC arrives on PE. The intra
> PE
> > traffic is forwarded to the Root AC ( VSI 1-R ). There is no PW
> semantic
> > for this traffic so it appears as if it is native ethernet traffic
> with
> > the same semantic as an AC.  At this point the traffic in that context
> > is sent out to all interfaces both PWs and other ACs possibly homed
> into
> > ( VSI 1-R ). This would cause Leaf<->Leaf traffic as Leaf PE1 ( VSI
> 1-L
> > ) would receive the traffic from the PE ( VSI 1-R ) that is not really
> > the customer's root traffic..
> > 
> > Leaf AC ( VSI 1-L )-------
> >                          |
> >                          |
> > Root AC ( VSI 1-R )-----PE-------------PE1--------Leaf ( VSI 1-L )
> > 
> > Have a read on the section 4.3 and see if it works.
> > 
> > Thanks,
> > Raymond
> > 
> > 
> > > UTTARO, JAMES (ATTLABS) <[email-masked]> wrote:
> > > 
> > > I guess  am still a bit confused as to how this would work when
> there
> > > are leafs and roots on the same PE..
> > > 
> > > a) If Leafs are on the same PE how will the CW function? Will we
> need
> > to
> > > rely on some other mechanism to prevent Leaf<>Leaf traffic on the
> same
> > > PE ?
> > > 
> > > b) Leaf->Root traffic on the same PE? We don't want the Root to
> simply
> > > forward the traffic directly to another Leaf either on the PE or via
> a
> > > PW to a remote PE.. How is this accomplished?
> > > 
> > > Comments In-Line..
> > > 
> > > Jim Uttaro
> > > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > > Of Raymond Key
> > > Sent: Friday, April 23, 2010 9:39 PM
> > > To: Delregno, Christopher N (Nick DelRegno)
> > > Cc: [email-masked]
> > > Subject: Comments on draft-key-l2vpn-vpls-etree-02
> > > 
> > > Hi Nick,
> > > 
> > > Thanks for your comment.
> > > 
> > > Quote from your email, "However, if we are relying on CW to indicate
> > > leaf/root and the targeted PE doesn't support CW, then the ETREE
> model
> > > breaks as I can no longer determine leaf/root and drop/forward
> traffic
> > > accordingly."
> > > 
> > > There may be some confusion here. When the targeted PE doesn't
> support
> > 
> > > CW, it also implies the targeted PE doesn't support the extension 
> > > specified in this draft (see section 4.2, "A PE MUST be capable of 
> > > sending and receiving the Control Word on Ethernet PW") and hence
> the 
> > > targeted PE has only Root ACs. This is a backward compatibility 
> > > scenario and does not result in any problem.
> > > 
> > > [Jim U>] From an SP perspective this approach represents a major
> > > operational/provisioning challenge.. We would now need to track the
> > set
> > > of PEs that are candidates for Roots ( No CW Capable ), Roots and
> > Leafs,
> > > Leafs only. We cannot easily go back and change our homing rules.
> This
> > > would also impact the provisonable footprint.
> > > 
> > > Backward compatibility issues are discussed in section 5 in the
> draft.
> > 
> > > (http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-02#section-5)
> > > Some paragraphs are extracted below.
> > > 
> > > (5.3. Additional Action in Data Forwarding)
> > > 
> > > For backward compatibility reason, a PE not supporting the extension
> > > specified in this document can participate in an E-Tree construct,
> > > but only Root ACs can be connected to such PE.
> > > 
> > > Lack of Control Word L-bit per-payload signaling between a PE
> > > supporting the extension specified in this document and a PE not
> > > supporting such extension does not result in any problem.
> > > 
> > > (5.3.1 Ingress PE Support the Extension but Egress PE Not)
> > > 
> > > If Control Word is not used on the Ethernet PW, there will be no CW
> > > L-bit. The egress PE will forward the frame as per current standard.
> > > This is correct as only Root ACs exist on a PE not supporting the
> > > extension specified in this document.  A Root AC can receive from
> any
> > > other ACs.
> > > 
> > > By the way I recently posted a draft "Requirements for MEF E-Tree 
> > > Support in VPLS" 
> > > (http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-00)
> > > trying to start a "solution-neutral" discussion on whether there is
> a 
> > > valid requirement to enhance VPLS or not. Any comments on that
> draft?
> > > 
> > > Thanks,
> > > Raymond 
> > > 
> > > 
> > > > Delregno, Christopher N (Nick DelRegno)
> <[email-masked]>
> > > wrote:
> > > > 
> > > > Raymond:
> > > > 
> > > > From a purely T-LDP perspective, I agree.  However, if we are
> > relying
> > > on
> > > > CW to indicate leaf/root and the targeted PE doesn't support CW,
> > then
> > > > the ETREE model breaks as I can no longer determine leaf/root and
> > > > drop/forward traffic accordingly.  As such, the implementation
> > > behavior
> > > > when using CW to indicate Leaf/Root MUST NOT allow the CW
> preference
> > > > mismatch to result in an active PW.
> > > > 
> > > > Thanks,
> > > > Nick
> > > > 
> > > > -----Original Message-----
> > > > From: Raymond Key [mailto:[email-masked]] 
> > > > Sent: Wednesday, April 21, 2010 4:55 PM
> > > > To: Delregno, Christopher N (Nick DelRegno)
> > > > Cc: [email-masked]
> > > > Subject: Re: Updated minutes from IETF 77
> > > > 
> > > > Hi Nic,
> > > > 
> > > > I go through the recently published IETF77 L2VPN minutes and would
> > > like
> > > > to follow up on one of your comments.
> > > > 
> > > > Extract from minutes under
> > > > 10) Extension to VPLS for E-Tree
> > > > "Nic: This requires a control word, so a box has to support a
> > control
> > > > word. 
> > > > PW mustn't come up if a CW is not supported."
> > > > 
> > > > There may be some confusion here. When one PE does not support
> > control
> > > > word, PW can still come up.
> > > > 
> > > > Refer to Section 5.2. Control Word (under Backward Compatibility)
> > For
> > > > backward compatibility reason, use of Control Word on Ethernet PW
> is
> > > not
> > > > mandatory. If the PE on the other end prefers not to use Control
> > Word
> > > or
> > > > does not support Control Word (which implies such PE does not
> > support
> > > > the extension specified in this document), then Control Word will
> > not
> > > be
> > > > used on the Ethernet PW.
> > > > Refer to Appendix A for different Control Word scenarios.
> > > >
> > (http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-02#section-5.2)
> > > > 
> > > > Regards,
> > > > Raymond Key
> > > > 
> > > > 
> > > > > Giles Heron <[email-masked]> wrote:
> > > > > 
> > > > > Ok - so it'd help if I actually put some content in my email.
> > > > > 
> > > > > As Simon Delord helpfully pointed out the other day I missed the
> 
> > > > > second half of the meeting out when I posted these.
> > > > > 
> > > > > I've now updated the online minutes:
> > > > > 
> > > > > http://www.ietf.org/proceedings/10mar/minutes/l2vpn.txt
> > > > > 
> > > > > Giles

---

From: "UTTARO, JAMES (ATTLABS)" <[email-masked]>
Date: Mon, 10 May 2010 10:38:52 -0400

Raymond,

Comments In-Line..

Jim Uttaro

-----Original Message-----
From: Raymond Key [mailto:[email-masked]] 
Sent: Monday, May 10, 2010 2:58 AM
To: UTTARO, JAMES (ATTLABS)
Cc: Delregno, Christopher N (Nick DelRegno); [email-masked]
Subject: RE: Comments on draft-key-l2vpn-vpls-etree-02

Hi Jim,

-snipped-

[RK] By "The vendors approach", which vendors are you referring to?
[Jim U>] I am speculating that this is the only available approach if we
do not define intra-PE Leaf<->Leaf communication in the E-TREE reqs
draft.. From an SP perspective it is not enough to state that
Leaf<->Leaf is disabled.. The way it is disabled needs to be consistent
from an inter and intra PE perspective. We do not want the same
functional req to be met differently based on where a leaf is homed. 

-snipped-

[RK] There are many LDP-VPLS [RFC4762] in operation without BGP. 
My opinion is be liberal in requirement and allow more freedom for 
innovative solutions. I think BGP is not a requirement but well be 
part of a potential solution.
[Jim U>] I do agree with that but would add that the LDP-VPLS signaled
VPNs deployed have all been any-to-any and simulated a ethernet LAN
across a WAN. There has been no requirement to create arbitrary
topologies of which E-Tree is one.  I am not making a value judgment and
am in no way saying BGP is required. Here is the requirement stated
agnostically. The signaling protocol that is used to create a VPLS
topology must inherently support the definition of the topology. This
definition should be consistent from an intra and inter PE perspective. 

-snipped-

[Jim U>] Sounds Good.

Thanks,
Raymond Key

> [Jim U>] The notion of multiple VSIs is used to create a topology..
When
need
simply