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

[Luca Martini <[e-mail]>]

Stewart,

Replies in line. ( note that the original e-mail never got to the pwe3 
list , as you had the wrong e-mail address )

Luca

Stewart Bryant wrote:

> 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]
>
yes, this is from the original draft-martini. I removed it.

> ------
>
> 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.
>
I added the text out of the ethernet , and ATM drafts.

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

I already do. what do you mean ?

>
> ------
>
> In the above diagram the first 4 bits are set to 0 in indicate PW
> data [ARCH].
>
> Should be CW
>
so 0 indicates CW, ok.

> -------
>
> 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?
>
because it is a separate draft.
A long time ago , I made a decision , not to change all PWE3 drafts to 
accommodate the latest developments and additions to the protocol.
Including fragmentation here would mean a normative reference to the 
fragmentation document. I would like to avoid that,

> -------
>
> 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
>
to avoid a normative reference ....

> -------
>
> If a packet is received, on the attachment circuit, that exceeds the
> interface MTU paramater value [CONTROL] , it MUST be dropped.
>
> subTLV?
>
yes I messed this one .

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

> --------
>
> 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
>
??? it might be , but that draft is done .

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