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

From: Raymond Key <[email-masked]>
Date: Tue, 27 Apr 2010 13:10:36 +1000

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

[RK] When both ingress AC and egress AC are on the same PE, PW is not 
involved and hence CW is not applicable.

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

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: Wed, 28 Apr 2010 09:17:59 -0400

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,

rely 

[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?

[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 )

Thanks,
Raymond