Subject: [Gen-art] draft-ietf-l2tpext-l2vpn-06.txt

From: Elwyn Davies <[email-masked]>
Date: Fri, 03 Feb 2006 20:23:10 +0000

I was selected as General Area Review Team reviewer for this specification
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Document: draft-ietf-l2tpext-l2vpn-06.txt
Intended Status: Proposed Standard (WG submission)
Shepherding AD: Mark Townsley
Review Trigger: IETF last call ended 23 Jan 2006

Summary:
This document is close to being ready for PS.  It has one minor issue 
relating to the M bit in the various AVPs (see below) and its 
readability/usefulness could be much improved by pointers to the 
relevant parts of RFC3931 for definitions and processes referred to.  It 
also could do with a terminology section to make it clear where all the 
various terms come from and expand some of the acronyms.

Minor issues:

M bit in AVPs:
==============
s4.3: In the description of the new AVPs, the M bit is specified as 
SHOULD be 0 for all three items i.e. the receiver should ignore the AVP 
if it doesn't understand it.  Two questions (one with two parts) come to 
mind:
- For each AVP, will everything work as expected if the sender includes 
the AVP and the receiver ignores it?  Should the behaviours in this 
eventuality be discussed?
- What circumstances would lead an implementer to set the M bit to 1?

A related point: in this application do any of the existing AVPs need to 
be sent with M=1?
 
At least a pointer to s5.2 of RFC3931 would help.

======================

Editorial:
s1: Acronyms PPP and LAC need expansion..  More generally a brief 
terminology section saying where terms are imported from (mostly either 
the L2TPv3 and L2VPN Framework documents) would be helpful.

s2, last para: s/cross-connect/cross-connects/

s4.1, para 1: s/to signaling L2VPNs/for signaling L2VPNs/, s/has some 
advantages/have some advantages/

s4.2: AVP, SCCRQ, SCCRP, ICRQ, ICRP, ICCN, SLI need expanding or (in the 
cased of the message IDs, noting that this is what they are and saying 
where they are defined).

s4.2: It would be worth noting that these existing AVPs are defined in 
s5.4.3 of RFC3931.

s4.3: All AVPs: should specify lengths are in octets.

s4.3: It would be useful to provide a pointer to s5.3 of RFC3931 for a 
description of hiding.

s4.3: MTU AVP should specify encoding (presumably integer, octet order?) 
of MTU.

s5.1, para 2: A pointer to the relevant IANA registry  for the  
psudowire types should be included and also a reference to 
draft-ietf-pwe3-iana-allocation-15.txt.

s5.1, para 4: s/forwarder identifier/forwarder identifiers/ (refers to 
both local and remote).

s5.2, last para:  A pointer to (presumably) to Session Mgmt Tie Breaker 
AVP in s5.4.4 of RFC3931 would help.

s5.3 (and also s1): Make it explicit that the object of the exercise is 
to create a complete mesh of interconnections between SOURCE_FORWARDERS 
and TARGET_FORWARDERS.

s5.3, algorithm: I know it is a bit pedantic but it should explicitly 
say start from beginning of SOURCE_FORWARDERS (new Step 0), and Step 1 
should say start again from the beginning of TARGET_FORWARDERS.  This 
should be matched in the diagram.

s6: Should point at the IANA registry procedures in RFC3931.

s7:  The text is rather clumsy.  Try something like: 'This specification 
does not introduce any additional security issues beyond those discussed 
in [RFC3931] and [L2VPN FW].'

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Wei Luo <[email-masked]>
Date: Tue, 07 Feb 2006 15:50:52 -0800

Thank you for the thorough review, Elwyn.  I have incorporated most of your 
suggested changes in the latest revision, enclosed herewith. The ones I 
specifically respond to below use a slightly different approach.

> various terms come from and expand some of the acronyms.

For each newly defined AVP, the specification already defines the 
receiver's behaviors when these AVPs are absent.  The behaviors when the 
receiver ignores the AVPs can be inferred based on the specification.

Will this work?  The answer is yes.  When the receiver ignores the AVPs, it 
continues to process the rest of the message as if they are absent.  Since 
it ignores the AVPs, it will not send an response back to the sender with 
these AVPs.  As the specification defines, the sender simply assumes the 
receiver uses the default values (specified for each AVP).  On the other 
hand, the sender could have a user-defined policy that refuses a connection 
that uses the default values, but that's not something the protocol 
specification should control.

> - What circumstances would lead an implementer to set the M bit to 1?

Only if the implementer does not want the session to be established if the 
receiver does not understand these AVPs.  Such an implementation, however, 
will impair its interoperability.

> A related point: in this application do any of the existing AVPs need to 

The M-bit settings of this application for the existing AVPs align with 
those specified in RFC3931, and impose no additional requirement or special 
condition.

All the M-bit issues you mentioned are described in RFC 3931 Section 5.2. 
I add some clarification and reference on the points I made above.

> At least a pointer to s5.2 of RFC3931 would help.

I expand all the acronyms and add references you mentioned in their current 
places accordingly rather than add new terminology section.

> should be matched in the diagram.

This seems to get too much into programming details.  A reasonable 
programmer should understand the basics of initialization and looping of 
the algorithm.

> in [RFC3931] and [L2VPN FW].'

The rest of the comments has been incorporated in the new draft, which also 
passed the I-D nit checker.

Thanks,

---Wei

Network Working Group                                            Wei Luo
Internet Draft                                       Cisco Systems, Inc.
February 2006

                       L2VPN Extensions for L2TP

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   The Layer 2 Tunneling Protocol (L2TP) provides a standard method for
   setting up and managing L2TP sessions to tunnel a variety of L2
   protocols.  One of the reference models supported by L2TP describes
   the use of an L2TP session to connect two Layer 2 circuits attached
   to a pair of peering LACs, which is a basic form of Layer 2 Virtual
   Private Network (L2VPN).  This document defines the protocol
   extensions for L2TP to set up different types of L2VPN in a unified
   fashion.

Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119].

Luo                                                            [Page 1]

Internet Draft      draft-ietf-l2tpext-l2vpn-07.txt        February 2006

   Table of Contents

   Status of this Memo..........................................    1

   1. Introduction..............................................    3

   2. Network Reference Model...................................    3

   3. Forwarder Identifier......................................    4

   4. Protocol Components.......................................    5
      4.1 Control Messages......................................    5
      4.2 Existing AVPs for L2VPN...............................    5
      4.3 New AVPs for L2VPN....................................    6
      4.4 AVP Interoperability..................................    8

   5. Signaling Procedures......................................    8
      5.1 Overview..............................................    8
      5.2 Pseudowire Tie Detection..............................    9
      5.3 Generic Algorithm.....................................   10

   6. IANA Considerations.......................................   13

   7. Security Considerations...................................   14

   8. Intellectual Property Statement...........................   14

   9. Copyright Notice..........................................   14

   10. Acknowledgement..........................................   15

   11. References...............................................   15
      11.1 Normative References.................................   15
      11.2 Informative References...............................   15

   12. Authors' Address.........................................   15

Luo                                                            [Page 2]

Internet Draft      draft-ietf-l2tpext-l2vpn-07.txt        February 2006

1. Introduction

   [RFC3931] defines a dynamic tunneling mechanism to carry multiple
   Layer 2 protocols besides Point-to-Point Protocol (PPP), the only
   protocol supported in [RFC 2661], over a packet-based network.  The
   baseline protocol supports various types of applications, which have
   been highlighted in the different L2TP reference models in [RFC3931].
   An L2TP Access Concentrator (LAC) is an L2TP Control Connection
   Endpoint (LCCE) that cross-connect attachment circuits and L2TP
   sessions.  L2VPN applications are typically in the scope of the LAC-
   LAC reference model.

   This document discusses the commonalities as well as differences
   among L2VPN applications with respect to utilizing L2TPv3 as the
   signaling protocol.  The acronym "L2TP" refers to L2TPv3 or L2TP in
   general in this document.

2. Network Reference Model

   In the LAC-LAC reference model, a LAC serves as a cross-connect
   between attachment circuits and L2TP sessions.  Each L2TP session
   acts as an emulated circuit, also known as pseudowire.  A pseudowire
   is used to bind two "forwarders" together.  For different L2VPN
   applications, different types of forwarders are defined.

   In the L2VPN framework [L2VPN FW], a LAC is a Provider Edge (PE)
   device.  LAC and PE are interchangeable terms in the context of this
   document.  Remote systems in the LAC-LAC reference model are Customer
   Edge (CE) devices.

   +----+  L2  +----+                      +----+  L2  +----+
   | CE |------| PE |....[core network]....| PE |------| CE |
   +----+      +----+                      +----+      +----+

                    |<- emulated service ->|
         |<----------------- L2 service -------------->|

                  L2VPN Network Reference Model

   In a simple cross-connect application, an attachment circuit is a
   forwarder directly bound to a pseudowire.  It is a one-to-one
   mapping.  Traffic received from the attachment circuit on a local PE
   is forwarded to the remote PE through the pseudowire.  When the
   remote PE receives traffic from the pseudowire, it forwards the
   traffic to the corresponding attachment circuit on its end.  The
   forwarding decision is based on the attachment circuit or pseudowire
   demultiplexing identifier.

Luo                                                            [Page 3]

Internet Draft      draft-ietf-l2tpext-l2vpn-07.txt        February 2006

   With Virtual Private LAN Service (VPLS), a Virtual Switching Instance
   (VSI) is a forwarder connected to one or more attachment circuits and
   pseudowires.  A single pseudowire is used to connect a pair of VSIs
   on two peering PEs.  Traffic received from an attachment circuit or a
   pseudowire is first forwarded to the corresponding VSI based on the
   attachment circuit or pseudowire demultiplexing identifier.  The VSI
   performs additional lookup to determine where to further forward the
   traffic.

   With Virtual Private Wire Service (VPWS), attachment circuits are
   grouped into "colored pools".  Each pool is a forwarder and connected
   through a network of point-to-point cross-connects.  The data
   forwarding perspective is identical to the cross-connect application.
   However, constructing colored pools involves more complicated
   signaling procedures.

3. Forwarder Identifier

   A forwarder identifier is assigned to each forwarder on a given PE
   and is unique in the context of the PE.  It is defined as the
   concatenation of an Attachment Group Identifier (AGI) and an
   Attachment Individual Identifier (AII), denoted as <AGI, AII>.  The
   AGI is used to group a set of forwarders together for signaling
   purpose.  An AII is used to distinguish forwarders within a group.
   AII can be unique at a per platform or per group basis.

   As far as the signaling procedures are concerned, a forwarder
   identifier is an arbitrary string of bytes.  It is up to
   implementations to decide the values for AGI and AII.

   When connecting two forwarders together, both MUST have the same AGI
   as part of their forwarder identifiers.  The AII of the source
   forwarder is known as the Source AII (SAII), and the AII of the
   target forwarder is known as the Target AII (TAII).  Therefore,
   source forwarder and target forwarder can be denoted as <AGI, SAII>
   and <AGI, TAII> respectively.

Luo                                                            [Page 4]

Internet Draft      draft-ietf-l2tpext-l2vpn-07.txt        February 2006

4. Protocol Components

4.1 Control Messages

   L2TP defines two sets of session management procedures: incoming call
   and outgoing call.  Even though it is entirely possible to use the
   outgoing call procedures for signaling L2VPNs, the incoming call
   procedures have some advantages in terms of the relevance of the
   semantics.  [PWE3L2TP] gives more details on why the incoming call
   procedures are more appropriate for setting up pseudowires.

   The signaling procedures for L2VPNs described in the following
   sections are based on the Control Connection Management and the
   Incoming Call procedures, defined in Section 3.3 and 3.4.1 of
   [RFC3931] respectively.  L2TP control message types are defined in
   Section 3.1 of [RFC3931].  This document references the following
   L2TP control messages:

     Start-Control-Connection-Request (SCCRQ)
     Start-Control-Connection-Reply   (SCCRP)
     Incoming-Call-Request            (ICRQ)
     Incoming-Call-Reply              (ICRP)
     Incoming-Call-Connected          (ICCN)
     Set-Link-Info                    (SLI)

4.2 Existing AVPs for L2VPN

   The following AVPs, defined in Section 5.4.3, 5.4.4, and 5.4.5 of
   [RFC3931], are used for signaling L2VPNs.

Router ID

   The Router ID sent in SCCRQ and SCCRP during control connection setup
   establishes the unique identity of each PE.

Pseudowire Capabilities List

   The Pseudowire Capabilities List sent in the SCCRQ and SCCRP
   indicates the pseudowire types supported by the sending PE.  It
   merely serves as an advertisement to the receiving PE.  Its content
   should not affect the control connection setup.

   Before a local PE initiates a session of a particular pseudowire type
   to a remote PE, it MUST examine whether the remote PE has advertised
   this pseudowire type in this AVP, and SHOULD NOT attempt to initiate
   the session if the intended pseudowire type is not supported by the
   remote PE.

Luo                                                            [Page 5]

Internet Draft      draft-ietf-l2tpext-l2vpn-07.txt        February 2006

Pseudowire Type

   The Pseudowire Type sent in ICRQ signals the intended pseudowire type
   to the receiving PE.  The receiving PE checks it against its local
   pseudowire capabilities list.  If it finds a match, it responds with
   an ICRP without a Pseudowire Type AVP, which implicitly acknowledges
   its acceptance of the intended pseudowire.  If it does not find a
   match, it MUST respond with a CDN with an "unsupported pseudowire
   type" result code.

L2-Specific Sublayer

   The L2-Specific Sublayer can be sent in ICRQ, ICRP, and ICCN.  If the
   receiving PE supports the specified L2-Specific Sublayer, it MUST
   include the identified L2-Specific Sublayer in its data packets sent
   to the sending PE.  Otherwise, it MUST reject the connection by
   sending a CDN to the sending PE.

Circuit Status

   The Circuit Status is sent in both ICRQ and ICRP to inform the
   receiving PE about the circuit status on the sending PE.  It can also
   be sent in ICCN and SLI to update the status.

Remote End Identifier

   The TAII value is encoded in the Remote End ID AVP and sent in ICRQ
   along with the optional AGI to instruct the receiving PE to bind the
   proposed pseudowire to the forwarder that matches the specified
   forwarder identifier.

4.3 New AVPs for L2VPN

Attachment Group Identifier

   The AGI AVP, Attribute Type TBA, is an identifier used to associate a
   forwarder to a logical group.  The AGI AVP is used in conjunction
   with the Local End ID AVP and Remote End ID AVP, which encode the
   SAII and TAII respectively, to identify a specific forwarder.  When
   the AGI AVP is omitted in the control messages or contains a zero-
   length value, the forwarders are considered using the default AGI.
   Note that there is only one designated default AGI value for all
   forwarders.

   The Attribute Value field for this AVP has the following format:

Luo                                                            [Page 6]

Internet Draft      draft-ietf-l2tpext-l2vpn-07.txt        February 2006

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|H|0|0|0|0|    Length         |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              TBA              |      AGI (variable length)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The AGI field is a variable-length field.  This AVP MAY be present in
   ICRQ.

   This AVP MAY be hidden (the H bit MAY be 0 or 1).  The hidding of AVP
   attribute values is defined in Section 5.3 of [RFC3931].  The M bit
   for this AVP SHOULD be set to 0.  The Length (before hiding) of this
   AVP is 6 octets plus the length of the AGI field.

Local End ID

   The Local End ID AVP, Attribute Type TBA, encodes the SAII value.
   The SAII may also be used in conjunction with the TAII to detect
   pseudowire ties.  When it is omitted in the control messages, it is
   assumed that it has the same value as the TAII.

   The Attribute Value field for this AVP has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|H|0|0|0|0|    Length         |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              TBA              |       SAII (variable length)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The SAII field is a variable-length field.  This AVP MAY be present
   in ICRQ.

   This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for this
   AVP SHOULD be set to 0.  The Length (before hiding) of this AVP is 6
   octets plus the length of the SAII field.

Interface Maximum Transmission Unit

   The Interface Maximum Transmission Unit (MTU) AVP, Attribute Type
   TBA, indicates the MTU in octets of a packet that can be sent out
   from the CE-facing interface.  The MTU values of a given pseudowire,
   if advertised in both directions, MUST be identical.  If they do not
   match, the pseudowire SHOULD NOT be established.  When this AVP is
   omitted in the control messages in either direction, it is assumed

Luo                                                            [Page 7]

Internet Draft      draft-ietf-l2tpext-l2vpn-07.txt        February 2006

   that the remote PE has the same interface MTU as the local PE for the
   pseudowire being signaled.

   The Attribute Value field for this AVP has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|H|0|0|0|0|    Length         |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              TBA              |          Interface MTU        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Interface MTU field is a 2-octet integer value.  This AVP MAY be
   present in ICRQ and ICRP.  When a PE receives an Interface MTU AVP
   with an MTU value different from its own, it MAY respond with a CDN
   with a new result code indicating the disconnect cause.

     RC-TBA-1 - Mismatching interface MTU

   This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for this
   AVP SHOULD be set to 0.  The Length (before hiding) of this AVP is 8
   octets.

4.4 AVP Interoperability

   To ensure interoperability, the mandatory (M) bit settings of the
   existing AVPs used in L2VPN applications should be the same as those
   specified in [RFC3931].  The generic M-bit processing is described in
   Section 5.2 of [RFC3931].  Setting the M-bit of the new AVPs to 1
   will impair interoperability.

5. Signaling Procedures

5.1 Overview

   Assume a PE assigns a forwarder identifier to one of its local
   forwarders, and knows it needs to set up a pseudowire to a remote
   forwarder on a remote PE that has a certain Forwarder ID.  This
   knowledge can be obtained either through manual configuration or some
   auto-discovery procedure.

   Before establishing the intended pseudowire, each pair of peering PEs
   exchanges control connection messages to establish a control
   connection.  Each advertises its supported pseudowire types, as
   defined in [PWE3IANA], in the Pseudowire Capabilities List AVP.

Luo                                                            [Page 8]

Internet Draft      draft-ietf-l2tpext-l2vpn-07.txt        February 2006

   After the control connection is established, the local PE examines
   whether the remote PE supports the pseudowire type it intends to set
   up.  Only if the remote PE supports the intended pseudowire type, it
   should initiate a pseudowire connection request.

   When the local PE receives an ICRQ for a pseudowire connection, it
   examines the forwarder identifiers encoded in the AGI, SAII, and TAII
   in order to determine the following:

     - whether it has a local forwarder with the forwarder identifier
       value specified in the ICRQ,

     - whether the remote forwarder with the forwarder identifier
       specified in the ICRQ is allowed to connect with this local
       forwarder.

   If both conditions are met, it sends an ICRP to the remote PE to
   accept the connection request.  If either of the two conditions
   fails, it sends a CDN to the remote PE to reject the connection
   request.

   The local PE can optionally include a result code in the CDN to
   indicate the disconnect cause.  The possible result codes are:

     RC-TBA-2 - Attempt to connect to non-existent forwarder
     RC-TBA-3 - Attempt to connect to unauthorized forwarder

5.2 Pseudowire Tie Detection

   Conceivably in the network reference models, as either PE may
   initiate a pseudowire to another PE at any time, the PEs could end up
   initiating a pseudowire to each other simultaneously.  In order to
   avoid setting up duplicated pseudowires between two forwarders, each
   PE must be able to independently detect such a pseudowire tie.  The
   following procedures need to be followed to detect a tie:

   If both TAII and SAII are present in the ICRQ, the receiving PE
   compares the TAII and SAII against the SAII and TAII itself
   previously sent to the sending PE.  If the received TAII matches the
   sent SAII and the received SAII matches the sent TAII, a tie is
   detected.

   If only the TAII is present in the ICRQ, the SAII is assumed to have
   the same value as the TAII.  The receiving PE compares the received
   TAII with the SAII that it previously sent to the sending PE.  If the
   SAII in that ICRQ is also omitted, then the value encoded in the sent
   TAII is used for comparison.  If they match, a tie is detected.

Luo                                                            [Page 9]

Internet Draft      draft-ietf-l2tpext-l2vpn-07.txt        February 2006

   If the AGI is present, it is first prepended to the TAII and SAII
   values before the tie detection occurs.

   Once a tie is discovered, the PE uses the standard L2TP tie breaking
   procedure, as described in Section 5.4.4 of [RFC3931], to disconnect
   the duplicated pseudowire.

5.3 Generic Algorithm

   The following uses a generic algorithm to illustrate the protocol
   interactions when constructing an L2VPN using L2TP signaling.

   Each PE first forms a list, SOURCE_FORWARDERS, consisting of all
   local forwarders of a given VPN.  Then it puts all local forwarders
   that need to be interconnected and all remote forwarders of the same
   VPN into another list, TARGET_FORWARDERS.  The formation of the
   network topology depends on the content in the SOURCE_FORWARDERS and
   TARGET_FORWARDERS lists.  These two lists can be constructed by
   manual configuration and/or some auto-discovery procedure.

   The algorithm is used to set up a full mesh of interconnections
   between SOURCE_FORWARDERS and TARGET_FORWARDERS.  An L2VPN is formed
   upon finishing the algorithm in every participating PE of this L2VPN.

     1.  Pick the next forwarder, from SOURCE_FORWARDERS.  If no
         forwarder is available for processing, the processing is
         complete.

     2.  Pick the next forwarder, from TARGET_FORWARDERS.  If no
         forwarder is available for processing, go back to step 1.

     3.  If the two forwarders are associated with different Router
         IDs, a pseudowire must be established between them.  Proceed
         to step 6.

     4.  Compare the <AGI, AII> values of the two forwarders.  If
         they match, the source and target forwarders are the same,
         so no more action is necessary.  Go back to step 2.

     5.  As the source and target forwarders both reside on the local
         PE, no pseudowire is needed.  The PE simply creates a local
         cross-connect between the two forwarders.  Go back to step 2.

     6.  As the source and target forwarders reside on different PEs,
         a pseudowire must be established between them.  The PE first
         examines if the source forwarder has already established a
         pseudowire to the target forwarder.  If so, go back to step 2.

Luo                                                           [Page 10]

Internet Draft      draft-ietf-l2tpext-l2vpn-07.txt        February 2006

     7.  If no pseudowire is already established between the source and
         target forwarders, the local PE obtains the address of the
         remote PE, and establishes a control connection to the remote
         PE if one does not already exist.

     8.  The local PE sends an ICRQ to the remote PE.  The AGI, TAII,
         and SAII values are encoded in the AGI AVP, the Remote End ID
         AVP, and the Local End ID AVP respectively.

     9.  If the local PE receives a response corresponding to the
         ICRQ it just sent, proceed to step 10.  Otherwise, if the
         local PE receives an ICRQ from the same remote PE, proceed
         to step 11.

     10. The local PE receives a response from the remote PE.  If
         it is a CDN, go back to step 2.  If it's an ICRP, the local
         PE binds the source forwarder to the pseudowire and sends
         an ICCN to the remote PE.  Go back to step 2.

     11. If the local PE receives an ICRQ from the same remote PE,
         it needs to perform session tie detection, as described in
         Section 5.2.  If a session tie is detected, the PE performs
         tie breaking.

     12. If the local PE loses the tie breaker, it sends a CDN with
         the result code that indicates the disconnection is due to
         losing the tie breaker.  Proceed to step 14.

     13. If the local PE wins the tie breaker, it ignores the remote
         PE's ICRQ, but acknowledges receipt of the control message
         and continues waiting for the response from the remote PE.
         Go to step 10.

     14. The local PE determines whether it should accept the
         connection request, as described in the Section 5.1.
         If it accepts the ICRQ, it sends an ICRP to the remote PE.

     15. The local PE receives a response from the remote PE.  If
         it is a CDN, go back to step 2.  If it is an ICCN, the local
         PE binds the source forwarder to the pseudowire, go back
         to step 2.

   The following diagram illustrates the above procedure:

Luo                                                           [Page 11]

Internet Draft      draft-ietf-l2tpext-l2vpn-07.txt        February 2006

          --------->     Pick Next
          |           Source Forwarder
          |                 |
          |                 |
          |                 v                  N
          |        Found Source Forwarder? ----------> End
          |                 |
          |              Y  |
          |                 v
          |              Pick Next     <--------------------------------
          |           Target Forwarder                                 |
          |                 |                                          |
          |                 |                                          |
          |  N              v                                          |
          -------- Found Target Forwarder?                             |
                            |                                          |
                         Y  |                                          |
                            v             Y                        Y   |
                      Same Router ID? ------> Same Forwarder ID? ------|
                            |                         |                |
                         N  |                      N  |                |
                            |                         v                |
                            |                      Create Local -------|
                            v                      Cross-connect       |
                    Pseudowire Already    Y                            |
                    Established Between -------------------------------|
                    Source and Target?                                 |
                            |                                          |
                         N  |                                          |
                            v                                          |
                 Local Initiates Pseudowire                            |
               Connection Request to Remote                            |
                            |                                          |
                            |                                          |
                            v                                          |
      ------->    Local Wait for Message                               |
      |           ----- from Remote   --------------                   |
      |           |                                |                   |
      |           |                                |                   |
      |           v                                v                   |
      |   Local Receives Pseudowire      Local Receives Pseudowire     |
      |     Connection Request             Connection Response         |
      |       from Remote                     from Remote              |
      |           |                                |                   |
      |           |                                |                   |
      |           v                                v             N     |
      |   Perform Pseudowire              Connection Accepted? --------|
      |   Tie Detection                            |                   |

Luo                                                           [Page 12]

Internet Draft      draft-ietf-l2tpext-l2vpn-07.txt        February 2006

      |           |                             Y  |                   |
      |           |                                v                   |
      |           |                        Local Binds Source ---------|
      |           |                      Forwarder to Pseudowire       |
      |           |                                                    |
      |           v             N                  N                   |
      |       Tie Detected?  -----> Accept Remote ----->  Reject ------|
      |           |             Connection Request?    Remote Request  |
      |        Y  |                        ^   |                       |
      |           v                        |   |   Y                   |
      |   Perform Tie Breaking             |   ------>  Local Binds ----
      |           |                        |         Source Forwarder
      |           |                        |           to Pseudowire
      |           v             N          |
      |   Won Tie Breaking?  ------>   Disconnect
      |           |                  Local Connection
      |        Y  |
      |           v
      ------ Ignore Remote
            Connection Request

6. IANA Considerations

   The IANA registry procedure in this document follows that in Section
   10 of [RFC3931].  The following are requests for new values for
   existing registries managed by IANA.

   This document defines three new L2TP control message Attribute Value
   Pairs (AVPs) to be assigned by the IANA.  These are described in
   Section 4.3 are summarized below:

     AVP-TBA-1 - Attachment Group Identifier
     AVP-TBA-2 - Local End Identifier
     AVP-TBA-3 - Interface Maximum Transmission Unit

   Section 4.3 and Section 5.1 define three new result codes for the CDN
   message are to be assigned by the IANA:

     RC-TBA-1 - Mismatching interface MTU
     RC-TBA-2 - Attempt to connect to non-existent forwarder
     RC-TBA-3 - Attempt to connect to unauthorized forwarder

Luo                                                           [Page 13]

Internet Draft      draft-ietf-l2tpext-l2vpn-07.txt        February 2006

7. Security Considerations

   This specification does not introduce any additional security
   considerations beyond those discussed in [RFC3931] and [L2VPN FW].

8. Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   [email-masked].

9. Copyright Notice

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Luo                                                           [Page 14]

Internet Draft      draft-ietf-l2tpext-l2vpn-07.txt        February 2006

10. Acknowledgement

   The author would like to thank Mark Townsley and Carlos Pignataro for
   their valuable input.

11. References

11.1 Normative References

   [RFC3931]  J. Lau et. al., "Layer Two Tunneling Protocol - Version 3
              (L2TPv3)", RFC 3931, March 2005

11.2 Informative References

   [PWE3IANA] L. Martini, "IANA Allocations for Pseudo Wire Edge to Edge
              Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-15.txt,
              November 2005

   [L2VPN FW] L. Andersson et. al., "PPVPN L2 Framework",
              draft-ietf-l2vpn-l2-framework-05.txt, June 2004

   [PWE3L2TP] W. Townsley, "Pseudowires and L2TPv3",
              draft-townsley-pwe3-l2tpv3-01.txt, June 2003

   [RFC 2661] W. Townsley et. al., "Layer 2 Tunnel Protocol (L2TP)",
              RFC 2661, August 1999.

12. Authors' Address

   Wei Luo
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   Email: [email-masked]

Luo                                                           [Page 15]