RE: [L2tpext] Comments on draft-ietf-l2tpext-tunnel-switching-01. txt (resend)

["Reinaldo Penno"<[e-mail]>]

Hello Mark,

thanks for the constructive comments. I'll update the draft and publish
another version.

cheers,

Reinaldo

>-----Original Message-----
>From: W. Mark Townsley [mailto:[e-mail]]
>Sent: Tuesday, February 19, 2002 11:03 PM
>To: [e-mail]
>Subject: [L2tpext] Comments on
>draft-ietf-l2tpext-tunnel-switching-01.txt (resend)
>
>
>
>(Trying again. I didn't see the version I sent a few days ago 
>post to the list.)
>
>I think that this Tunnel Switch document needs some work 
>before we can move
>forward. 
>
>Tunnel switching is certainly being used today, in multivendor 
>environments,
>without any formal standardization. We have been doing this 
>for a while, so
>documenting this as a "Best Current Practices," for tunnel switching is
>certainly a reasonable start. The advantages/disadvantages 
>sections in this
>document are a good beginning, though they still read a bit 
>like a marketing
>document selling tunnel switches. I think we need to be a 
>little more objective
>with the technology, pointing out all of the potential 
>pitfalls as well as the
>advantages.
>
>As for protocol work, I think we should limit ourselves to how and what
>information we should propogate through a tunnel switch. 
>Perhaps one step would
>be to identify whether an AVP is to be propogated exactly as 
>received, altered
>with a new value at the tunnel switch, "stacked" in a list at 
>each tunnel switch
>node (providing a logical traceback), or is left up in that air as
>implementation-specific. A realistic beginning might be to 
>simply identify these
>classes of AVPs and give them names. Then, we can worry about 
>which AVPs fall
>into which categories. New messages and L2TP state machine 
>events should be
>addressed in a general manner as well.
>
>As an aside, a good portion of this document details LAC/LNS 
>load balancing and
>session limits that I think is quite applicable with or 
>without a tunnel switch.
>We might want to simply move this to a different document, or 
>at least relegate
>it to a "load-balancing considerations" section.
>
>Please see WMT inline for more specific comments.
>
>Thanks,
>
>- Mark
>
>Network Working Group                                           V. Jain
>Internet-Draft                                                 R. Penno
>Expires: March 2002                                          S. McGeown
>                                                        Nortel Networks
>
>                                                                 Ly Loi
>                                                          TahoeNetworks
> 
>                                                            Mark Rayson
>                                                 BT Network and Systems
>
>                                                       Marc 
>Eaton-Brown 
>                                                  FrontRunner Solutions
>
>
>                                                        
>September, 2001 
>
>                          L2TP Tunnel Switching
>               draft-ietf-l2tpext-tunnel-switching-01.txt
>
>
>Status of this Memo
>
>
>   This document is an Internet-Draft and is in full conformance with 
>   all provisions of Section 10 of RFC2026.
>
>   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.
>
>Copyright Notice
>
>   Copyright (C) The Internet Society (2000). All Rights Reserved.
>
>Abstract
>
>   For some time now several equipment manufactures have been 
>   implementing what is called L2TP tunnel switching or L2TP multihop.
>   Although this technology has several applications and is quite 
>   widespread, there has been no effort to standardize the 
>nomenclature 
>   and methods associated with it. 
>   The goal of this document is to achieve a common denominator in what
>   is tunnel switching, its advantages and nomenclature associated with
>   it.
>
>WMT The abstract could use some work to read a little 
>better... What about
>something like:
>
>L2TP "Tunnel Switching" or "Multihop" is the process of 
>forwarding an L2TP
>tunneled data link from the logical termination point of one 
>L2TP session onto
>another at an L2TP-aware intervening node. This action has the 
>affect of
>directing a session, or groups of sessions, based on L2TP or 
>tunneled data link
>characterisics. This document will provide some examples of 
>where this technique
>might be useful in various network environments, offer 
>guidelines to Tunnel
>Switch implementors, and define associated tunnel switching 
>nomenclature, and
>provide protocol extensions to help facilitate tunnel switching.
>
>
>Penno, et al.                                                  [Page 1]
>
>
>Internet-Draft    draft-ietf-l2tpext-switching-01.txt   September, 2001
>
>
>
>Specification of Requirements
>
>   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
>   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
>   document, are to be interpreted as described in RFC 2119 [3].
>
> 
>Table of Contents
>
>   1.      What is L2TP Tunnel Switching. . . . . . . . . . . . . . . 3
>   2.      Tunnel Switching Nomenclature . . . . . . . . . . . . . . .3
>   3.      Why L2TP Tunnel Switching. . . . . . . . . . . . . . . . . 4
>   4.      Disadvantages of Tunnel Switching. . . . . . . . . . . . . 5
>   5.      Extensions to enhance tunnel switching support. . . . . . .6
>   6.      References . . . . . . . . . . . . . . . . . . . . . . . .11
>   7.      Acknowledgments. . . . . . . . . . . . . . . . . . . . . .11
>   8.      Author's Addresses. . . . . . . . . . . . . . . . . 
>. . . 11 
>           Full Copyright Statement. . . . . . . . . . . . . . . . . 12
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Penno, et al.                                                  [Page 2]
>
>
>Internet-Draft    draft-ietf-l2tpext-switching-01.txt   September, 2001
>
>
>
>1. What is L2TP Tunnel Switching
>
>   L2TP tunneling allows processing of layer2 packets to be divorced 
>   from the termination of layer2 circuit. L2TP tunnel switching 
>   facilitates moving the termination of a layer2 session further to 
>   another LNS potentially unknown to the first LAC. It does so by re-
>   tunneling the layer2 session over another L2TP tunnel to a 
>different 
>   LNS. The knowledge of whether to switch a layer2 session to another 
>   L2TP tunnel can be static or dynamic (for example when a 
>PPP session 
>   is established). 
>
> _______           _______            _______ _______          _______
>|  L2   |         |       |          |       |       |        |       |
>| User  |         | LAC A |          | LNS A | LAC B |        | LNS B |
>|_______|         |_______|          |_______|_______|        |_______|
>        
>
>|------ L2- ------|
>
>                  |---- L2/L2TP ----|
>
>                                     |-- L2 --|
>
>                                              |------ L2/L2TP -------|
>
>                                     |------- tunnel switching ------|
>
>
>   The figure above presents a typical tunnel switching scenario. The 
>   user opens a layer2 (for example PPP) session to LAC A, which puts 
>   the layer2 session into a L2TP tunnel that terminates on LNS A. If 
>   LNS A decides to further tunnel the layer2 session, it puts the 
>   layer2 session on another L2TP tunnel originating on LAC B and 
>   terminating on LNS B. LNS A and LAC B reside on the same device.  
>
>   The process of getting the layer2 session terminating on LNS A and 
>   further tunneling it to another LNS, in the example above LNS B, is 
>   called tunnel switching. 
>
>2. Tunnel Switching Nomenclature
>
>   Ingress Tunnel Aggregator (ITA): These devices are represented by 
>   the first layer of LACs, represented in the picture by LAC A. This 
>   is he node which terminates layer2 circuit and initiates the first 
>   L2TP tunnel.
>
>
>
>
>Penno, et al.                                                  [Page 3]
>
>
>Internet-Draft    draft-ietf-l2tpext-switching-01.txt   September, 2001
>
>
>   Tunnel Switching Aggregator (TSA): These are the devices 
>that act as 
>   LNS as well as LAC for a particular layer2 session therefore it 
>   typically re-tunnels layer2 session to another LNS. The TSA is 
>   composed of two parts: the TSA-LAC and the TSA-LNS.
>
>   Egress Tunnel Aggregator (ETA): These are devices that 
>terminate the 
>   layer2 session. They are represented in the picture by LNS B.
>
>3. Why L2TP Tunnel Switching
>
>WMT Please make the title of this section analogous to that in 
>Section 4. e.g
>section 4 reads: "Disadvantages of L2TP tunnel switching" So, 
>this should simply
>read "Advantages of L2TP Tunnel Switching" and the following 
>line deleted (as 
>it is then made obvious and redendant). 
>
>   This section discusses the advantages of L2TP tunnel switching. 
>
>WMT General comment on this section: It seems a little too 
>much like a marketing
>document selling a tunnel switch. I think it should focus a 
>little more on the
>protocol issues.
>
> * Often, the administrative domain of a LAC, an ILEC or CLEC, is not  
>   same as that of LNS, typically an ISP terminating subscriber's    
>   Layer2 connection. In such situations, a multi tier deployment with
>   tunnel switching helps the LEC (ILEC or CLEC) mask its internal 
>   network architecture from the ISPs. In particular, it eases the 
>   configuration across different administrative domain. For example,
>   for every new ITA added in the system, ISP doesn't need to 
>   reconfigure its LNSs  - for them LACs are always same (TSAs).
>
> * L2TP tunnel switching divorces the location of "decision-maker" LNS.
>   Certain deployments do not have decision-making capabilities on LAC 
>   For example PC based LACs might not have mechanisms to be configured
>   with policies a service provider wants to adopt; On other hand, it
>   might not be desirable to expose such policies to every 
>customer LAC 
>   CPE. The decision to choose the right LNS, for load balancing or 
>   other administrative purposes, when multiple LNSs are available, 
>   might not be done best by the first LAC always. Not all LACs should 
>   be expected to exhibit such rich functionality, features and 
>   flexibility. 
>
>WMT Rather than "decision-making" could we say "policy"? From 
>a protocol
>perspective, the above two points below might simply be 
>collapsed into a
>reference that a TSA is quite useful if one's policy is 
>distributed across
>management domains or various equipment. Suggesting that an 
>LAC should or should
>not exhibit a given set of rich functionality might be going a 
>bit too far...
>It's pretty easy for the equipment to include the software to 
>*make* the policy
>decision, quite another thing for an administrative domain to 
>*have* the
>necessary information to make the decision. The latter I think 
>is a reasonable
>guidelines for vendors to build equipment and protocols for, 
>the former strikes
>me a bit as laziness :-)
>
> * L2TP tunnel switching allows using a common L2TP tunnel on LAC for 
>   sessions that are actually destined to different LNSs. This enables
>   wholesaling layer2 sessions destined to any LNS go over a few 
>   tunnels.
>
>WMT The above point is somewhat obvious, and is certainly 
>redundant with the
>exhaustive tunnel reduction analysis that follows, I think it 
>may be omitted.
>
> * L2TP tunnel switching might reduce the total number of tunnels in a 
>   meshed environment. The advantage of fewer tunnels would primarily 
>   be in a configuration and provisioning ease. The reduction of 
>   tunnels can be seen from three different angles, from the entire 
>   system, from the ITA and from the last ETA point of view. 
>
>WMT I would suggest something like this for the point above:
>
>"L2TP tunnel switching may be used to reduce the number of 
>tunnels in a fully
>meshed environment. An advantage here may be reflected in a 
>lesser number of
>LAC to LNS relationships one has to manage by providing an 
>aggregate point
>for configuration, network management, and provisioning.  This 
>could be of
>particular concern when tunnels cross administrative 
>boundaries. An analysis of
>the this point is given from three different perspectives: 
>Entire System, ITA,
>and ETA."
>
> * Entire System
>
>   In a traditional deployment, the total number of L2TP sessions   
>   between N LACs (ITA) and M LNSs (ETA) is N*M, assuming there is 
>   at least one layer2 session from every LAC that needs to be 
>   terminated on each LNS. With tunnel switching, this number can be
>   reduced to (#ETA + #ITA) * (#TSA).
>
>Penno, et al.                                                  [Page 4]
>
>
>Internet-Draft    draft-ietf-l2tpext-switching-01.txt   September, 2001
>
>
>
>     Of course the advantage on the reduction of tunnels in the system 
>     only holds when the (#TSA)is less than the number of LNS1s (see 
>     picture below). 
>
>   * ITA
>
>     From the first layer of LACs point of view, the reduction in the 
>     number of tunnels holds whenever ITA*TSA < TSA*ETA, which is true 
>     for most deployments.
>
>   * ETA
>
>     On the other hand, the advantage on the reduction of tunnels from 
>     the last LNS (LNS2) point of view in comparison with LNS1 is 
>     considerable, since the M*(#TSA) is usually much less than M*N. 
>
>
> ____           ______            ______ ______                ______
>| PC |         | LAC1 |__________| LNS1 | LAC2 |______________| LNS2 | 
>|____|         |______|\      ___|______|______|              |______|
>                        \    /
>                         \__/
>                        ___/\                        
> ____           ______ /     \    ______ ______                ______
>| PC |         | LAC1 |_______\__| LNS1 | LAC2 |______________| LNS2 | 
>|____|         |______|          |______|______|              
>|______|  
>                   .       .             .                     
>   .        
>                   .                     .                        .
>                   .     /   \           .                        .
> ____           ______  /     \   ______ ______                ______
>| PC |         | LAC1 |/       \_| LNS1 | LAC2 
>|______________| LNS2 |  
>|____|         |______|          |______|______|              |______|
>
>
>4. Disadvantages of L2TP tunnel switching:
>
> * Focal point of failure: As TSA aggregates more and more tunnels, 
>   it becomes a focal point for failure, as compared to if ITAs had 
>   tunnels to ETAs directly. 
>
> * Multiple Negotiations: Subscriber might be authenticated/LCP 
>   multiple times because each TSA might have its own criteria to 
>   determine if subscriber should be authenticated or if LCP 
>parameters 
>   negotiated (proxy-LCP) are appropriate. 
>
>
>WMT I might call this "increased signalling" or some such. 
>"Negotiation" is
>fairly PPP specific, and is OK for the example that follows. 
>But, this is also
>true for L2TP signalling (or any other protocol that L2TP 
>might carry which has
>to complete before forwarding may occur).
>
>
>
>
>
>Penno, et al.                                                  [Page 5]
>
>
>Internet-Draft    draft-ietf-l2tpext-switching-01.txt   September, 2001
>
>
> * Session limit within an L2TP tunnel: Bundling sessions within a 
>   single L2TP tunnel makes one deployment more likely to hit the 65k 
>   limit inherent of the L2TP protocol faster than if you have unique 
>   tunnels. Care should be taken while deploying L2TP tunnel switching 
>   to not exceed this limit due to aggregation of various sessions in 
>   limited number of tunnels.
>
>WMT Other disadvantages:
>
>* Packet switching performance may be inhibited. Unless the 
>TSA is operating at
>line rate, or at least as fast as the native packet switching 
>performance of the
>underlying network the L2TP packets are traversing, then there may
>be a performance degredation at the TSA.
>
>* Routing may be non-optimal. Passing through the TSA may 
>require a packet to
>traverse more hops than is optimal before reaching its final 
>destination. Note
>that this is an issue with tunneling in general, that is simply further
>mitigated 
>by the fact that there are more tunnels to steer through.
>
>* Session source tracing. A session which passes through a TSA 
>loses much of its
>source destination information from an L2TP perspective. Thus, 
>if there is a
>problem with a given session at an LNS, it becomes more 
>difficult to trace the
>session back to the original LAC from which it began.
>
>* L2TP parameters lossed in TSA transit. RFC2661 does not 
>specify how exactly to
>propogate information arriving in L2TP AVPs from one session or control
>connection to another at a TSA. Thus, there may be 
>inconsistency in what
>information is propogated, omitted, or replaced at each TSA. 
>(This document
>should probably address this concern specifically).
>
>5. Extensions to enhance tunnel switching support
>
>   In this section we present new AVPs (and motivation behind them) 
>   that can enhance tunnel switching support beyond what is usually 
>   deployed today. These extensions are only applicable for 
>L2TP tunnel 
>   switching.
>
>5.1 Problem Statement
>
>   When an TSA <-> ETA tunnel collapses for one reason or 
>another (link 
>   failure, etc), the initial ITA<->TSA link continues to function 
>   normally, even though there is nowhere for the layer2 traffic to go 
>   once it gets to this TSA point. This causes a major disruption of 
>   service impact, as several subscribers who were knocked off the 
>   network will not be able to get back on the network.  This 
>creates a 
>   "black hole" condition, which directs all new sessions to the TSA, 
>   which has no path to the ETA. All new session attempts for this ETA 
>   fail.
>
>WMT Given that this is a "Problem Statement" shouldn't it at 
>least be defined as
>a disadvantage? Perhaps with a forward reference to how we are 
>going propose
>fixing it later in the document.
>
>5.2 Tunnel Set Dependency
>
>   A new object L2TP Dependency should be defined to maintain a 
>   relationship between the ITA to TSA tunnels and the TSA to ETA 
>   tunnels. 
>
>   This object can be utilized by ITA to route away L2TP sessions from 
>   failures in the TSA to ETA connection. Information about failures 
>   between TSA and ETA should be provided to ITA through a new set of 
>   AVPs defined below. 
>
>5.3 Tunnel Dependency Load AVP (All Control Messages)
> 
>   The Tunnel Dependency Load AVP, Attribute Type XS, indicates the 
>   capacity to carry L2TP sessions from TSA to ETA for certain 
>   "service profile" (e.g., a ISP or Domain Name)
>
>   
>
>
>
>
>
>
>Penno, et al.                                                  [Page 6]
>
>
>Internet-Draft    draft-ietf-l2tpext-switching-01.txt   September, 2001
>
>
>   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
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                  Number of Services Profiles                  |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | SPN Length    | Service Profile Name ... (arbitrary length)   |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                       Maximum  Load                           |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                       Current Load                            |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>      The Number of Services Profiles indicates the number of 
>      occurrences of the tuple (Service Profile Name, Maximum Load, 
>      Current Load).
>
>      The Service Profile Name is up to 256 bytes long, but MUST be at 
>      least 1 octet. This name should be as broadly unique as 
>possible, 
>      because the tunnels between ITA to TSA can contain sessions for 
>      different service profiles. 
>
>      The Maximum Load indicates the Maximum reference capacity for a 
>      service profile. It could be the number of maximum tunnels 
>      supported by the system at a point in time, maximum amount of 
>      bandwidth, or some other metric that reflects ratio 
>
>      The Current Load indicated the current capacity of the 
>system, it 
>      could be the number of active tunnels at a point in time, amount 
>      of utilized bandwidth, or some other metric that reflects ratio. 
>
>WMT It's not entirely clear how this new AVP will be used, and 
>what a "Service
>Profile Name" is... This sounds a lot like the "Private Group 
>ID" which still is
>difficult to quantify. Also, what is Tunnel Switching specific 
>about it? From
>what I do gather from the description, it seems that this 
>could be used in an
>environment which didn't have a TSA at all.
>
>      This AVP MAY be be hidden (the H-bit can be either 0 or 1). The 
>      M-bit for this AVP MUST be set to 0.  
>
>5.4. Loop Prevention AVP
>
>   The Loop Prevention AVP, Attribute Type TBD, can be used to detect 
>   the existence of loops in the TSA network.  
>
>       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
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                       Number of Nodes                         |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | HN Length     |          HostName ... (arbitrary length)      |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                   IP address of the Node                      |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>WMT The AVP identified here makes a lot of assumptions about 
>identifying an
>L2TP node. For instance, this doesn't seem to work if you have 
>more than one IP
>address for a given L2TP node, or you have a stack of L2TP 
>nodes with different
>IP addresses operating as a logical group to load balance 
>across. Not to mention
>that L2TP may no be operating over IPv4 (could be FR, ATM, IPv6...).
>
>WMT If one is truly just concerned about an L2TP session 
>crossing a given TSA 
>(as this AVP seems to address) rather than a logical group, a 
>better solution 
>might be to combine the Vendor ID that we all have a unique 
>value for, together 
>with a "serial number" that I am sure we all have in our boxes 
>somewhere. The
>combination of the two of these should certiainly yield a 
>unique box identifier
>which would be better suited for loop prevention through a 
>given piece of 
>equipment. 
>
>WMT If you want to prevent loops across logical nodes, there 
>is no easy solution 
>to this as it requires a logical, unique, value to be managed 
>across the VPN. 
>In the PWE3 L2VPN space we resort to a  "VPN ID", which in 
>L2TPv3 we are 
>including in the "End Identifier" AVP. This might be a better 
>loop prevention 
>value, though it is something new to be configured and managed.
>
>
>Penno, et al.                                                  [Page 7]
>
>
>Internet-Draft    draft-ietf-l2tpext-switching-01.txt   September, 2001
>
>
>      The Number of Nodes indicates the occurrences of the tuple (Host
>      Name, IP Address). Each tuple identifies a node in the tunnel-
>      switched-path.
>
>      The Hostname is MUST be same as used on the Hostname AVP 
>when the 
>      tunnel was established.
>
>      The IP address field represents the IP address which was used to
>      establish the tunnel.
>      
>      This AVP is updated by LAC when a new tunnel is being 
>      established. It adds (Hostname, IP address) tuple to the 
>existing 
>      AVP and increments Number of Nodes.
>
>
>5.5 CDN Messages and L2TP Tunnel Switching
>
>   The Call-Disconnect-Notify (CDN) message is an L2TP control message 
>   sent either by the LAC or LNS to request disconnection of a 
>specific 
>   call within the L2TP tunnel. Its purpose is to inform the peer of 
>   the disconnection and the reason why it occurred.
>
>   As an indication to its use, an Incoming-Call-Request message is  
>   generated by the LAC when the subscriber's call is 
>detected. The LAC 
>   selects a Session ID and sends the Incoming-Call-Request to 
>the LNS; 
>   it then waits for a response from the LNS - keeping the subscribers 
>   call waiting. It is at this point that the LNS may decline 
>to accept 
>   the call 
>
>WMT The above text is summarizing RFC2661. The reader is 
>expected to be familiar
>with L2TP, so I think most of this is unnecessary. 
>
>   It is also understood that if the call is terminated before the LNS 
>   accepts it, a Call-Disconnect-Notify is sent by the Calling LAC to 
>   indicate this condition, and is understood to be catered for within 
>   current L2TP implementation. Any CDN messages originating from the 
>   LAC are therefore omitted from the scope of this proposal, however 
>   the Calling LAC must interpret the CDN messages received from the   
>   LNS correctly, and must take the appropriate steps to ensure that 
>   the intention of the CDN messages are carried out as expected.
>
>WMT I don't see why we need to omit any CDN events from this 
>proposal. It's
>certainly possible for the TSA to have begun setting up a 
>secondary tunnel upon
>receipt of the ICRQ, thus, the CDN must be propogated in a 
>similar manner.
>
>   In the case where an L2TP Tunnel Switch has successfully extended 
>   the Control Connection to the ETA, and it returns general CDN 
>   messages during session establishment, any such messages may be 
>   passed transparently through to the ITA or may be 
>interpreted by the 
>   TSA; such scenarios are included.
>
>WMT The above (run-on) sentence seems to essentially say: "If 
>the TSA receives a
>CDN, it can interpret it or pass it through transparently." 
>
>
>Penno, et al.                                                  [Page 8]
>
>
>Internet-Draft    draft-ietf-l2tpext-switching-01.txt   September, 2001
>
>
>   The following is proposed with regards of tunnel switching and CDN 
>   messages:
>
>   o  To define the circumstances that warrants the ETA to 
>send general 
>      protocol CDN messages to the LAC over and above all other 
>      signaling mechanisms defined in RFC2661.
>   o  To include decisions that may be undertaken by an TSA.
>   o  To include assurances that multiple TSA peering is supported.
>
>WMT I would avoid the use of the word "peering." This term 
>generally has far
>more connotations among service providers in the routing world 
>than I think is
>intended in this document. 
>
>
>5.6 Scenarios for generating CDN messages
>
>   The proposed causes and recommended LNS generated CDN messages for 
>   each scenario are documented here.
>
>5.6.1 LNS specific CDN Message
>
>   Here the TSA-LNS or Peering LNS cannot accept another Session and 
>   signals to the downstream LAC.
>
>   o The TSA-LNS or Peering LNS reaches a pre-determined threshold, 
>     this may be administrative or it may be a system function. As a 
>     result, CDN Code-7 is generated by the LNS and passed to the 
>     downstream LAC.
>
>   The downstream LAC should change the state of the upstream peer to 
>   'busy' and apply an administrative hold-down. Thereafter 
>the TSA-LAC 
>   or ITA should try all possible LNS peers - if there are no 
>   available LNS peers the CDN Code should be passed to the downstream 
>   LAC by the TSA-LNS only. The Calling LAC may choose to clear the 
>   call.
>
>WMT All of this max-session logic applies generally as well as 
>to tunnel
>switching. I'm not sure this is the correct home for all of this. 
>
>5.6.2 TSA-LAC specific CDN Message
>
>   This scenario only affects the TSA-LAC, which cannot establish 
>   another session due to it reaching the aggregate session limit.
>
>   o If the TSA-LAC exceeds max-sessions then it may signal to the 
>     TSA-LNS to generate a CDN Code-4 for the downstream LAC. 
>
>WMT Do we really need to model the internal state between the 
>"TSA-LAC" and
>"TSA-LNS" ? This might be more complexity than is necessary to provide
>implementation guidance.
>
>   The downstream LAC should change the state of the upstream peer to  
>   'busy' and apply an administrative hold-down. Thereafter 
>the TSA-LAC 
>   or Calling LAC should try all possible LNS peers - if there are no 
>   available LNS peers the CDN Code should be passed to the downstream 
>   LAC by the TSA-LNS only. The Calling LAC may choose to clear the 
>   call.
>
>
>
>
>
>Penno, et al.                                                  [Page 9]
>
>
>Internet-Draft    draft-ietf-l2tpext-switching-01.txt   September, 2001
>
>
>5.6.3 Calling LAC Control Connection failures
>
>   If there is a problem for the LAC to establish an L2TP tunnel,   
>   because the Control Connection to the LNS is down, then a general 
>   CDN message may or may not be appropriate depending upon the LAC 
>   type. Three scenarios are mentioned here.
>
>   o The Calling LAC cannot establish a Control Connection with the 
>     Peering LNS.
>
>   If the Calling LAC cannot continue with a session because 
>there is   
>   no Control Channel then it should try another L2TP peer. 
>The Calling 
>   LAC should record the unavailability of the Peering LNS and mark it 
>   as unavailable for a period of time that is determined by the 
>   Administrator.
>
>   o The TSA-LAC cannot establish a Control Connection with the 
>     upstream LNS
>
>   If the TSA-LAC cannot continue with a session because there is no 
>   Control Channel then a CDN Code-1 message may be generated by the 
>   TSA-LNS to signal to the upstream LAC to try another L2TP peer. 
>
>   The TSA-LAC should change the state of the upstream peer to 
>'dead'    
>   and apply an administrative hold-down. Thereafter the 
>TSA-LAC should 
>   try all possible LNS peers - if there are no available LNS 
>peers the 
>   CDN Code should be passed to the downstream LAC by the 
>TSA-LNS only. 
>
>   o Calling LAC receives CDN Code-1
>
>   If the Calling LAC receives CDN Code-1, then it should try another 
>   L2TP peer. The Calling LAC should record the unavailability of the 
>   upstream LNS and mark it as unavailable for a period of 
>time that is 
>   determined by the Administrator. The Calling LAC will thereafter 
>   clear the call.
>
>WMT More load-balancing specific text that I am not sure is 
>primarily applicable
>to tunnel switching.
>
>5.6.4 LNS Session Failure
>
>   Unable to accept the incoming call the peer LNS may return the  
>   correct CDN message defined above or it may be unaware of these 
>   requirements.
>
>   The following are therefore best provided by implementation since 
>   there are a number of options that may be selected.
>
>   * The Administrator may choose to interpret all CDN messages 
>     generated by the upstream LNS. This is typically because the LNS 
>     employs the CDN Codes defined above (and may be 
>implemented as the 
>     default option).
>
>
>Penno, et al.                                                 [Page 10]
>
>
>Internet-Draft    draft-ietf-l2tpext-switching-01.txt   September, 2001
>
>   * The Administrator may choose to ignore the CDN messages generated 
>     by the upstream LNS, and by so doing may alert the downstream LAC 
>     to mark it as unavailable for a period of time. This is typically 
>     due to the upstream LNS being unaware of the CDN Codes defined 
>     above.
>
>   * The Administrator may choose to relay any CDN messages generated  
>     by the upstream LNS transparently through to the downstream LAC. 
>     This caters for the scenario where the TSA is not 
>interpreting the 
>     CDN Codes correctly or the topology does not lend itself to the 
>     TSA intercepting CDN messages.
>
>6. References 
>
>   [RFC 2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn,
>              B. Palter, "Layer 2 Tunnel Protocol (L2TP)", RFC2661,
>              August 1999.
>                                                               
>                             
>   [RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD
>              51, RFC 1661, July 1994.
>
>   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
>              Requirement Levels", BCP 14, RFC 2119, March 1997.
>    
>7. Acknowledgments 
>    
>   Thanks to W. Mark Townsley for his valuable comments 
>    
>  
>8. Author's Addresses 
>    
>   Vipin Jain
>   Nortel Networks, Inc. 
>   2305 Mission College Boulevard
>   Building SC9  
>   Santa Clara, CA 95054
>   Email: [e-mail]
>
>
>   Reinaldo Penno
>   Nortel Networks, Inc. 
>   2305 Mission College Boulevard
>   Building SC9  
>   Santa Clara, CA 95054
>   Email: [e-mail] 
>
>
>
>
>
>
>
>Penno, et al.                                                 [Page 11]
>
>
>Internet-Draft    draft-ietf-l2tpext-switching-01.txt   September, 2001
>
>   Ly Loi
>   Tahoe Networks, Inc. 
>   3052 Orchard Drive 
>   San Jose, CA 95134 
>   Phone: [phone] 
>   Email: [e-mail]
>
>   Mark Rayson
>   British Telecom, Inc. 
>   B67 Room 106
>   BT Research Laboratories
>   Martlesham Heath
>   IPSWITCH, Suffolk IP5 3RE
>   Phone: [phone]
>   Email: [e-mail]
>
>   Marc Eaton-Brown 
>   FrontRunner Solutions, Ltd.
>   131 Finsbury Pavement
>   Moorgate
>   London EC2A 1NT
>   Phone: [phone]
>   Email: [e-mail]
>
>Full Copyright Statement
>
>   Copyright (C) The Internet Society (2000). All Rights Reserved.
>
>   This document and translations of it may be copied and furnished to
>   others, and derivative works that comment on or otherwise explain it
>   or assist in its implementation may be prepared, copied, published
>   and distributed, in whole or in part, without restriction of any
>   kind, provided that the above copyright notice and this paragraph
>   are included on all such copies and derivative works. However, this
>   document itself may not be modified in any way, such as by removing
>   the copyright notice or references to the Internet Society or other
>   Internet organizations, except as needed for the purpose of
>   developing Internet standards in which case the procedures for
>   copyrights defined in the Internet Standards process must be
>   followed, or as required to translate it into languages other than
>   English.
>
>   The limited permissions granted above are perpetual and will not be
>   revoked by the Internet Society or its successors or assigns.
>
>   This document and the information contained herein is provided on an
>   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
>   TASK FORCE DISCLAIMS 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.
>
>Penno, et al.                                                 [Page 12]
>
>
>Internet-Draft    draft-ietf-l2tpext-switching-01.txt   September, 2001
>
>Acknowledgement
>
>   Funding for the RFC editor function is currently provided by the
>   Internet Society.
>
>_______________________________________________
>L2tpext mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/l2tpext
>