Subject: [L2tpext] RE: Comments on draft-ietf-l2tpext-mcast-02.txt

From: "BOURDON Gilles FTRD/DAC/ISS" <[email-masked]>
Date: Mon, 5 Aug 2002 18:21:14 +0200

Hi,

Thanks again for your comments, my questions/comments inline (GB:).

Gilles.

-----Message d'origine-----
De : W. Mark Townsley [mailto:[email-masked]]
Envoye : vendredi 2 aout 2002 16:33
A : BOURDON Gilles FTRD/DAC
Cc : [email-masked]
Objet : Comments on draft-ietf-l2tpext-mcast-02.txt

Bonjuor Gilles,

Please find comments and questions inline by WMT. 

Thanks,

- Mark 

Network Working Group                                         G. Bourdon

Internet Draft                                        France Telecom R&D

Document: draft-ietf-l2tpext-mcast-02.txt                    August 2002

Category: Experimental

                        L2TP Multicast Extension 
                   <draft-ietf-l2tpext-mcast-02.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. 

Abstract 
    
   The Layer Two Tunneling Protocol (L2TP) [RFC2661] provides a standard

   method for tunneling PPP [RFC1661] packets.  This document describes 
   an extension to L2TP, in order to have an efficient use of L2TP 
   tunnels within the context of deploying multicast services whose data

   will have to be conveyed by such tunnels. 

WMT Editorial: No RFC references allowed in an abstract. 
    
Table of Contents 
    
   1.      Introduction................................................2

   1.1.    Conventions used in this document...........................3

   1.2.    Terminology.................................................3

   2.      Motivation for a session-based solution.....................4

   3.      Tunnel establishment........................................4

   3.1.    Negotiation phase...........................................4

   3.2.    Multicast Capability AVP (SCCRQ, SCCRP).....................4

   4.      L2TP multicast session establishment........................5

   4.1.    IGMP states in LNS..........................................5

   4.2.    Triggering..................................................6

   5.      L2TP multicast session opening process......................6

Bourdon                    Expires February 2003               [Page 1] 

Internet Draft      draft-ietf-l2tpext-mcast-02.txt         August 2002 

   5.1.    Multicast Session AVP (OCRQ)................................7

   5.2.    OCRQ........................................................7

   5.3.    OCRP........................................................8

   5.4.    OCCN........................................................8

   6.      Session maintenance and management..........................8

   6.1.    Outgoing Sessions List updates..............................9

   6.1.1.  New Outgoing Sessions AVP (MSI).............................9

   6.1.2.  Withdraw Outgoing Sessions AVP (MSI).......................10

   6.2.    Multicast Packets Priority AVP (MSI).......................11

   6.2.1.  Global configuration.......................................12

   6.2.2.  Individual configuration...................................12

   6.2.3.  Priority...................................................13

   7.      Multicast session teardown.................................13

   7.1.    Operations.................................................13

   7.2.    Result Codes...............................................14

   8.      Traffic merging............................................14

   9.      IANA Considerations........................................14

   10.     Security Considerations....................................15

   11.     References.................................................15

   12.     Acknowledgments............................................15

   13.     Author's Addresses.........................................16

WMT Looks like some of your paragraphs have been merged (e.g. no space
between,
or fully concatenated) in the Intro and throughout the document.

GB: I double-checked the file and I didn't notice any editing/paging
issue in the document. Could you point one of these problems ?

1. Introduction 
    
   The deployment of IP multicast services may co-exist with L2TP tunnel

   engineering. From this perspective, the forwarding of multicast data 
   within L2TP sessions may impact the throughput of L2TP tunnels. This 
   proposal aims to reduce this impact by applying replication mechanism

   of multicast traffic only when necessary. 
   The solution described herein provides a mechanism for transmitting 
   multicast data only once for all the L2TP sessions that have been 
   established in a tunnel, each multicast group having a dedicated L2TP

   session. 
   Within the context of deploying IP multicast services, it is assumed 
   that the routers of the IP network that embed a L2TP Network Server 
   (LNS) capability may be involved in the forwarding of multicast data,

   towards users who access the network through an L2TP tunnel. Then the

   LNS is in charge of replicating the multicast data for a multicast 
   group G for each L2TP session that is used by a receiver who has 
   actually subscribed to group G. The solution described here gives the

   ability for a LNS to send multicast data once and make the L2TP 
   Access Concentrator (LAC) perform the traffic replication. By doing 
   so, it is expected to spare transmission resources in the core 
   network that supports L2TP tunnels. This multicast extension to L2TP 
   is designed so that it does not affect the behavior of L2TP equipment

   under normal conditions. A solution to carry multicast data once in a

   L2TP tunnel is interesting for service providers since edge 
   equipments are aggregating more and more users. This is particularly 
   true for operators who are deploying xDSL (Digital Subscriber Line) 
   and cable infrastructure. Therefore, L2TP tunnels that may be 
 
Bourdon                    Expires February 2003               [Page 2] 

Internet Draft      draft-ietf-l2tpext-mcast-02.txt         August 2002 

   supported by the network will have to carry multiple redundant 
   multicast data more often. The solution described in this document 
   applies to downstream traffic exclusively, i.e. data coming from the 
   LNS towards end-users connected to the LAC. This downstream multicast

   traffic is not framed by the LNS but by the LAC, thus ensuring 
   compatibility for all users in a common tunnel whatever their framing

   scheme is. 

WMT Conjecture: In cases where the operator of the LAC and operator of
the LNS
are different corporate entities, it may be an interesting business
exchange as
to who should perform the replication here. Naturally, the LAC
performing this
makes more sense from an overall bandwidth usage perspective.
Replication isn't
free, so transferring this requirement from the LNS to the LAC is a
transfer of
capital investment requirement as well. I suppose these issues exist
with
cross-domain multicast in general though, and is something for the
bean-counters
to figure out....

GB: Yes, that is definitely true... and if replicating packets as close
as possible from the edge doesn't fit any business model, then we just
have to get rid off multicast in networks. In L2TP, that's one
motivation for the LAC to announce the multicast capability on a per
tunnel basis: the LAC operator can therefore control what it
allows/forbids depending on the LNS (on a contractual basis, using a
dedicated RADIUS tag signaling for instance).

<...snip...>
    
3.2. Multicast Capability AVP (SCCRQ, SCCRP) 
    
   In order to inform the LNS that a LAC is able to handle multicast 
   sessions, the LAC sends a Multicast Capability AVP during the tunnel 
   establishment phase.  
   This AVP is sent either in a SCCRQ or SCCRP control message by the 
   LAC towards the LNS. There is no point to send this AVP from an LNS 
   to a LAC except for information or debugging purposes, since all L2TP

Bourdon                    Expires February 2003               [Page 4] 

Internet Draft      draft-ietf-l2tpext-mcast-02.txt         August 2002 

   multicast actions will be initiated by the LNS, if the remote LAC(s) 
   support the multicast extensions.  

WMT But, if your Control Connection is serving an a box which can be an
LAC or
LNS, there may be more reason than just debugging. There is no protocol
restriction disallowing initiation of an L2TP session from either side
of a
Control Connection after it is established. e.g. Once a Control
Connection is
up, either side can be an LAC or an LNS (this isn't just an L2TPv3
thing, it
exists in L2TPv2 as well). This is arguably an edge case, and you can
get around
this by qualifying that your solution only covers the canonical LAC/LNS
case
where neither side may have a dual-personality on a single Control
Connection.
        
GB: I have to admit that is a case I never imagined so far. That is
another motivation to move from a OCRQ/RP/CN message exchange to a
multicast-specific one (MCRQ/RP/CN, as you suggested). I will change
that...

<...snip...>

6.1.1. New Outgoing Sessions AVP (MSI) 
    
   The New Outgoing Sessions AVP can only be carried within a MSI 
   message type. This AVP piggybacks every Session ID to which the 
   multicast traffic has to be forwarded.   
 
Bourdon                    Expires February 2003               [Page 9] 

Internet Draft      draft-ietf-l2tpext-mcast-02.txt         August 2002 

   The AVP has the following format:  
    
      Vendor ID = to be defined  
      Attribute = GHI (16 bits) (Note: GHI to be assigned by IANA)  
    
       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       |          Vendor ID            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |              GHI              |         Session ID 0          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |              ...              |         Session ID N          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   There can be from 1 to N Session IDs present in the New Outgoing 
   Sessions AVP. This AVP must be placed in a MSI message and sent 
   immediately after the establishment of the multicast session to 
   indicate the LAC what are the initial outgoing sessions, and at any 
   time when one or more outgoing sessions appear during the multicast 
   session lifetime. Upon reception of this AVP, the LAC MUST be ready 
   to forward the multicast traffic towards the indicated sessions as 
   soon as the MSI control message is acknowledged by the LAC. 
   An LNS is allowed to send multicast traffic within the L2TP multicast

   session and stop sending multicast traffic for the related group 
   within L2TP unicast sessions mentioned in the AVP only when it 
   receives a reception acknowledgement from the LAC about the MSI 
   message carrying these session IDs. 

WMT If you are going to rely on acknowledgement of a message, you should
do so
with an explicit REQ/REP message structure. You should have to rely on
the
underlying control plane to have to provide an upcall when a specific
message is
delivered.

GB: I agree that using an explicit reply message will be more relevant,
especially for New Outgoing Session messages. I think withdrawals don't
need any acknowledgment, since we aim to stop the multicast traffic
ASAP. 

<...snip...>

6.2. Multicast Packets Priority AVP (MSI) 
        
   The Multicast Packets Priority AVP is intended to provide the LAC 
   with an indication on how to process multicast against unicast 
   traffic. Even though the LAC behavior is partially described here, 
   the nature of the traffic (layer-2 frames for regular sessions and 
   pure IP for multicast sessions) is not a criteria for priority 
   decisions. Traffic processing for the provisioning of a uniformly-
   framed traffic for the final user is described is section 8.  
    
   Three different behaviors can exist:  
        
   1) Best effort: the traffic is forwarded from the LAC to the end-user

   in the order it comes from the LNS, whatever the type of traffic. If 
   the LAC forwarding interface buffer is full, packets coming from 
   unicast session or multicast session will be dropped with equal 
   chances, depending on their order of arrival.   
   2) Standard traffic priority: traffic coming down the L2TP unicast 
   session has priority over traffic coming down the L2TP multicast 
   session.   
   3) Multicast traffic priority: traffic coming down the L2TP multicast

   session has priority over traffic coming down the L2TP unicast 
   session.  

WMT How do you handle sequencing of the merged traffic ("we don't" is
OK, but it
should be pointed out clearly somewhere)?

GB: As you noticed, I make it clearer in a specific section.

<...snip...>        
    
6.2.3. Priority 
    
   It is the responsibility of the network administrator to decide which

   behavior to adopt between global or individual configuration, if the 
   AVP is sent twice (one for a multicast group and one for an 
   individual user). By default, only the individual configuration 
   SHOULD be taken into consideration in that case.  

WMT Is it a requirement for the LAC to be able to handle each of these
modes?
Or, can it simply ignore the message and do whatever it wants? 

GB: I don't think the priority message is a requirement for the LAC, it
just has to be treated as a preference expressed by the LNS. I will make
this more clear in the next release. This means that priority messages
should be ignored by the LAC if not supported (that is implicitly the
current behavior since M-bit must be 0).

WMT Also, if you do end up with a REQ/REP for the new/withdraw
operations, I
think the dynamic priority update message could still be its own single
message.
    
GB: Yes, as for withdrawals.

7. Multicast session teardown 
      
     A L2TP multicast session should be torn down when there are no 
     longer users interested in. More generally, we can consider that a 
     multicast session becomes useless as soon as the related OSL has 
     less than a predefined number of entries, this number being defined

     by a threshold. 
     Multicast session flapping may occur when the number of OSL entries

     is oscillating around the threshold, if the same value is used to 
     trigger the creation or the deletion of an L2TP multicast session.

     To avoid this behavior, two methods can be used: 
      
        - The threshold value used to determine if the L2TP multicast 
     session has to be torn down is lower than the 
     MULTICAST_SESSION_THRESHOLD value; 
        - The MULTICAST_SESSION_THRESHOLD value is used to determine if 
     the L2TP multicast session has to be torn down. A multicast session

     SHOULD be killed after a period of MULTICAST_SESSION_HOLDTIME 
     seconds if the corresponding OSL maintains less than 
     MULTICAST_SESSION_THRESHOLD entries. The MULTICAST_SESSION_HOLDTIME

     value is 10 seconds by default, and SHOULD be configurable either 
     by the LAC or LNS administrator. 
       
     The multicast session can be torn down for multiple reasons, 
     including specific criteria not described here (can be vendor-
     specific).   
     A multicast session teardown can be initiated either by the LAC or 
     the LNS. 

WMT Hmm... If a wide variety of methods are allowed here, and the
teardown may
be initiated by the LAC or the LNS, then could you not end up in some
serious
thrashing? Perhaps you need some more MUSTs here, or have one side
always be the
decision-maker.

GB: The idea is to keep the decision process in the LNS only to bring up
or tear down the multicast session on  threshold crossing. The LAC could
also stop the session "de facto" by killing the multicast session, in
case of failure or configuration change for instance, but never when
crossing a threshold in any case. I will write this more explicitly.

7.1. Operations 
    
   The effective termination of a multicast session is initiated with a 
   CDN control message, sent either by the LAC or by the LNS. The CDN 
   message carries a Result Code AVP with an optional Error Code.  
       
   The following AVPs MUST be present in a multicast CDN message:  
        
      Message Type  
      Result Code  
      Assigned Session ID  
 
Bourdon                    Expires February 2003              [Page 13] 

Internet Draft      draft-ietf-l2tpext-mcast-02.txt         August 2002 

   The Cause Code AVP SHOULD NOT be present in a multicast CDN message 
   (because Q.931 Cause Codes make no sense in a multicast session 
   context). However, the Cause Code AVP MUST be ignored if received in 
   this context.

WMT An "MCDN" could be your own message along with the MCRQ/MCRP
messages.
       
GB: Don't you think a CDN could suit to all Incoming/Outgoing/Multicast
calls, since a CDN doesn't carry any information on the session type ?

<...snip...>
 
10. Security Considerations 
    
   The extension described in this document does not introduce any 
   additional security issues as far as the activation of the L2TP 
   protocol is concerned. 
   However, activation of the L2TP multicast capability on a LAC could 
   make the equipment more sensitive to Denial of Service attacks if the

   tunnel or the related LNS is hacked. By injecting appropriate control

   packets in the tunnel towards a LAC, final users could be flooded by 
   unwanted multicast traffic. The LAC might also be sensitive to the 
   burden generated by the additional replication work. 

WMT I suspect that the ability to setup a single session and cause
packet
replication and injection into L2TP multiple sessions could be an
interesting
platform for staging all sorts of attacks... This section might need a
little
more filling out to get by the IESG, though some of the issues are
probably
similar as those for Multicast in general (allowing you to reference or
borrow
text from there if possible).
            
GB: That a combined L2TP/Multicast security issue. The Control
Connection must first be hacked (and that is an RFC2661 security
problem), and thereafter individual terminals can be attacked using
multicast methods. I will add some references about multicast security.

_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 06 Aug 2002 14:37:43 +0200

> BOURDON Gilles FTRD/DAC/ISS wrote:
>           

Perhaps, particularly given that it is already shared among the ICxx and 
OCxx models. My only concern was in placing restrictions on what AVPs 
can and cannot be in the message (e.g. the Cause Code restriction). Some 
implementations sanity check a message when received against of list of 
AVPs that MUST/MAY be present for that message, so you might be making 
that ability more complex if you make this session-id context-dependent.

- Mark

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 06 Aug 2002 14:37:43 +0200

- Mark