Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks
RFC 4717

Note: This ballot was opened for revision 11 and is now closed.

(Mark Townsley) Yes

(Jari Arkko) No Objection

Comment (2006-06-08)
No email
send info
> defined in [RFC4446], but the ATM PW specific interface paramenter is

Typo.

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) (was Discuss, No Objection, Discuss) No Objection

Comment (2006-06-06)
No email
send info
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/

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Sam Hartman) (was Discuss, No Objection) No Objection

Comment (2006-06-08)
No email
send info
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.

(Russ Housley) (was Discuss) No Objection

Comment (2006-06-08)
No email
send info
  Section 17: s/then a native ATM service/than a native ATM service/

(Cullen Jennings) No Objection

(David Kessens) No Objection

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

Magnus Westerlund No Objection

Comment (2006-06-02)
No email
send info
Several acronyms are not written out on their first usage:
 SVCs SVPs, SPVCs and SPVPs

(Brian Carpenter) Abstain

Comment (2006-06-06)
No email
send info
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.