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

From: Giles Heron <[email-masked]>
Date: 29 Jun 2002 18:21:50 +0000

On Wed, 2002-06-26 at 16:11, W. Mark Townsley wrote:

> [ 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. 

agreed.  This really comes back to the fact that the PWE3 Design Teams
were chartered to provide solutions over IP, L2TP and MPLS and that the
PWE3 area was also instructed to use the acronym "PSN" instead of the
word "Transport" to describe the entity that PWs ran over.

> [ 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 ;-)

yes, there was some debate about whether multipoint was in, or out of,
scope.  So bits probably got left in ;-)

> 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.

agreed.  Though in general L2TP control will be used with L2TP encaps,
MPLS control with MPLS encaps and so on?

I know the wording there is poor, but again I suspect the way in which
these teams were chartered is as much to blame as anything :(

>    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.

yeah - the master doc was in MS Word, I suspect ;-)
          
>    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.

I think this came out of the multipoint stuff more than anything else so
it should be dropped.

> [ 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). 

the latter.

going forward the plan is to merge the MPLS portion of draft-so with the
Ethernet encap of draft-martini, to drop the IP/GRE stuff, and to handle
L2TPv3 in the appropriate place :)

Might be worth you talking to XiPeng about this directly - I believe he
wrote the L2TP section?

[rest snipped]

Giles

-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================

---

From: "W. Mark Townsley" <[email-masked]>
Date: Sat, 29 Jun 2002 20:45:40 +0200

> word "Transport" to describe the entity that PWs ran over.

I think it is safe to say that consensus has converged on MPLS and L2TP. The IP
PSN is a MUST for L2TP, and a MAY for MPLS. Thus, the spirit of including IP in
the charter is fulfilled. 

> MPLS control with MPLS encaps and so on?

It is at least conceivable to use the L2TP control protocol to exchange MPLS
labels in an LDP-like fashion. But, in general, yes.

> L2TPv3 in the appropriate place :)

Sounds good.

> Might be worth you talking to XiPeng about this directly - I believe he

OK. I will be happy to help with any of the text here. 

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

---

From: "Nick Tingle" <[email-masked]>
Date: Wed, 26 Jun 2002 10:37:56 -0700

Re: use of End Identifier AVP.

We did see this field but did not use it for the PW ID as the semantics did not
seem correct, as described in the L2TPV3 draft. Specifically:

- the End Identifier is assigned "to detect ties in session establishment for
the same circuit". We want it even when there is only a single circuit, to
identify the PW to the far end (so the other PE knows which PW we are setting
up).

- the M bit SHOULD be zero. If the field is malformed or not understood it's
difficult to see how the remote PE will correctly set up the PW.

However it is pretty close to what we want, and some explanatory text in
draft-so could probably clarify how we use this field.

Nick

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of W.
> Mark Townsley
> Sent: Wednesday, June 26, 2002 9:11 AM
> To: [email-masked]
> Subject: [PWE3] Comments on draft-so-pwe3-ethernet.txt
>
>
>
> 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 ]
>
> 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 ]
>
>    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.
>
>    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 ]
>