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

From: Raymond Key <[email-masked]>
Date: Sat, 01 May 2010 18:30:51 +1000

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.

I consider "a PW semantic for intra-PE traffic between two ACs" more 
as a possible solution approach, rather than as a requirement.

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.

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, 3 May 2010 09:47:16 -0400

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,

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. 

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

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

to