Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks
draft-ietf-pwe3-atm-encap-11

[Ballot discuss]
Section 15., paragraph 1:

>    As explained in [RFC3985], the PSN carrying the PW may be subject to
>    congestion, with congestion characteristics depending on PSN type,
>    network architecture, configuration, and loading. During congestion
>    the PSN may exhibit packet loss that will impact the service carried
>    by the ATM PW. In addition, since ATM PWs carry an variety of
>    services across the PSN, including but not restricted to TCP/IP, they
>    may or may not behave in a TCP-friendly manner prescribed by
>    [RFC2914]. In the presence of services that reduce transmission rate,
>    ATM PWs may thus consume more than their fair share and in that case
>    SHOULD be halted.

        DISCUSS: RFC3985 also says: "Where congestion is avoided by
        shutting down a PW, a suitable mechanism must be provided to prevent
        it from immediately returning to service and causing a series of
        congestion pulses." I don't see such a mechanism in this draft.

[Ballot comment]
Per discussions with the authors of this draft and MPLS ping I would
strongly prefer that the discussion of TTL explicitly mention that TTL
0 cannot be used.

PROTO

Stewart Bryant is the WG Chair responsible for this WG draft.

  1.a) Have the chairs personally reviewed this version of the Internet
      Draft (ID), and in particular, do they believe this ID is ready
      to forward to the IESG for publication?

Yes

  1.b) Has the document had adequate review from both key WG members
      and key non-WG members?  Do you have any concerns about the
      depth or breadth of the reviews that have been performed?

This document has been fully reviewed by the PWE3 WG.

  1.c) Do you have concerns that the document needs more review from a
      particular (broader) perspective (e.g., security, operational
      complexity, someone familiar with AAA, etc.)?

We have no concerns.

  1.d) Do you have any specific concerns/issues with this document that
      you believe the ADs and/or IESG should be aware of?  For
      example, perhaps you are uncomfortable with certain parts of the
      document, or have concerns whether there really is a need for
      it.  In any event, if your issues have been discussed in the WG
      and the WG has indicated it that it still wishes to advance the
      document, detail those concerns in the write-up.

We have no concerns.

  1.e) How solid is the WG consensus behind this document? Does it
      represent the strong concurrence of a few individuals, with
      others being silent, or does the WG as a whole understand and
      agree with it?

There is firm consenus for the design described in this document.

  1.f) Has anyone threatened an appeal or otherwise indicated extreme
      discontent?  If so, please summarize the areas of conflict in
      separate email to the Responsible Area Director.

No

  1.g) Have the chairs verified that the document adheres to all of the
      ID nits? (see http://www.ietf.org/ID-Checklist.html).

http://tools.ietf.org/wg/pwe3/draft-ietf-pwe3-atm-encap/draft-ietf-pwe3-atm-encap-11.nits.txt
reports no nits, but some experimental warnings.
We deal with those below.

  1.h) Is the document split into normative and informative references?
      Are there normative references to IDs, where the IDs are not
      also ready for advancement or are otherwise in an unclear state?
      (note here that the RFC editor will not publish an RFC with
      normative references to IDs, it will delay publication until all
      such IDs are also ready for publication as RFCs.)

Yes, it is correctly split into normative and non-normative references.
All normative references are RFCs.


  1.i) For Standards Track and BCP documents, the IESG approval
      announcement includes a write-up section with the following
      sections:

      *    Technical Summary

An ATM Pseudowire (PW) is used to carry ATM cells over an MPLS
network. This enables service providers to offer "emulated" ATM
services over existing MPLS networks. This document specifies a
number of methods for the encapsulation of ATM cells
within a pseudowire, and describes the applicability of each
method.

      *    Working Group Summary

The PWE3 WG have thoroughly reviewed this design. The design is
technically identical to Y.1411 and Y.1412, and the design
represents the combined efforts of ITU SG13 and IETF PWE3WG.

      *    Protocol Quality

There are a number of existing implementations of this protocol


The following edits should be made by the RFC editor

1) In Section 5.4. (MPLS Shim TTL Values): the sentence should
  end with a full-stop - there is no text that follows the
  word "dependent".

2) In informative references add

[RFC2914] "Congestion Control Principles", S. Floyd, September 2000

3) [RFC4029] is mentioned on line 238 should be [RFC4026]

4) [RFC3270] is defined on line 1563, but not referenced, the reference
should be deleted.

[Ballot discuss]
There is an informatibe reference to [RFC3985] in the Security
  Considerations section.  There is some very good, highly relevant
  material in the Security Considerations section of RFC 3985.  Please
  make [RFC3985] a normative reference.

[Ballot comment]
Includes the RFC2119 boilerplate but doesn't cite RFC2119.

Section 2., paragraph 1:

>    Packet Switched Networks (PSNs) have the potential to reduce the
>    complexity of a service providers infrastructure by allowing
>    virtually any existing digital service to be supported over a single
>    networking infrastructure. The benefit of this model to a service
>    provider is threefold:

        NIT: s/providers/provider's/


Section 4., paragraph 1:

>    One-to-one mode: The One-to-one mode specifies an encapsulation
>    method which maps one ATM Virtual Channel Connection ( VCC ) (or one
>    ATM Virtual Path Connection (VPC) ) to one pseudowire.

        NIT: Spaces before/after parentheses are unusual.
        (Elsewhere in the draft, too.)


Section 4., paragraph 2:

>    N-to-one mode (N >= 1): The N-to-one mode specifies an encapsulation
>    method which maps one or more ATM VCCs (or one or more ATM VPCs) to
>    one pseudowire.

        N > 1? Otherwise, wouldn't it be the one-to-one case? (Elsewhere
        in the document, too.)


Section 5.1.1., paragraph 10:

>    The sequence number space is a 16 bit, unsigned circular space. The
>    sequence number value 0 is used to indicate that the sequence number
>    check alghorithm is not used.

        NIT: s/alghorithm/algorithm/


Section 5.2., paragraph 1:

>    The network MUST be configured with an MTU that is sufficient to
>    transport the largest encapsulation frames. If MPLS is used as the
>    tunneling protocol, for example, this is likely to be 12 or more
>    bytes greater than the largest frame size. Other tunneling protocols
>    may have longer headers and require larger MTUs. If the ingress
>    router determines that an encapsulated layer 2 PDU exceeds the MTU of
>    the tunnel through which it must be sent, the PDU MUST be dropped. If
>    an egress router receives an encapsulated layer 2 PDU whose payload
>    length (i.e., the length of the PDU itself without any of the
>    encapsulation headers), exceeds the MTU of the destination layer 2
>    interface, the PDU MUST be dropped.

        Problematic to have a MUST on a configuration requirement in the
        first sentence.


Section 5.4., paragraph 1:

>    The setting of the TTL value in the PW label is application
>    dependent,

        NIT: There seems to be some text missing after the comma?


Section 6.3., paragraph 4:

>    The limitations of the AAL5 SDU encapsulation are:
>        -i. If an ATM OAM cell is received at the ingress PE, it is sent
>            before the cells of the surrounding AAL5 frame. Therefore,
>            OAM cell reordering may occur, which may cause certain ATM
>            OAM performance monitoring and ATM  security applications to
>            operate incorrectly.
>        -ii. If the ALL5 PDU is scrambled using ATM security standards, a
>            PE will not be able to exctract the ALL5 SDU and therefore
>            the whole PDU will be dropped.

        NIT: s/exctract/extract/

[Ballot comment]
Section 2., paragraph 1:

>    Packet Switched Networks (PSNs) have the potential to reduce the
>    complexity of a service providers infrastructure by allowing
>    virtually any existing digital service to be supported over a single
>    networking infrastructure. The benefit of this model to a service
>    provider is threefold:

        NIT: s/providers/provider's/


Section 4., paragraph 1:

>    One-to-one mode: The One-to-one mode specifies an encapsulation
>    method which maps one ATM Virtual Channel Connection ( VCC ) (or one
>    ATM Virtual Path Connection (VPC) ) to one pseudowire.

        NIT: Spaces before/after parentheses are unusual.
        (Elsewhere in the draft, too.)


Section 4., paragraph 2:

>    N-to-one mode (N >= 1): The N-to-one mode specifies an encapsulation
>    method which maps one or more ATM VCCs (or one or more ATM VPCs) to
>    one pseudowire.

        N > 1? Otherwise, wouldn't it be the one-to-one case? (Elsewhere
        in the document, too.)


Section 5.1.1., paragraph 10:

>    The sequence number space is a 16 bit, unsigned circular space. The
>    sequence number value 0 is used to indicate that the sequence number
>    check alghorithm is not used.

        NIT: s/alghorithm/algorithm/


Section 5.2., paragraph 1:

>    The network MUST be configured with an MTU that is sufficient to
>    transport the largest encapsulation frames. If MPLS is used as the
>    tunneling protocol, for example, this is likely to be 12 or more
>    bytes greater than the largest frame size. Other tunneling protocols
>    may have longer headers and require larger MTUs. If the ingress
>    router determines that an encapsulated layer 2 PDU exceeds the MTU of
>    the tunnel through which it must be sent, the PDU MUST be dropped. If
>    an egress router receives an encapsulated layer 2 PDU whose payload
>    length (i.e., the length of the PDU itself without any of the
>    encapsulation headers), exceeds the MTU of the destination layer 2
>    interface, the PDU MUST be dropped.

        Problematic to have a MUST on a configuration requirement in the
        first sentence.


Section 5.4., paragraph 1:

>    The setting of the TTL value in the PW label is application
>    dependent,

        NIT: There seems to be some text missing after the comma?


Section 6.3., paragraph 4:

>    The limitations of the AAL5 SDU encapsulation are:
>        -i. If an ATM OAM cell is received at the ingress PE, it is sent
>            before the cells of the surrounding AAL5 frame. Therefore,
>            OAM cell reordering may occur, which may cause certain ATM
>            OAM performance monitoring and ATM  security applications to
>            operate incorrectly.
>        -ii. If the ALL5 PDU is scrambled using ATM security standards, a
>            PE will not be able to exctract the ALL5 SDU and therefore
>            the whole PDU will be dropped.

        NIT: s/exctract/extract/

[Ballot discuss]
Section 15., paragraph 1:

>    As explained in [RFC3985], the PSN carrying the PW may be subject to
>    congestion, with congestion characteristics depending on PSN type,
>    network architecture, configuration, and loading. During congestion
>    the PSN may exhibit packet loss that will impact the service carried
>    by the ATM PW. In addition, since ATM PWs carry an variety of
>    services across the PSN, including but not restricted to TCP/IP, they
>    may or may not behave in a TCP-friendly manner prescribed by
>    [RFC2914]. In the presence of services that reduce transmission rate,
>    ATM PWs may thus consume more than their fair share and in that case
>    SHOULD be halted.

        DISCUSS: RFC3985 also says: "Where congestion is avoided by
        shutting down a PW, a suitable mechanism must be provided to prevent
        it from immediately returning to service and causing a series of
        congestion pulses." I don't see such a mechanism in this draft.

[Ballot comment]
I'm abstaining because the applicability statement in section 3
makes me very uncomfortable. It's clear that this service
doesn't emulate ATM with respect to latency, jitter, reordering,
QOS in general, and layer 2 security. I might be talked into No
Objection if the applicability statement was much stronger
as a health warning.

Minor comments from Gen-ART review by Gonzalo Camarillo:

RFC 4029 and RFC 2914 are missing in the References Section. RFC 4026
and RFC 3270 and in the References Section but are not used in the text.

All acronyms should be expanded on the first use.

RFCs are referenced in the text in two ways:
1) ... as defined in [RFCxxxx]
2) ... as defined in RFCxxxx [RFCxxxx]
it would be good to choose one and stick to it.

Carriage return problem in the second paragraph of Section 5.1.3.

[Note]: 'From SB: The original hold was for applicability, but I think that we also need some congestion text particularly for the cell mode case.' added by Mark Townsley

-------- Original Message --------
Subject: Re: Proto questionairre for draft-ietf-pwe3-atm-encap-10.txt
Date: Thu, 08 Dec 2005 17:01:43 +0000
From: Stewart Bryant
To: Mark Townsley
CC: Danny McPherson
References: <43970B96.5050004@cisco.com>


Only just found this - Luca is needs to re-issue with applicability
statement
similar to Ethernet

- Stewart

-------- Original Message --------
Subject: Re: draft-ietf-pwe3-atm-encap-09.txt - a couple of nits
Date: Wed, 24 Aug 2005 15:28:52 -0600
From: Luca Martini
To: Mark Townsley
CC: Stewart Bryant , Danny McPherson
References: <42CD7C98.4030600@cisco.com> <430C41B5.7040703@cisco.com>


The WG LC expired a long time ago ....
Unless we re-issue one , the current draft is up to date.
The comment below, came in after wg LC , i'm happy to incorporate them
as part of a ietf LC revision.

Luca


Mark Townsley wrote:
>
>
> I just realized I may have pushed the IETF LC button before the WG LC
> expired and you said go.
>
> Sorry about that. Luca, did you take care of these comments? And,
> Stewart, may I have a WG LC Summary?
>
> Thanks,
>
> - Mark
>
> Stewart Bryant wrote:
>
>> Luca
>>
>> I just read this whole draft through again and I have a
>> few nits. I think that you probably ought to take a look
>> at the following text before Mark takes this to IETF LC.
>>
>> - Stewart
>>
>> -------
>>
>> In several places (for example 5) you talk about PW Header,
>> when I think you mean PW label.
>>
>> I think that this is a legacy from the days when the draft
>> had L2TPv3 included, but given that L2TPv3 uses a different
>> control word the description is not generic in the widest
>> sense.
>>
>> You then pull MPLS shim out of a hat.
>>
>>
>>
>> 5. General encapsulation method
>>
>>    This section describes the general encapsulation format for ATM over
>>    PSN pseudo wires.
>>
>>    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
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |              PSN Transport Header (As Required)              |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                    Pseudo Wire Header                        |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                    ATM Control Word                          |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                    ATM Service Payload                      |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>      Figure 2: General format for ATM encapsulation over PSNs
>>
>>    The PSN Transport Header depends on the particular tunneling
>>    technology in use. This header is used to transport the encapsulated
>>    ATM information through the packet switched core.
>>
>>    The Pseudo Wire Header identifies a particular ATM service on a
>>    tunnel. In case of MPLS the Pseudo Wire Header is the MPLS label at
>>    the bottom of the MPLS label stack.
>>
>>    The ATM Control Word is inserted before the ATM service payload. It
>>    may contain a length and sequence number in addition to certain
>>    control bits needed to carry the service.
>>
>>
>> --------
>>
>>
>> Then in section 9 you talk about L2TP and IP, which again is out
>> of place in this draft - I think a legacy from an earlier version.
>>
>> 9.1. ATM One-to-one Service Encapsulation
>>
>>    This section describes the general encapsulation format for ATM over
>>    PSN pseudo wires, such as IP, L2TP, or MPLS. The specifics pertaining
>>    to each packet technology are covered in later sections.  Figure 6
>>    provides a general format for encapsulation of ATM cells into
>>    packets.
>>    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
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |              PSN Transport Header (As Required)              |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                    Pseudo Wire Header                        |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |0 0 0 0| Resvd |    Optional Sequence Number  | ATM Specific  |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                    ATM Service Payload                      |
>>    |                                                              |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>    Figure 6: General format for One-to-one mode encapsulation over PSNs
>>
>>    The PSN Transport Header depends on the packet technology: IP, L2TP
>>    or MPLS.  It identifies a particular ATM service within the PSN
>>    tunnel. This header is used to transport the encapsulated ATM
>>    information through the packet switched core. This header is always
>>    present if the Pseudo Wire is MPLS.
>>
>> ---------
>>
>>
>

[Note]: 'Subject: Re: pwe3 docs...
Date: Wed, 23 Mar 2005 15:44:39 -0700
From: Luca Martini
To: W. Mark Townsley

> draft-ietf-pwe3-atm-encap-07.txt

Some service defining text what was moved from the control protocol draft needs to be integrated in this one.' added by Mark Townsley

[Note]: 'Discussions with one of the authors (Luca Martini) indicate that a few more edits are necessary for this spec. Will move to Revised ID Needed once I get more details on what is needed (email sent asking for details).' added by Mark Townsley

[Note]: '2004-12-17: on hold until the following bundle of documents is through
the IESG (pushing the bundle through will clarify what changes are
needed in this document): draft-ietf-pwe3-ethernet-encap-07.txt
draft-ietf-pwe3-cw-01.txt draft-ietf-pwe3-control-protocol-14.txt
draft-ietf-pwe3-iana-allocation-07.txt
' added by Thomas Narten

[Note]: '2004-12-17: on hold until the following bundle of documents is through
(pushing the bundle through will clarify what changes are needed in
this document): draft-ietf-pwe3-ethernet-encap-07.txt
draft-ietf-pwe3-cw-01.txt draft-ietf-pwe3-control-protocol-14.txt
draft-ietf-pwe3-iana-allocation-07.txt
' added by Thomas Narten

From: Thomas Narten
To: Stewart Bryant , Danny McPherson
cc: lmartini@cisco.com
Date: Mon, 30 Aug 2004 16:00:51 -0400
Subject: AD review of draft-ietf-pwe3-atm-encap-06.txt

Here is my AD review. My guess is an updated ID would be in order
before IETF LC.

Thomas

8/27/04: review of -06, WG says it is done.

General: there are an awful lot of optional encapulations. That does
not promote interoperability, since both PE devices need to implement
an encapsulation in order for them to be used. Are they really
necessary? Are they really expected to be used? Can we remove some of
them or should we put them in other documents where it is more clear
they are not core?

I find it interesting that this document says it this is for L2TP or
MPLS. No where do I see anything w.r.t. L2TP where any feature of L2TP
is actually used. I.e., what features of L2TP are actually used by
this document? I would assume the sequencing, but where is this
discussed?

I'm really concerned that all these encapsulations use only 16 bits
for sequence numbers. That's a small space.

No references in abstract please. Abstract could be a bit more
detailed.

Section 2 duplicates Section 1.

move section 3 to the end.

>        This document describes a method to carry ATM services over L2TP
>        and MPLS.  It lists ATM specific requirements and provides
>        encapsulation formats and semantics for connecting ATM edge
>        networks through a core packet network using L2TP or MPLS. The
>        techniques described in this draft will allow ATM service
>        providers to take advantage of new technologies in the core in
>        order to provide ATM multi-services.

Does this document cover more than encapsulations? Above could be more
clear on this.

>    method which maps one ATM VCC (or one ATM VPC) to one Pseudo Wire.

expand vcc/vpc upon first use?

>    Customer Edge - A Customer Edge (CE) is A device where one end of a

s/A/a/

>    The ingress LSR, PE1, MUST set the S bit of the PW label to a value
>    of 1 to denote that the VC label is at the bottom of the stack.

reference to appropriate MPLS doc?

>    The setting of the TTL value in the PW label is application
>    dependent, however in a strict point to point application the TTL
>    SHOULD be appropriately set to 2.

reference MPLS doc?

>        -iv. To allow accurate packet inspection in an MPLS PSN, and/or
>            to operate correctly over MPLS PSNs that have deployed
>            equal-cost multiple-path load-balancing, a PW packet MUST
>            NOT alias an IP packet.

Explain what alias means.

>    The PWE3 architecture document describes a generic control word and a
>    preferred control word. This document makes use of both of these
>    control words depending on the encapsulation mode. Both of these
>    control words addresses all of the above requirements.

update reference to new control word doc?

for section 6.3, same comments as for ethernet encapsulation document.

> 6.4. MTU Requirements

This section is odd in that it doesn't say what must be
IMPLEMENTED. It talks about what must be configured in terms of what
needs to be carried. But what are the implementation considerations?

>            belonging to different service cathegories and qos

spelling

also s/qos/QoS/ throughout? (Pick one and be consistent)

>    Like the N to one cell encapsulation mode, the One-to-one mode

N-to-one (change needs to be made in multiple places)

>    The ATM Control Word is inserted before the ATM service payload. It
>    may contain a length and sequence number in addition to certain
>    control bits needed to carry the service.

Format? Is this the (unlabeled) header in Figure 4?

>        the ATM headers (without HEC) of the incoming cell.

HEC??

>    Wire.  As such it emulates as Virtual Path cross-connect across the

s/as/a/

>    encapsulate multiple ATM cells into a Pseudo Wire PDU.  The ingress
>    and egress PE SHOULD agree to a maximum number of cells in a single
>    Pseudo Wire PDU.  This agreement may be accomplished via a Pseudo

seems like a MUST. Don't bad things happen if they don't agree? (same
comment later)


>    CPCS-PDU, the PE discards the PAD and CPCS-PDU trailer then inserts

s/then/and then/ ??


>    This mode MAY support fragmentation in order to maintain OAM cell
>    sequencing.

what kind of fragmentation is meant here?


>    CPCS-PDU is not processed i.e. an AAL5 frame with an invalid CRC or

s/i.e./, i.e.,/

>    This section is informational.

Better wording to make clear this is not part of the standard?

Split references into normative/informative.

Too many authors. Please clarify which are
contributers/authors/editors.

>    The N-to-one mode (N >= 1) described in this Draft allows a service

s/draft/document/