Subject: Comments on draft-so-pwe3-ethernet.txt

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 26 Jun 2002 18:11:23 +0200

Hello Tricci, et. al., 

I have some comments, identified with ****.

Thanks,

- Mark

PWE3 Working Group                                           Tricci So
Internet Draft                                        Caspian Networks
Expiration Date: March 2002                                XiPeng Xiao
                                                          Loa Anderson
David Zelig                                                  Utfors AB
Corrigent Systems                                         Chris Flores
Giles Heron                                                Nick Tingle
PacketExchange Ltd.                                    Sunil Khandeker
                                                      TiMetra Networks

            Ethernet Pseudo Wire Emulation Edge-to-Edge (PWE3) 
                                      
                        draft-so-pwe3-ethernet.txt 

[ snip ]

    +-------------+                                +-------------+ 
    |  Emulated   |                                |  Emulated   | 
    |  Ethernet   |                                |  Ethernet   | 
    | (including  |         Emulated Service       | (including  | 
    |  VLAN)      |<==============================>|  VLAN)      | 
    |  Services   |                                |  Services   | 
    +-------------+           Pseudo Wire          +-------------+ 
    |Encapsulation|<==============================>|Encapsulation| 
    +-------------+                                +-------------+ 
    |    PSN      |            PSN Tunnel          |    PSN      | 
    |IP/MPLS/L2TP |<==============================>|IP/MPLS/L2TP | 
    +-------------+                                +-------------+ 
    |  Physical   |                                |  Physical   | 
    +-----+-------+                                +-----+-------+ 
          |                                              | 
          |                IP/MPLS/L2TP Network          | 
          |             ____     ___       ____          | 
          |           _/    \___/   \    _/    \__       | 
          |          /               \__/         \_     | 
          |         /                               \    | 
          +========/                                 |===+ 
                   \                                 / 
                    \                               / 
                     \   ___      ___     __      _/ 
                      \_/   \____/   \___/  \____/ 
   
          Figure 2: Ethernet PWE3 Protocol Stack Reference Model 

**** L2TP is not a "Network" or PSN. It is a tunneling protocol that sits on top
of IP. IP and MPLS are PSNs. 

[ snip ]
   
   As there are alternative mechanisms for providing virtual Ethernet 
   segments using multiple point-to-point Ethernet PWs and a suitable 
   Adaptation function (e.g. see [Vkompella]), the multipoint Ethernet 
   PW is not addressed further in this document.  

**** You state here that multipoint Ethernet PW is not addressed further in this
document, though I see a reference two paragraphs below ;-)
    
3.3. Packet Processing  
    
3.3.1. Encapsulation  
    
   The entire Ethernet frame without the preamble or FCS is 
   transported as a single packet. PSN-specific tunnel identifiers are 
   prepended to this. 
      
   In the multi-point case where the egress PE needs to know which 
   ingress PE forwarded the packet this information must be derived 
   from the PW-specific tunnel identifiers. In the MPLS case this 
   implies that a separate VC label be assigned to each ingress PE.  
   With such consideration, the following implications shall be 
   examined, i.e. 
    
[ snip ]

3.4.1. Pseudo-wire Establishment 
    
   An Ethernet PW can be established over a PSN either via 
   configuration or via some sort of signaling mechanism, e.g. LDP, 
   MP-BGP etc., whichever is applicable to the underlying PSN.  

**** The PSN does not dictate the signaling for the PW, as this statement seems
to imply. For example, L2TP uses its own control protocol, but this doesn't have
anything to do with IP per se.
    
   If available, an auto-discovery mechanism, which may be associated 
   with some signaling mechanism (e.g. LDP, MP-BGP) or some server 
   based solution (e.g. DNS), can be used to identify the Ethernet PW 
   types (e.g. native Ethernet or VLAN type) among the PE peers across 
   the PSN. It is expected that when a PW is established between the 
   PEs, the Ethernet PW types are compatible at each end of the PW, 
   i.e. tagged to tagged or raw to raw. 
    
   Multiple PWs can be set up within the same PSN tunnel and 
   therefore, the PE/PWES is required to have an ability to support a 
   mechanism to multiplex and de-multiplex the various PW instances.  
   The VC label for an Ethernet PW instance shall be unique at least 
   within the same PSN tunnel so that misrouting of the Ethernet 
   packet can be avoided.  
    
   In the case when 802.1p [802.1p] support is required, a COS mapping 
   mechanism (e.g. MPLS EXP field and IP Diffserv DSCP mapping) shall 
   be configured at each PE. The policy of the service mapping between 
   the PW and the PSN tunnel is outside the scope of this 
   specification.  
    
3.4.2. Link Maintenance  
    
   It is desirable to detect Ethernet PW failure at the PE which is 
   caused either by the PW itself or by the PSN in a timely manner.  
   Unlike some other transmission technologies, e.g. SONET/SDH, 
   Ethernet does not have a specific standard performance requirement 
   for fault detection and recovery. The requirement on an Ethernet PW 
   is that its reliability performance is identical to standard 
   Ethernet, the performance indicators for this is for further study. 
    
   The types of failures detection that have an impact on the Ethernet 
   PW are:  
    
     1. 
        PSN tunnel failures 
     2. 
        VC tunnel failures  
     3. 
        PWES failures 

**** Nit: There seems to be a general formatting problem with bullets and
numbers in this document.
         
   The detection and diagnostics of these failures requires a co-
   ordination between the PSN tunnel, the VC-tunnel and the PWES. 

[ snip ]    
    
3.7.2. PW establishment 
    
   If a signaling mechanism is used to establish the PW then the 
   protocol chosen MUST be suitable for inter-domain operation. 
   Furthermore, the identifier used for the PW SHOULD be globally 
   unique. 

**** Why does the PW ID need to be globally unique? For purposes of simple PWE3
operation, it only needs to be unique per tunnel. Certain PPVPN applications may
require more broad scope for ID uniqueness, but I would expect this to be above
the PWE3 level of concern.
    
[ snip ] 
 
5. Ethernet PW Over IP/GRE  

**** Question: Is this section here because someone is interested in seriously
implementing and deploying it, or is it to meet the "IP requirement" of the
charter? If it is for the latter, I suggest stating that we already have two
methods which operate over IP (MPLS in GRE and L2TP), and we don't need a third
(thus this section could simply be deleted). 
    
   Ethernet PW packets are encapsulated over an IP network using the 
   Generic Routing Encapsulation protocol as specified in [GRE-encap, 
   GRE-IPv4][GRE-revised][GRE-KeyExt]. 

**** "Ethernet PW packet _may be_ encapsulated over an IP..." Clearly if you are
identifying alternatives, then one cannot imply that PW over GRE is the only
method.
    
   Note: an alternative method of encapsulating Ethernet PW packets 
   over IP is to use the MPLS encapsulation (see sectioin 4) and an 
   MPLS-in-IP protocol  as described in [Rekhter][Worster]. 

**** I would say that L2TP over IP is an "alternative" for IP operation as well,
given that that it is the default mode of operation defined in the base L2TP
draft ;-)

[ snip ]
    
                      Figure 7: Ethernet over L2TPv3 
    
   An L2TPv3 data packet can be sent as over UDP or directly over IP. 
   The selection of UDP vs. IP is beyond scope of this document. 

**** I would probably go so far as to say that support of IP is a MUST, and that
UDP is a MAY. It is a bit out of scope here (as you say) as the pros/cons of
this in general are discussed at length in [L2TPv3] and one should be able to
make their own decisions with regard to this. But, if you want to lean the
preference one way or another, I would say that for core network applications
L2TP/IP has more support. L2TP/UDP will become important if/when NATs get stuck
between the PEs (certainly not a consideration for the "classic" ppvpn case, but
perhaps something that might come into play eventually).
    
   L2TPv3 data channels do not provide reliable or in-order delivery. 
   There is no sequence number field in an L2TPv3 header. 

**** There is a "default L2-specific sublayer" much like the "martini control
word" that should be here if sequencing is desired. Its presence is signaled in
[L2TPv3]. In fact, I would suggest using this and simply referring to the
[L2TPv3]
document. You could eliminate a lot of duplicate text here that way. 

[ snip ]
 
   After the encapsulation, the whole packet is as follows: 
    
    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Session ID                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                    Cookie (optional, up to 64 bits)           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                    Control word (optional)                    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                   Tunneled Ethernet Frame                     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

**** So, to expand on the previous comment, the "Control Word" becomes the
"Default L2-Specific Sublayer"

[ snip ]    
 
   Ethernet frame size (without the preamble or FCS) plus 20 bytes. If 
   the PSN cannot support such a MTU, another option is to set the MTU 
   size of the two Ethernet ports between the PEs and the CEs to 
   (network_MTU - 20). This may imply that Ethernet jumbo frame cannot 
   be used. 

**** This certainly depends on the size of the Ethernet Jumbo frame available,
which can be as much as 9216 bytes. If this is a problem for L2TP, it almost
certainly is a problem for GRE/IP as well. 
    
   If the PSN cannot be configured with a sufficiently large MTU to 
   avoid fragmentation, Ethernet PWE over L2TPv3 can rely on IP 
   fragmentation. 
    
[ snip ]
    
   Legal "Pseudo Wire Types" that may be included in the Pseudo Wire 
   Capabilities List are defined below (pending IANA approval): 
    
      0x0004 - Sessions without control word for connecting Ethernet 
               VLANs are allowed  
      0x0005 - Sessions without control word for connecting Ethernet 
               ports are allowed 
So, et al               Expires September 2002               [Page 24] 
 
Internet Draft      draft-so-pwe3-ethernet-00.txt       September 2002 
 
      0x8004 - Sessions with control word for connecting Ethernet VLANs 
               are allowed  
      0x8005 - Sessions with control word for connecting Ethernet ports 
               are allowed  

**** There is an L2TPv3-specific AVP for including or not including the
L2-Specific-Sublayer (control word). No need for negotiating this as part of the
PW-Type.

[ snip ]    
    
   - PW ID 
    
   Each PW is associated with a PW ID. The two PEs of a PW have the 
   same PW ID for it. Together with the Pseudo-Wire Type, a PW ID 
   uniquely identifies a PW session at every PE. A new L2TPv3 AVP will 
   be defined for signaling the PW ID. 

**** This should be the "End Identifier" AVP in L2TPv3. 
    
   - Group ID 
    
   A Group ID is used for referring to a group of PWs so that they can 
   be signaled down collectively. The L2TPv3 "Private Group ID" AVP 
   can be used for signaling the Group ID. 

**** This is not the intended purpose of the L2TP Private Group ID. L2TP
Sessions associated with a given Control Connection (of which there may be more
than one between two same peers) are always signalled down collectively when the
Control Connection is terminated.
    
   - PWES parameters 
    
   Three parameters are defined for each Ethernet PWES. They can be 
   used for detecting mismatch between the two PWES's of a PW. 
    
        + Description string 
         
        This is an informational description string for a PWES. For 
        example, if the local PWES is VLAN 100 of interface GE 1/1 on 
        PE1, then the description string of the PW can be "PE1-GE1/1-
        VLAN100") 
         
        A new L2TPv3 AVP will be defined for signaling this 
        description string. 

**** Yes, this is a good idea. There happens to be a new, general, l2tp
connection information description string being standardized in l2tpext (for
L2TPv2, and usable for L2TPv3 as well). The draft has been submitted, and should
be available soon. draft-mistretta-l2tp-infomsg-00.txt
        
        + MTU  
         
        This parameter specifies the MTU size of the local PWES. It 
        can be used for detecting MTU mismatch of the two PWES's of a 
        PW. MTU mismatch SHOULD be logged if identified. 
         
        A new L2TPv3 AVP will be defined for signaling the MTU of a 
        PWES.  

**** A similar AVP has been defined for L2TP as part of
draft-malis-pwe3-fragmentation-00.txt
         
        + Speed 
         
        This parameter specifies the Send and Receive speed of the 
        PWES. That is, speed of an Ethernet PW is assumed to be 
        symmetric. 

**** I'm not sure why it needs to be considered symmetric. Certainly L2TP has
the AVPs for transmit and receive connect speeds, and it is possible that such
conditions exist. 

**** As a side note, reported connect speed is sometimes used in routing metric
calculations.

        The speed of a PWES should not be higher than the 
        speed of the physical port. The speed specification is mainly 
        for informational purpose, e.g., for detecting speed mismatch 
        of the two PWES's. An example of speed mismatch is: one PWES, 
        a VLAN, is specified to have speed 20Mbps (possibly via rate-
        limiting) and the other PWES, another VLAN, is specified to 
        have speed 40Mbps. Speed mismatch SHOULD be logged if 
        identified. 

So, et al               Expires September 2002               [Page 26] 


 
Internet Draft      draft-so-pwe3-ethernet-00.txt       September 2002 
 
        The L2TPv3 "Connect Speed" AVP can be used for signaling the 
        speed of a PWES. 
    
6.2.2. PW Status Monitoring 
    
   The working status of a PW is reflected by the state of the L2TPv3 
   session. If the corresponding L2TPv3 session is down, both PWES's 
   associated with it MUST be shut down. 
    
   If a control connection is used, and the control channel and the 
   data channels operate in-band, the keep-alive mechanism of L2TPv3 
   can serve as a link status monitoring mechanism for the PWs (i.e. 
   sessions) associated with that control connection. If the control 
   channel and the data channels operate out-of-band, an L2TPv3 data 
   session may be dedicated for sending keep-alive information 
   [Editor's note: details will be provided in the next version of the 
   draft]. 

**** In the latest version of L2TPv3, the data and control channel are always
inband.
    
   If one of the PWES is down, Ethernet PWE MUST treat it as an L2TPv3 
   "local close request" and tear down the PW associated with that 
   PWES. When the remote PE cleans the state for the PW, it MUST shut 
   down the PWES associated with it. 
    
6.2.3. Fault Detection & Recovery 
    
   An Ethernet PW can incur loss, corruption, and out-of-order delivery
   of data packets. Packet loss, corruption, and out-of-order delivery 
   can be considered as "generalized packet error" of an Ethernet PW. 
   If the "generalized packet error" rate is higher than a configurable
   threshold, the PW MUST be signaled down with this reason explained 
   in the "Result Code" AVP. The two PWES's MUST also be shut down. 

**** The Wan Error Notify AVP might be mentioned here as well. If a new Result
Code is to be defined for this case, it should be done explicitly.
    
[ snip ]