Subject: RE: I-D ACTION:draft-ietf-l2vpn-signaling-00.txt

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 21 Oct 2003 10:31:15 -0400

Eric, Vasile,

I have two concerns regarding section 5.5.

1. The sequence of signaling messages

The document states that an N-PE must be given "A "Remote" list:  {<IP address, k>}, telling it to set up k PWs, for each U-PE, to the specified IP address."

This paragraph suggests that the N-PE autonomously sets up PWs with other N-PEs, whether it has received signaling messages from U-PEs or not.

However, I thought that in an earlier email exchange we had established that an N-PE would have to wait for a signaling message from a U-PE before it could send a message itself. The signaling (LDP Label Mapping) message contains parameters specific to the U-PE, such as Requested VLAN id or Maximum number of 
concatenated ATM cells.

Because the U-PE knows these parameters and the N-PE doesn't, PW setup has to start with a U-PE sending a signaling message to an N-PE. In turn, the N-PE forwards the message to the next-hop N-PE, which forwards it to the destination U-PE. The same is true for the Label Mapping Message that flows in the reverse direction.

2. Topology discovery

The document assumes that an N-PE knows exactly how many PWs will be routed through it. Presumably, it can make this determination because U-PEs are provisioned as wirtual ports on the N-PE. (The document says: "Every N-PE must be provisioned with the set of VPLS instances it supports, a VPN-id for each one, and a list of local U-PEs for each such VPLS")

It is not clear to me how this would work for more complex cases. What happens in the case of a dual-homed U-PE? And what happens in the case of Inter-AS VPLS? E.g. Assume that PE1 has Border-Router 12 as its next hop to reach PE2 in AS2 and has Border Router 13 as its next hop to reach PE3 in AS3. Should PE1 be provisioned as a port on BR12 as well as on BR13? And what happens if it needs to setup a PW with PE4, which could be reached through AS2 as well as through AS3?

Conclusions:

It seems to me that these issues could easily be solved if we would consider a set of spliced-together PW segments as a single multi-hop PW set up with "regular" signaling means. Specifically, I believe it is wrong to assume that an N-PE can somehow make a decision that it is an intermediate hop on an end-to-end multi-hop PW. Instead, I believe that it is up to the U-PEs to decide which node is the next hop on the end-to-end path. Subsequently, an N-PE or Border Router that receives a Label Mapping Message should be able to derive from the contents of that message what the next hop is. The cleanest solution, in my mind, is that the signaling messages contain a source and destination IP address. Currently, that is not the case. The currently proposed structure for the Generelized ID FEC assumes that only application-specific parameters like VPLS id or AC-id are used.

I propose that we consider to include source and destination IP addresses in the LDP Label Mapping Messages for PW setup. They could be part of the Generalized ID FEC or could be contained in another TLV (e.g. ERO).

Peter

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, September 05, 2003 10:40 AM
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-l2vpn-signaling-00.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Layer 2 Virtual Private 
> Networks Working Group of the IETF.
> 
> 	Title		: Provisioning Models and Endpoint 
> Identifiers in L2VPN 
>                           Signaling
> 	Author(s)	: E. Rosen, V. Radoaca
> 	Filename	: draft-ietf-l2vpn-signaling-00.txt
> 	Pages		: 22
> 	Date		: 2003-9-5
> 	
> [PWE3-CONTROL] specifies a 'signaling protocol' which uses extensions
> of LDP [RFC 3036] to set up and maintain pseudowires [PWE3-ARCH].
> Like any protocol which sets up connections, the signaling protocol
> provides a method by which each endpoint can identify the other.
> [L2VPN-FW] describes a number of different ways in which sets of
> pseudowires may be combined together into 'Provider Provisioned Layer
> 2 VPNs' (L2 PPVPNs, or L2VPNs), resulting in a number of different
> kinds of L2VPN.  Different kinds of L2VPN may have different
> 'provisioning models', i.e., different models for what information
> needs to be configured in what entities. Once configured, the
> provisioning information is distributed by a 'discovery process', and
> once the information is discovered, the signaling protocol is
> automatically invoked to set up the required pseudowires.  The
> semantics of the endpoint identifiers which the signaling protocol
> uses for a particular type of L2VPN are determined by the
> provisioning model.  This document specifies a number of PPVPN
> provisioning models, and specifies the semantic structure of the
> endpoint identifiers required. It further specifies how the endpoint
> identifiers are carried in the 'Generalized Identifier FEC' of
> [PWE3-CONTROL].  It is believed that the specified identifiers can
> also be carried within the L2TP signaling protocol, though this is
> currently not specified.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-00.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body 
> of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-l2vpn-signaling-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-l2vpn-signaling-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>