Subject: wg last call on ldp and bgp based vpls solutions

From: Loa Andersson <[email-masked]>
Date: Tue, 13 Apr 2004 23:18:02 +0200

Working group,

we've decided to issue a working last call for the ldp and bgp based
vpls solutions at the same time. Nevertheless this is not a beauty
contest and the purpose is not to compare solutions, the working group
has decided to progress both solutions.

The working group last call and the review will be for each documents
independently and on its own merits. Please send comments on the
documents to the working group mailing list and the working group
chairs. Take care to indicate in Subject: which document you are
commenting on, and don't mix comments unnecessarily.

The working group last call will end midnight April 30th, PST. The
documents under review is:

<draft-ietf-l2vpn-vpls-ldp-02.txt>

http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-02.txt

and

<draft-ietf-l2vpn-vpls-bgp-01.txt>

http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-bgp-01.txt

/Loa, Vach and Rick

-- 

Loa Andersson

mobile +46 739 81 21 64

---

From: Eric Rosen <[email-masked]>
Date: Wed, 14 Apr 2004 11:40:59 -0400

I am sure no one will be  surprised to hear that I object to the advancement
of this  document in its current  form, as section  7.1 (on the use  of PWE3
signaling) is inadequate and out of date.

Although  the PWE3  LDP-based Control  Protocol specification  is referenced
(though the reference is  to a version over a year old),  no notice is taken
of  the fact that  the PWE3  LDP-based control  protocol supports  two FECs.
This  document appears to  mandate the  use of  one of  them (FEC  128), but
doesn't even state that explicitly, leaving it as an exercise for the reader
to infer this from the diagrams.

In fact,  the VPLS  specification should  allow both FECs,  FEC 128  and FEC
129,  and draft-l2vpn-signaling  should also  be referenced.  (Actually, the
latter appears in the references, but is not actually referenced!)

In addition,  the document's use of FEC  128 is non-standard, as  its use of
the group  id field does not  appear to be  in accord with the  PWE3 control
protocol specification.  I understand that this is a backwards compatibility
issue, but it needs to be called out explicitly. 

As far as I can tell,  there is nothing really LDP-specific in this document
except  the  requirement  to use  LDP.   I  don't  think there  is  anything
incompatible with the use of  L2TP-based PWE3 signaling; this should also be
accommodated.

From section 7.1: "In a VPLS, we  use a VCID (to be substituted with a VPNID
TLV later, to address extending the  scope of a VPLS)".  I have two comments
on this: 
- I always thought  "later" meant "before last call",  not "we hope everyone
  will forget about it" ;-)
- It should be noted that this problem is solved via the use of FEC 129. 

Section  7.1 also repeats  the definitions  of various  VC type  fields from
PWE3.   This  should  be  eliminated,  and the  appropriate  PWE3  documents
referenced instead. 

If I might also comment on a procedural issue, I think that before issuing a
last call, the WG chairs should ask the authors to update the references and
the boilerplate (intellectual property section and copyright section).  

Based on  my own recent experiences  as an editor with  documents before the
IESG, I think that the  Security Considerations section will not be accepted
by the IESG.   They will ask for a brief discussion  of the key distribution
method behind the "use  MD5 to secure the LDP sessions" and  they will for a
bit more (quite a bit more probably) than "if you want security encrypt your
packets."

---

From: "Vach Kompella" <[email-masked]>
Date: Wed, 14 Apr 2004 10:03:03 -0700

I agree with Eric.  I didn't get a chance to put in my changes to use
the generalized PWID FEC structure before it got submitted as the final
version of the draft.  I'll get those in forthwith.

-Vach 

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]] 
> Sent: Wednesday, April 14, 2004 8:41 AM
> To: Loa Andersson
> Cc: [email-masked]; Thomas Narten; Alex Zinin; 
> [email-masked]'; [email-masked]
> Subject: Re: wg last call on ldp-based vpls solutions
> 
> 
> 
> I am sure no one will be  surprised to hear that I object to 
> the advancement of this  document in its current  form, as 
> section  7.1 (on the use  of PWE3
> Although  the PWE3  LDP-based Control  Protocol specification 
>  is referenced (though the reference is  to a version over a 
> year old),  no notice is taken of  the fact that  the PWE3  
> LDP-based control  protocol supports  two FECs. This  
> document appears to  mandate the  use of  one of  them (FEC  
> 128), but doesn't even state that explicitly, leaving it as 
> an exercise for the reader to infer this from the diagrams.
> 
> In fact,  the VPLS  specification should  allow both FECs,  
> FEC 128  and FEC 129,  and draft-l2vpn-signaling  should also 
>  be referenced.  (Actually, the latter appears in the 
> references, but is not actually referenced!)
> 
> In addition,  the document's use of FEC  128 is non-standard, 
> as  its use of the group  id field does not  appear to be  in 
> accord with the  PWE3 control protocol specification.  I 
> understand that this is a backwards compatibility issue, but 
> it needs to be called out explicitly. 
> 
> incompatible with the use of  L2TP-based PWE3 signaling; this 
> should also be accommodated.
> 
> From section 7.1: "In a VPLS, we  use a VCID (to be 
> substituted with a VPNID TLV later, to address extending the  
> scope of a VPLS)".  I have two comments on this: 
> If I might also comment on a procedural issue, I think that 
> before issuing a last call, the WG chairs should ask the 
> authors to update the references and the boilerplate 
> (intellectual property section and copyright section).  
> 
> Based on  my own recent experiences  as an editor with  
> documents before the IESG, I think that the  Security 
> Considerations section will not be accepted
> method behind the "use  MD5 to secure the LDP sessions" and  
> they will for a bit more (quite a bit more probably) than "if 
> you want security encrypt your packets."
> 
> 
>

---

From: Eric Rosen <[email-masked]>
Date: Wed, 14 Apr 2004 13:35:15 -0400

I note  that both documents describe  the operation of the  VPLS data plane,
e.g., MAC address  learning, flooding, etc.  It's never  been quite clear to
me whether the data plane is supposed  to operate the same in both specs, or
whether there are some intentional differences.  If there is no disagreement
about the  operation of the  data plane, then  I don't understand why  it is
described in two  different documents.  (Generally a WG  doesn't produce two
different documents  describing something on which there  IS consensus!)  If
there  are intentional  differences,  then  these will  need  to be  clearly
described  in  Applicability  Statements,  and  one  might  think  that  the
applicability statements should be last called  at the same time as the base
specs.

---

From: Ali Sajassi <[email-masked]>
Date: Thu, 15 Apr 2004 15:58:12 -0700

Section 4. (Data Plane) of this draft overlaps with data-plane description 
of draft vpls ldp very much but some of the info of this section is 
ambiguous and maybe incorrect. So I would suggest to either:

a) remove this section and instead make a reference to data-plane sections 
of vpld ldp OR
b) remove data-plane descriptions from both draft and make a stand alone 
draft where it describes both data plane operation and the related issues.

The data-plane operation for both of these draft should be identical and if 
not, then I would like to know why ?

Section 4.1 says:
"Ethernet frames received from CE devices are encapsulated for transmission 
over the packet switched network connecting the PEs. The encapsulation is 
as in [10], with one change: a PE that sets the P bit in the Control Flags 
strips the outermost VLAN from an Ethernet frame received from a CE before 
encapsulating it, and pushes a VLAN onto a decapsulated frame before 
sending it to a CE."

The raw and tagged modes as described in [10] should be sufficient. If not 
and any changes to it needs to be done, then I'd like to know the rational 
behind it.

Section 4.2.1, 3d para says:

"In qualified learning, the learning decisions at the VE are based on the 
customer ethernet packet's MAC address and VLAN tag, if one exists. If no 
VLAN tag exists, the default VLAN is assumed. Effectively, within one VPLS, 
there are multiple logical FIBs, one for each customer VLAN tag identified 
in a customer packet. In unqualified learning, learning is based on a 
customer ethernet packet's MAC address only. In other words, at any VE, 
there is only one FIB per VPLS."

A few clarifications:

1) Qualified/unqualified learning is not based on customer VLAN but it is 
based on whether those VLANs are service-delimiting or not. If service 
delimiting, each VLAN tag points to separate filtering database and if not 
they point to the same filtering database.

2) If there are multiple service instances (and multiple filtering 
databases) share the same VPLS for qualified mode, then how do you limit 
the broadcast domain for each service ?

Also in section 4.2.2 where it talks about PE that are incapable of 
flooding,  and either L2PE or upstream PEs need to do the 
flooding/replication for them, it is not clear whether this flooding is 
done over the same PWs between the PEs or different PWs. This should be 
clarified.

Also last but not least, we should get the terminology for both drafts in 
synch with l2vpn framework - e.g., MTU-s and L2PE should be changed to u-PE 
and so on ....

-Ali

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 16 Apr 2004 11:53:44 -0700 (PDT)

On Wed, 14 Apr 2004, Eric Rosen wrote:

> whether there are some intentional differences.

Good point.  There are no intentional differences; some minor
differences arise from the fact that the ldp draft also specifies the
operation of spokes in H-VPLS.

> If there is no disagreement
> described in two  different documents.

I am fine with pulling out the data plane operation into an
independent document; I had suggested that a long time back, but I
guess there were more important things going on.

As people comment on the docs, it would help if they include whether or
not they think that splitting out the data plane part is a good idea.

Kireeti.
-------