Subject: Comments on draft-ietf-l2vpn-signaling-03.txt

From: David McDysan <[email-masked]>
Date: Wed, 09 Mar 2005 09:43:54 -0500

As mentioned in the L2VPN meeting on March 8, I offer the following major
and editorial comments on the subject draft.

http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-03.txt

Dave

Major:

Sections 2.3, 4.2: At least mention of the following should be made in the
document:

The AGI and AII from the Generalized FEC previously are specified in
standard single hop PW a simple matching operation by the PW endpoints. This
document defines a specific format and semantics for these fields in an
inter-AS . This means that a network operator could not use these fields for
other administrative purposes when the procedures defined in this document
are followed.  

(An alternative would be to specify more structure or a syntax for the AGI
and AII fields that would support the use defined in this document, as well
as support other uses, such as for administrative purposes by a service
provider.)

Section 3.1.1.2: This approach has a scalability challenge in some
scenarios. The number of <VPN-id, AII> pairs advertised is equal to the
number of VPWS connections. In a large service provider network this could
be O(10^6). Suggest that this be noted in this section. The concept of pools
of attachement circuit pools in sections 3.3 would reduce this by a factor
proportional to the number of circuits per pool. 

Section 3.3.1: Where are the procedures mentioned in the first bullet
specified? Being able to actually provision a PW to a specific attachment
circuit is an important function that needs to be specified somewhere to
achieve interoperability. Also suggest that the case mentioned in the last
paragraph not be stated as optional. Being able to specify the (virtual)
attachment circuit that is bound to a particular pseudowire is important to
support conventions of assigning indetifiers (e.g., DLCI, VPI/VCI, VLAN) in
a provisioned manner is important for configuration of attached devices and
troubleshooting.

Section 3.5.4: The terminology in this section differs from that of section
3.5 on distributed VPLS, a number of terms are undefined (true endpoint,
direct route TLV, control point), and therefore the description is hard to
follow, and must be rewritten. The terminology used does not match that of
[PW-SWITCH], which is the only cited reference. It appears to be a more
description on "splicing and the data plane" that is more general than VPLS
and could also apply to MH PW. 

Section 4.2: Conecptually, I can see how this would work but I have a number
of comments on how this needs to be more fully defined and that there should
be statements about the assumptions made and resulting performance as
follows:

1) As in option (b) of 2547bis, the interconnecting AS's must coordinate
assignment of RD and RT values. Alternatively, a correspondence between RD
and/or RT values must be provisioned at all ASBRs. The text does not clearly
state whether matching or configuration of these values is to be performed
at the ASBRs. Without a clearer specification, interoperability will not be
achieved.

2) This solution would require that all U-PEs support BGP. In some use cases
as described in MH PW requirements this would be undesirable.

3) The splicing points are distributed to all ASBRs, and a U-PE would select
an S-PE based upon other inputs, such as IGP or local configuration. 

4) The document should note that this provides resiliency in the event of
S-PE failure is two or more ASBRs interconnect Ases. The document should
also note that this means that fault detection and restoration occurs on a
BGP time scale, which at best is tens of seconds.

5) This scenario assumes that the ASBR and S-PE function sare collocated. It
is not clear how other configurations would be supported.

6) As noted above, the AGI and AII values are populated to align with BGP
and (as currently specified) do not allow any other administrative use of
these identifiers.

7) In option (b) of 2547bis, a precaution sometimes used is to install
filters to only allow specific route targets in the event that a peer
misconfigures something. In this case, this devolves to configuration on a
per PW basis. Some form of authentication such as that being developed in
L3VPN could be considered to confirm such configurations and avoid the need
for filter configuration.

Editorial:

Section 2.3: The term "Attachment VC" is used here and never defined.
Believe what is meant is "Attachment Circuit." Suggest either defining the
term or replacing it.

Section 3.1.2: Suggest summarizing the sucessful case from [PWE3-CONTROL] as
context for the description of error cases.

Section 3.3.3: Suggest summarizing the sucessful case from [PWE3-CONTROL] as
context for the description of error cases.

Section 3.4: Insertion of a "hub and spoke" example here would help
illustrate the point.

Section 3.5: ASCII art that showed the multiple PWs would make this section
more readable.

---

From: David McDysan <[email-masked]>
Date: Wed, 23 Mar 2005 09:26:04 -0500

Scott Brim asked a question about examples of "other administrative
purposes" in the following comment at the Minneapolis meeting, and I wanted
to share my thoughts with the list to solicit comments. Adding PWE3 since
(at least requirements) work is being done there also.

Potential adminstrative uses of the AGI include:
	- Customer identification
	- Customer Contact point information (or pointer to it)
	- VPN identification (could be a list of service provider IDs)

Potential administrative uses of the AAI(s) include:
	- Physical Attachment circuit information (e.g., Circuit ID)
	- Logical Attachment circuit information (e.g., VLAN, DLCI, VPI/VCI)
	- Site identification
	- Site contact info (or pointer to it)
	- Service provider identification
	- Service provider contact point info (or pointer to it)

I had thought about using the SAII/TAII as the U-PE IP addresses for MH-PW,
but use of these fields for this purpose has an issue similar to that raised
below. That is, if the fields are defined for only one purpose then other
adminstrative provisioning, troubleshooting, billing, etc. functions are not
supported.

Scott suggested using a fixed length prefix for the "routeable" part, and I
suggested a more flexible syntax (e.g., sub-TLVs, or possibly something
SIP-like that would be human readable without a protocol analyzer). 

I think defining single-purpose AGI/AII uses is OK, but would like to hear
opinions from others on the utility of a multi-purpose AGI/AII.

Dave
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of David McDysan
> Sent: Wednesday, March 09, 2005 9:44 AM
> To: [email-masked]
> Subject: Comments on draft-ietf-l2vpn-signaling-03.txt
> 
> As mentioned in the L2VPN meeting on March 8, I offer the 
> following major and editorial comments on the subject draft.
> 
> The AGI and AII from the Generalized FEC previously are 
> specified in standard single hop PW a simple matching 
> operation by the PW endpoints. This document defines a 
> specific format and semantics for these fields in an inter-AS 
> . This means that a network operator could not use these 
> fields for other administrative purposes when the procedures 
> defined in this document are followed.  
> 
> (An alternative would be to specify more structure or a 
> syntax for the AGI and AII fields that would support the use 
> defined in this document, as well as support other uses, such 
> as for administrative purposes by a service
> provider.)
>