[PWE3] comments on draft-ietf-pwe3-hdlc-ppp-encap-mpls-05.txt

[Stewart Bryant <[e-mail]>]

-------- Original Message --------
Subject: comments on draft-ietf-pwe3-hdlc-ppp-encap-mpls-05.txt
Date: Fri, 08 Jul 2005 17:37:34 +0100
From: Stewart Bryant <[e-mail]>
To: 'Luca Martini' <[e-mail]>
CC: [e-mail]

Please don't forget the comments at

http://www.ietf.org/mail-archive/web/pwe3/current/msg07088.html


------

Not sure that the following text add any value

    Although different layer 2 protocols require different information to
    be carried in this encapsulation, an attempt has been made to make
    the encapsulation as common as possible for all layer 2 protocols.
    Other layer 2 protocols are described in separate documents. [ATM]
    [ETHER] [FRAME]

------

I note that you do not describe the layering in this draft, or
call it out explicitly. I think that you should import the layering
text from one of the other drafts to show PSN label/PW label/CW.

------

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 0|0 0 0 0|Res|   Length  |     Sequence Number           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 2: MPLS PWE3 Control Word


I think that you should call out the field descriptions as per other
encaps, and include the definition. It's just cut and paste.

------

    In the above diagram the first 4 bits are set to 0 in indicate PW
    data [ARCH].

Should be CW

-------

    The next 4 bits provide space for carrying protocol specific flags.
    These are not used for HDLC/PPP and they They MUST be set to 0 when
    transmitting, and MUST be ignored upon receipt.

Why is frag not supported?

-------

3.1.2. Processing the sequence number

3.2. MTU Requirements

    The network MUST be configured with an MTU that is sufficient to
    transport the largest encapsulation frames. When MPLS is used as the
    tunneling protocol, for example, this is likely to be 12 or more
    bytes greater than the largest frame size. The methodology described
    in [FRAG] MAY be used to fragment encapsulated frames that exeeed the
    PSN MTU. However if [FRAG] is not used then if the ingress router
    determines that an encapsulated layer 2 PDU exceeds the MTU of the
    PSN tunnel through which it must be sent, the PDU MUST be dropped.

So you do support frag, but you don't allocate the bits in Fig 2

-------

    If a packet is received, on the attachment circuit, that exceeds the
    interface MTU paramater value [CONTROL] , it MUST be dropped.

subTLV?

--------

4.2. Frame Relay Port Mode

    Figure 3 illustrates the concept of frame relay port mode or many-
    to-one mapping which is an OPTIONAL capability.

I think that the diagram needs a bit of a clean-up to make it
obvious there is a FIG 3a and a Fig 3b, it looks somewhat merged.

--------

5. Using an MPLS Label as the Demultiplexer Field

    To use an MPLS label as the demultiplexer field, a 32-bit label stack
    entry [MPLSENCAP] is simply prepended to the emulated PW
    encapsulation, and hence will appear as the bottom label of an MPLS
    label stack. This label may be called the "PW label". The particular
    emulated PW identified by a particular label value must be agreed by
    the ingress and egress LSRs, either by signaling (e.g, via the
    methods of [CONTROL]) or by configuration. Other fields of the label
    stack entry are set as follows.

I think that this text is missing from the ATM draft

----------

7. Security Considerations

    The ethernet pseudowire type is subject to all of the general

The HDLC/PPP PW

---------

Regards

Stewart







_______________________________________________
pwe3 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pwe3