Encapsulation Methods for Transport of Ethernet over MPLS Networks
draft-ietf-pwe3-ethernet-encap-11

[Ballot discuss]
I used to have a very long discuss on this document, and the vast majority of my issues have been dealt with very effectively by the authors (Thank you!).  However, I still have one issue remaining. 

I'd like to discuss my one remaining concern (see below) with the rest of the IESG on the telechat to determine if we think that this is a real issue that needs to be addressed.

Also, from a phone call with Mark, I believe that he said that a normative reference to the PWE3 terminology document would be added to this document.  That could obviously be done via an RFC Editor note.

---

My one remaing issue:

(1) This document makes the control word optional without explaining
    why it is safe to ignore the SHOULD in the control word document.

The authors and I had various conversations about this.  At first it was asserted that a valid ethernet address would never have a 4 or 6 as its first nibble, but I think that turned out to be incorrect.  At this point, I think that the main reason for not always requiring a control word in this document is compatibility with existing implementations, but I don't understand how that justifies a MAY for the control word, rather than a SHOULD to be consistent with the control word document.  If there is a reason to be
inconsistent, this document still doesn't point out that inconsistency and explain it.

Specific notes on the document text:

3.7. The Control Word

  When carrying Ethernet over an MPLS backbone, sequentiality may need
  to be preserved.  The OPTIONAL control word defined here addresses
  this requirement.  Implementations MUST support sending no control
  word, and MAY support sending a control word.

>> This is inconsistent with the control word document, which says that
>> a control word SHOULD be used to avoid various problems.  If there
>> is some reason why those problems would not apply to ethernet frames,
>> making it okay to default to using no CW, that should be explained
>> here.

  The next 16 bits provide a sequence number that can be used to
  guarantee ordered frame delivery. The processing of the sequence
  number field is OPTIONAL.

>> If processing this field is optional, how can it be used to guarantee
>> anything?

Note to RFC Editor

At the end of Section 2, please add the following sentence:

"Additional terminology relevant to pseudowires and Layer 2 Virtual Private
Networking (L2VPN) in general may be found in [RFC4026]."

Please replace the first three paragraphs of Section 4.6 with the following
text:

  The Control Word defined in this section is based on the
  Generic PW MPLS Control Word as defined in [PWE3-CW]. It
  provides the ability to sequence individual frames on the
  PW, avoidance of equal-cost multiple-path load-balancing
  (ECMP) [RFC2992], and OAM mechanisms including VCCV [VCCV].

  [PWE3-CW] states, "If a PW is sensitive to packet misordering
  and is being carried over an MPLS PSN that uses the contents of the
  MPLS payload to select the ECMP path, it MUST employ a mechanism which
  prevents packet misordering." This is necessary due to the fact that
  ECMP implementations may examine the first nibble after the MPLS label
  stack to determine whether the labelled packet is IP or not. Thus,
  if the source MAC address of an ethernet frame carried over
  the PW without a control word present begins with 0x4 or 0x6, it
  could be mistaken for an IPv4 or IPv6 packet. This could, depending
  on the configuration and topology of the MPLS network, lead to a
  situation where all packets for a given PW do not follow the
  same path. This may increase out-of-order frames on a given
  PW, or cause OAM packets to follow a different path than actual
  traffic (see section 4.4.3 on Frame Ordering).   

  The features that the control word provides may not be
  needed for a given ethernet PW. For example, ECMP may not
  be present or active on a given MPLS network, strict
  frame sequencing may not be required, etc. If this is the
  case, the control word provides little value and is therefore
  optional. Early ethernet PW implementations have been deployed
  that do not include a control word or the ability to process one if
  present. To aid in backwards compatibility, future
  implementations MUST be able to send and receive frames without
  the control word present.

  In all cases the ingress PE MUST be aware of whether the egress
  PE will send a control word over a specific PW. This may be
  achieved by configuration of the PEs, or by signaling, as
  defined in [PWE3-CTRL].

 
Additional Informational References:

  [VCCV] T. D. Nadeau, R. Aggarwal, "Pseudo Wire Virtual Circuit
          Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-07.txt,
          August 2005. (work in progress)

  [RFC2992] RFC-2992:  Analysis of an Equal-Cost Multi-Path
            Algorithm, C. Hopps, November 2000

  [RFC4026] Andersson, L., Madsen, T. "Provider Provisioned
            Virtual Private Network (VPN) Terminology", RFC
            4026, March 2005.

Spoke with Margaret 12/9, two items remain for her to clear her discuss:

1. Terms defined, can be handled via ref to terminology document

2. Control Word handling still contradicts a SHOULD in the base CW draft. If it is a MAY in this document due to the fact the most existing hardware supports this and it should only rarely be a problem, come out and say it this way. Current text seems to evade this and is not clear.

Mark will handle these via an RFC Editor's note, and Margaret will clear discuss. Document should then be ready to move forward.

[Ballot comment]
I found this document fairly unclear and while I could eventually
understand it, I do not believe it is ready for publication without
IEEE review and significant clarification.  However I believe
Margaret's discuss is a strict superset of the issues I identified.

[Ballot discuss]
I understand that this specification is widely implemented and useful,
and I support the idea of standardizing it.  However, I have two major
technical issues with the document:

(1) This document makes the control word optional without explaining
    why it is safe to ignore the SHOULD in the control word document.

(2) The sequence number section has some inconsistencies that make it
    unclear how/if use of the sequence number feature will actually
    result in in-order packet delivery.

I also would like to know whether or not this specification has been
reviewed by Bernard Aboba or Dan Romascanu (our IEEE 802.3 liaisons),
and/or whether it has been reviewed by IEEE 802.3.  I am particularly
interested in their feedback about the gig Etherent flow control
discussion.

I'm also concerned that some parts of this spec are not clear enough
to permit interoperable implementation.  My specific comments are
in-line, marked with >>:

2. Introduction

  An Ethernet Pseudowire (PW) allows Ethernet/802.3 Protocol Data Units
  (PDUs) to be carried over an MPLS network. In addressing the issues
  associated with carrying an Ethernet PDU over a Public Switched
  Network (PSN), this document assumes that a Pseudowire (PW) has been
  set up by using the LDP protocol as described in [PWE3-CTRL]. This
  may be via manual configuration, or a signaling protocol such as LDP,
  as defined in [PWE3-CTRL].

>> The last two sentences contradict each other.  The first says that
>> LDP is assumed, and the second says that LDP or manual
>> configuration may be used. 

>> Also, the reference to the IEEE 802.3 spec should be included here
>> (the first time that IEEE 802.3 is mentioned) not later.  Also,
>> MPLS should be expanded the first time it is used, and a normative
>> reference should be provided.

  The "emulated service" shown in Figure 1 is, strictly speaking, a
  bridged LAN; the PEs have MAC interfaces, consume MAC control frames,
  etc. However, the procedures specified herein only support the case
  in which there are two CEs on the "emulated LAN". Hence we refer to
  this service as "emulated point-to-point ethernet". Specification of
  the procedures for using pseudo wires to emulate LANs with more than
  two CEs are out of scope of the current document.

>> The terms PE and CE have not been defined. (I know what they mean,
>> this is strictly editorial.)

  The following reference model describes the termination point of each
  end of the PW within the PE:

          +-----------------------------------+
          |                PE                |
  +---+  +-+  +-----+  +------+  +------+  +-+
  |  |  |P|  |    |  |PW ter|  | PSN  |  |P|
  |  |<==|h|<=| NSP |<=|minati|<=|Tunnel|<=|h|<== From PSN
  |  |  |y|  |    |  |on    |  |      |  |y|
  | C |  +-+  +-----+  +------+  +------+  +-+
  | E |  |                                  |
  |  |  +-+  +-----+  +------+  +------+  +-+
  |  |  |P|  |    |  |PW ter|  | PSN  |  |P|
  |  |==>|h|=>| NSP |=>|minati|=>|Tunnel|=>|h|==> To PSN
  |  |  |y|  |    |  |on    |  |      |  |y|
  +---+  +-+  +-----+  +------+  +------+  +-+
          |                                  |
          +-----------------------------------+
                  ^        ^          ^
                  |        |          |
                  A        B          C

          Figure 3: PW reference diagram

>> This diagram doesn't seem right to me.  Is it really the case that
>> the CE will have two separate Phys for receive and transmit?  I
>> know that the PSN tunnels are uni-directional, but the Ethernet is
>> bi-directional, right?  I would have expected something like this:

          +------------------------------------+
          |                PE                |
  +---+  +-+  +-----+  +------+  +------+  +-+
  |  |  |P|  |    |  |PW ter|  | PSN  |  |P|
  |  |<=>|h|<=| NSP |<=>|minati|<=|Tunnel|<=|h|<== From PSN
  |  |  |y|  |    |  |on    |  |      |  |y|
  | C |  +-+  +-----+  |      |  +------+  +-+
  | E |  |              |      |              |
  |  |  |              |      |  +------+  +-+
  |  |  |              |      |  | PSN  |  |P|
  |  |  |              |      |=>|Tunnel|=>|h|==> To PSN
  |  |  |              |      |  |      |  |y|
  +---+  |              +------+  +------+  +-+
          |                                    |
          +------------------------------------+
                  ^        ^          ^
                  |        |          |
                  A        B          C

>> If my rendering isn't more accurate, could you explain why?

  The Native Service Processing (NSP) function includes frame
  processing that is required for the Ethernet frames that are
  forwarded to the PW termination point. Such functions may include
  stripping, overwriting or adding VLAN tags, physical port
  multiplexing and demultiplexing, PW-PW bridging, L2 encapsulation,
  shaping, policing, etc. These functions are specific to the native
  frame technology , and may not be required for the PW emulation
  service.

>> The "native frame technology" is always Ethernet in this case,
>> right?  If so, why not say ethernet?

  An ethernet PW operates in one of two modes: "raw mode" or "tagged
  mode". In tagged mode, each frame MUST contain an 802.1Q VLAN tag,

>> s/MUST contain an/MUST contain at least one??  (and subsequent
>> change to make the sentence work)

  and the tag value is meaningful to the NSPs at the two PW termination
  points. That is, the two PW termination points must have some
  agreement (signaled or manually configured) on how to process the
  tag. On a raw mode PW, a frame MAY contain an 802.1Q VLAN tag, but if
  it does, the tag is not meaningful to the NSPs, and passes
  transparently through them.

>> You should include the reference to 802.1Q here, rather than later.

3. Details Specific to Particular Emulated Services

3.1. Ethernet Tagged Mode

  The Ethernet frame will be encapsulated according to the procedures
  defined in this document "tagged mode".

>> Sentence doesn't parse. 

  It should be noted that if
  the VLAN identifier is modified by the egress PE, the Ethernet
  spanning tree protocol might fail to work properly. If the PE detects
  a failure on the Ethernet physical port, or the port is
  administratively disabled, it MUST send PW status notification
  message for all PWs associated with the port. This mode uses
  service-delimiting tags to map input ethernet frames to respective
  PWs and is corresponds to PW type 0x0004 "Ethernet Tagged Mode"
  [IANA].

>> I don't understand what this paragraph means...  The first sentence
>> points out a concern, and I'm not sure what the resolution is.  Don't
>> use tagged mode?  Stack the VLAN tags so that the original values
>> are maintained across the PW?  Or is the second sentence suppose to
>> be the resolution? 

3.2. Ethernet

  The Ethernet frame will be encapsulated according to the procedures
  defined in this document "raw mode".

>> Sentence doesn't parse.

  If the PE detects a failure on
  the Ethernet input port, or the port is administratively disabled,
  the PE MUST send an appropriate PW status notification message to the
  corresponding remote PE. 

>> Is this meant to be the same as the statement in the previous
>> section about a failure on the physical port?  If so, why different
>> wording?  If not, what is the difference?

3.3. Ethernet Specific Interface Parameter Sub-TLV

  This sub-TLV specifies interface specific parameters.

>> What is a sub-TLV?  This term should be defined or referenced.

3.4. Generic Procedures

  When the NSP/Forwarder hands a frame to the PW termination function:

    - The preamble (if any) and FCS are stripped off.

    - The control word as defined in the "The Control Word" section is,
      if necessary, prepended to the resulting frame. The conditions
      under which the control word is or is not used are specified
      below.

    - The proper Pseudowire demultiplexor ( PW Label ) is prepended to
      the resulting packet.

    - The proper tunnel encapsulation is prepended to the resulting
      packet.

>> The tunnel encapsultion will always be MPLS, right?

    - The packet is transmitted.

  The way in which the proper tunnel encapsulation and pseudo wire
  demultiplexor are chosen depends on the procedures that were used to
  set up the pseudo wire.

>> What are the choices?  And, when would one or the other be used?

3.4.1. Raw Mode vs. Tagged Mode

  When the PE receives an ethernet frame, and the frame has a VLAN tag,
  we can distinguish two cases:

>> How can "we" distinguish these two cases?  (Well-known values of
>> the VLAN tag, based on local configuration, based on some signalled
>> information?)

      1. The tag is "service-delimiting". This means that the tag was
        placed on the frame by some piece of service provider-operated
        equipment, and the tag is used by the service provider to
        distinguish the traffic. For example, LANs from different
        customers might be attached to the same service provider
        switch, which applies VLAN tags to distinguish one customer's
        traffic from another's, and then forwards the frames to the PE.

      2. The tag is not service-delimiting. This means that the tag was
        placed in the frame by a piece of customer equipment, and is
        not meaningful to the PE.

>> Is there a built-in assumption that there is only one "provider"?
>> i.e. that any "service delimiting tag" would have been placed in the
>> packet by the same provider that is offering the PW service?
>>
>> This section could probably benefit from being broken out into two
>> separate sections describing raw and tagged mode processing
>> separately.  As is, I have trouble figuring out exactly what the
>> PE should do in each of the four cases (two modes, two types of
>> tags).

  None of these
  tags may be service-delimiting, otherwise only one of these tags may
  be service-delimiting.

>> This sentence is unnecessarily obscure.  How about:  At most one
>> these tags may be service-delimiting.

3.4.2. MTU Management on the PE/CE Links

  The Ethernet PW MUST NOT be enabled unless it is known that the MTUs
  of the CE-PE links are the same at both ends of the PW.

>> Why is this section separate from the later, more complete discussion
>> of MTU issues?

3.4.3. Frame Ordering

  In general, applications running over Ethernet do not require strict
  frame ordering. However the IEEE definition of 802.3 [802.3] requires
  that frames from the same conversation are delivered in sequence.
  Moreover, the PSN cannot (in the general case) be assumed to provide
  or to guarantee frame ordering.  An ethernet PW can, through use of
  the control word, provide strict frame ordering. If this option is
  enabled, any frames which get misordered by the PSN will be dropped

>> Later, you indicate that misordered packets may be dropped or
>> reordered.  Also, it is not entirely clear that enabling this
>> option actually delivers on the promise that packets will not
>> arrive out-of-order, although I am not sure if that is accidental
>> or intentional (see below).

  by the receiving PW endpoint. If strict frame ordering is a
  requirement for a particular PW, this option MUST be enabled.

3.5. PW Setup and Maintenance

  This document assumes that a mechanism exists to set up the ethernet
  PW.  Maintenance of the PW (e.g. keepalives, status updates, etc) is
  generally tied closely to the PW Setup mechanisms. [PWE3-CTRL] and
  [L2TPv3] define two mechanisms for setup and maintenance of Ethernet
  PWs.

>> I thought that this document was concerned only with Ethernet over
>> MPLS.  Where does L2TPv3 come in?

3.7. The Control Word

  When carrying Ethernet over an MPLS backbone, sequentiality may need
  to be preserved.  The OPTIONAL control word defined here addresses
  this requirement.  Implementations MUST support sending no control
  word, and MAY support sending a control word.

>> This is inconsistent with the control word document, which says that
>> a control word SHOULD be used to avoid various problems.  If there
>> is some reason why those problems would not apply to ethernet frames,
>> making it okay to default to using no CW, that should be explained
>> here.

  The control word is defined as follows:

>> This is a definition specific to this encapsulation, right?

  The next 16 bits provide a sequence number that can be used to
  guarantee ordered frame delivery. The processing of the sequence
  number field is OPTIONAL.

>> If processing this field is optional, how can it be used to guarantee
>> anything?

  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.

3.7.1. Setting the sequence number

  For a given PW, and a pair of routers PE1 and PE2, if PE1 supports
  frame sequencing then the following procedures should be used:

    - the initial frame transmitted on the PW MUST use sequence number
      1
    - subsequent frames MUST increment the sequence number by one for
      each frame
    - when the transmit sequence number reaches the maximum 16 bit
      value (65535) the sequence number MUST wrap to 1

  If the transmitting router PE1 does not support sequence number
  processing, then the sequence number field in the control word MUST
  be set to 0.

3.7.2. Processing the sequence number

  If a router PE2 supports receive sequence number processing, then the
  following procedures should be used:

  When a PW is initially set up, the "expected sequence number"
  associated with it MUST be initialized to 1.

  When a frame is received on that PW, the sequence number should be
  processed as follows:

    - if the sequence number on the frame is 0, then the sequence
      number check is skipped. ( sequence check disabled )

    - otherwise if the frame sequence number >= the expected sequence
      number and the frame sequence number - the expected sequence
      number < 32768, then the frame is in order.

>> I am not sure that you mean to state that this packet is in order
>> unless the expected sequence number matches the frame sequence
>> number.  See below.

    - otherwise if the frame sequence number < the expected sequence
      number and the expected sequence number - the frame sequence
      number >= 32768, then the frame is in order.

>> It might be worthwhile to state here that these comparisons are all based
>> on unsigned 32-bit numbers.

    - otherwise the frame is out of order.

  If a frame passes the sequence number check, or is in order

>> What does it mean to "pass the sequence number check" as opposed to being
>> "in order"?

  then, it
  can be delivered immediately. If the frame is in order, then the
  expected sequence number should be set using the algorithm:

  expected_sequence_number := frame_sequence_number + 1 mod 2**16
  if (expected_sequence_number = 0) then expected_sequence_number := 1;

>> If I understand this correctly, if packets are mis-ordered, we will
>> deliver any future packets immediately on processing and reset the
>> expected sequence number.  So there is no opportunity to later
>> reorder packets to reassert the correct order, right?  That's okay,
>> but it is inconsistent with the next sentence:

  Packets which are received out of order MAY be dropped or reordered
  at the discretion of the receiver.

>> Also, I think that you mean to say that packets that are received
>> out of order _MUST_ be dropped (or reordered?).  Otherwise, it would
>> be in spec to go through all of this processing and just sent the
>> packets out-or-order anyway.

  If a PE router negotiated not to use receive sequence number
  processing, and it received a non zero sequence number, then it
  SHOULD send a PW status message indicating a receive fault, and
  disable the PW.

5. PSN MTU Requirements

  The PSN MUST be configured with an MTU that is large enough to
  transport a maximum sized ethernet frame which has been encapsulated
  with a control word, a pseudo wire demultiplexor, and a tunnel
  encapsulation.  If MPLS is used as the tunneling protocol, for
  example, this is likely to be 8 or more bytes greater than the
  largest frame size. Other tunneling protocols may have longer headers
  and require larger MTUs.

>> As far as I know, MPLS is the only tunneling protocol discussed
>> in this document.  Right?

  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.

9. Normative References

>> You need normative references to Ethernet, VLANs and MPLS, I think.

[Ballot discuss]
I understand that this specification is widely implemented and useful,
and I support the idea of standardizing it.  However, I have two major
technical issues with the document:

(1) This document makes the control word optional without explaining
    why it is safe to ignore the SHOULD in the control word document.

(2) The sequence number section has some inconsistencies that make it
    unclear how/if use of the sequence number feature will actually
    result in in-order packet delivery.

I also would like to know whether or not this specification has been
reviewed by Bernard Aboba or Dan Romascanu (our IEEE 802.3 liaisons),
and/or whether it has been reviewed by IEEE 802.3.  I am particularly
interested in their feedback about the gig Etherent flow control
discussion.

I'm also concerned that some parts of this spec are not clear enough
to permit interoperable implementation.  My specific comments are
in-line, marked with >>:

2. Introduction

  An Ethernet Pseudowire (PW) allows Ethernet/802.3 Protocol Data Units
  (PDUs) to be carried over an MPLS network. In addressing the issues
  associated with carrying an Ethernet PDU over a Public Switched
  Network (PSN), this document assumes that a Pseudowire (PW) has been
  set up by using the LDP protocol as described in [PWE3-CTRL]. This
  may be via manual configuration, or a signaling protocol such as LDP,
  as defined in [PWE3-CTRL].

>> The last two sentences contradict each other.  The first says that
>> LDP is assumed, and the second says that LDP or manual
>> configuration may be used. 

>> Also, the reference to the IEEE 802.3 spec should be included here
>> (the first time that IEEE 802.3 is mentioned) not later.  Also,
>> MPLS should be expanded the first time it is used, and a normative
>> reference should be provided.

  The "emulated service" shown in Figure 1 is, strictly speaking, a
  bridged LAN; the PEs have MAC interfaces, consume MAC control frames,
  etc. However, the procedures specified herein only support the case
  in which there are two CEs on the "emulated LAN". Hence we refer to
  this service as "emulated point-to-point ethernet". Specification of
  the procedures for using pseudo wires to emulate LANs with more than
  two CEs are out of scope of the current document.

>> The terms PE and CE have not been defined. (I know what they mean,
>> this is strictly editorial.)

  The following reference model describes the termination point of each
  end of the PW within the PE:

          +-----------------------------------+
          |                PE                |
  +---+  +-+  +-----+  +------+  +------+  +-+
  |  |  |P|  |    |  |PW ter|  | PSN  |  |P|
  |  |<==|h|<=| NSP |<=|minati|<=|Tunnel|<=|h|<== From PSN
  |  |  |y|  |    |  |on    |  |      |  |y|
  | C |  +-+  +-----+  +------+  +------+  +-+
  | E |  |                                  |
  |  |  +-+  +-----+  +------+  +------+  +-+
  |  |  |P|  |    |  |PW ter|  | PSN  |  |P|
  |  |==>|h|=>| NSP |=>|minati|=>|Tunnel|=>|h|==> To PSN
  |  |  |y|  |    |  |on    |  |      |  |y|
  +---+  +-+  +-----+  +------+  +------+  +-+
          |                                  |
          +-----------------------------------+
                  ^        ^          ^
                  |        |          |
                  A        B          C

          Figure 3: PW reference diagram

>> This diagram doesn't seem right to me.  Is it really the case that
>> the CE will have two separate Phys for receive and transmit?  I
>> know that the PSN tunnels are uni-directional, but the Ethernet is
>> bi-directional, right?  I would have expected something like this:

          +------------------------------------+
          |                PE                |
  +---+  +-+  +-----+  +------+  +------+  +-+
  |  |  |P|  |    |  |PW ter|  | PSN  |  |P|
  |  |<=>|h|<=| NSP |<=>|minati|<=|Tunnel|<=|h|<== From PSN
  |  |  |y|  |    |  |on    |  |      |  |y|
  | C |  +-+  +-----+  |      |  +------+  +-+
  | E |  |              |      |              |
  |  |  |              |      |  +------+  +-+
  |  |  |              |      |  | PSN  |  |P|
  |  |  |              |      |=>|Tunnel|=>|h|==> To PSN
  |  |  |              |      |  |      |  |y|
  +---+  |              +------+  +------+  +-+
          |                                    |
          +------------------------------------+
                  ^        ^          ^
                  |        |          |
                  A        B          C

>> If my rendering isn't more accurate, could you explain why?

  The Native Service Processing (NSP) function includes frame
  processing that is required for the Ethernet frames that are
  forwarded to the PW termination point. Such functions may include
  stripping, overwriting or adding VLAN tags, physical port
  multiplexing and demultiplexing, PW-PW bridging, L2 encapsulation,
  shaping, policing, etc. These functions are specific to the native
  frame technology , and may not be required for the PW emulation
  service.

>> The "native frame technology" is always Ethernet in this case,
>> right?  If so, why not say ethernet?

  An ethernet PW operates in one of two modes: "raw mode" or "tagged
  mode". In tagged mode, each frame MUST contain an 802.1Q VLAN tag,

>> s/MUST contain an/MUST contain at least one??  (and subsequent
>> change to make the sentence work)

  and the tag value is meaningful to the NSPs at the two PW termination
  points. That is, the two PW termination points must have some
  agreement (signaled or manually configured) on how to process the
  tag. On a raw mode PW, a frame MAY contain an 802.1Q VLAN tag, but if
  it does, the tag is not meaningful to the NSPs, and passes
  transparently through them.

>> You should include the reference to 802.1Q here, rather than later.

3. Details Specific to Particular Emulated Services

3.1. Ethernet Tagged Mode

  The Ethernet frame will be encapsulated according to the procedures
  defined in this document "tagged mode".

>> Sentence doesn't parse. 

  It should be noted that if
  the VLAN identifier is modified by the egress PE, the Ethernet
  spanning tree protocol might fail to work properly. If the PE detects
  a failure on the Ethernet physical port, or the port is
  administratively disabled, it MUST send PW status notification
  message for all PWs associated with the port. This mode uses
  service-delimiting tags to map input ethernet frames to respective
  PWs and is corresponds to PW type 0x0004 "Ethernet Tagged Mode"
  [IANA].

>> I don't understand what this paragraph means...  The first sentence
>> points out a concern, and I'm not sure what the resolution is.  Don't
>> use tagged mode?  Stack the VLAN tags so that the original values
>> are maintained across the PW?  Or is the second sentence suppose to
>> be the resolution? 

3.2. Ethernet

  The Ethernet frame will be encapsulated according to the procedures
  defined in this document "raw mode".

>> Sentence doesn't parse.

  If the PE detects a failure on
  the Ethernet input port, or the port is administratively disabled,
  the PE MUST send an appropriate PW status notification message to the
  corresponding remote PE. 

>> Is this meant to be the same as the statement in the previous
>> section about a failure on the physical port?  If so, why different
>> wording?  If not, what is the difference?

3.3. Ethernet Specific Interface Parameter Sub-TLV

  This sub-TLV specifies interface specific parameters.

>> What is a sub-TLV?  This term should be defined or referenced.

3.4. Generic Procedures

  When the NSP/Forwarder hands a frame to the PW termination function:

    - The preamble (if any) and FCS are stripped off.

    - The control word as defined in the "The Control Word" section is,
      if necessary, prepended to the resulting frame. The conditions
      under which the control word is or is not used are specified
      below.

    - The proper Pseudowire demultiplexor ( PW Label ) is prepended to
      the resulting packet.

    - The proper tunnel encapsulation is prepended to the resulting
      packet.

>> The tunnel encapsultion will always be MPLS, right?

    - The packet is transmitted.

  The way in which the proper tunnel encapsulation and pseudo wire
  demultiplexor are chosen depends on the procedures that were used to
  set up the pseudo wire.

>> What are the choices?  And, when would one or the other be used?

3.4.1. Raw Mode vs. Tagged Mode

  When the PE receives an ethernet frame, and the frame has a VLAN tag,
  we can distinguish two cases:

>> How can "we" distinguish these two cases?  (Well-known values of
>> the VLAN tag, based on local configuration, based on some signalled
>> information?)

      1. The tag is "service-delimiting". This means that the tag was
        placed on the frame by some piece of service provider-operated
        equipment, and the tag is used by the service provider to
        distinguish the traffic. For example, LANs from different
        customers might be attached to the same service provider
        switch, which applies VLAN tags to distinguish one customer's
        traffic from another's, and then forwards the frames to the PE.

      2. The tag is not service-delimiting. This means that the tag was
        placed in the frame by a piece of customer equipment, and is
        not meaningful to the PE.

>> Is there a built-in assumption that there is only one "provider"?
>> i.e. that any "service delimiting tag" would have been placed in the
>> packet by the same provider that is offering the PW service?
>>
>> This section could probably benefit from being broken out into two
>> separate sections describing raw and tagged mode processing
>> separately.  As is, I have trouble figuring out exactly what the
>> PE should do in each of the four cases (two modes, two types of
>> tags).

  None of these
  tags may be service-delimiting, otherwise only one of these tags may
  be service-delimiting.

>> This sentence is unnecessarily obscure.  How about:  At most one
>> these tags may be service-delimiting.

3.4.2. MTU Management on the PE/CE Links

  The Ethernet PW MUST NOT be enabled unless it is known that the MTUs
  of the CE-PE links are the same at both ends of the PW.

>> Why is this section separate from the later, more complete discussion
>> of MTU issues?

3.4.3. Frame Ordering

  In general, applications running over Ethernet do not require strict
  frame ordering. However the IEEE definition of 802.3 [802.3] requires
  that frames from the same conversation are delivered in sequence.
  Moreover, the PSN cannot (in the general case) be assumed to provide
  or to guarantee frame ordering.  An ethernet PW can, through use of
  the control word, provide strict frame ordering. If this option is
  enabled, any frames which get misordered by the PSN will be dropped

>> Later, you indicate that misordered packets may be dropped or
>> reordered.  Also, it is not entirely clear that enabling this
>> option actually delivers on the promise that packets will not
>> arrive out-of-order, although I am not sure if that is accidental
>> or intentional (see below).

  by the receiving PW endpoint. If strict frame ordering is a
  requirement for a particular PW, this option MUST be enabled.

3.5. PW Setup and Maintenance

  This document assumes that a mechanism exists to set up the ethernet
  PW.  Maintenance of the PW (e.g. keepalives, status updates, etc) is
  generally tied closely to the PW Setup mechanisms. [PWE3-CTRL] and
  [L2TPv3] define two mechanisms for setup and maintenance of Ethernet
  PWs.

>> I thought that this document was concerned only with Ethernet over
>> MPLS.  Where does L2TPv3 come in?

3.7. The Control Word

  When carrying Ethernet over an MPLS backbone, sequentiality may need
  to be preserved.  The OPTIONAL control word defined here addresses
  this requirement.  Implementations MUST support sending no control
  word, and MAY support sending a control word.

>> This is inconsistent with the control word document, which says that
>> a control word SHOULD be used to avoid various problems.  If there
>> is some reason why those problems would not apply to ethernet frames,
>> making it okay to default to using no CW, that should be explained
>> here.

  The control word is defined as follows:

>> This is a definition specific to this encapsulation, right?

  The next 16 bits provide a sequence number that can be used to
  guarantee ordered frame delivery. The processing of the sequence
  number field is OPTIONAL.

>> If processing this field is optional, how can it be used to guarantee
>> anything?

  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.

3.7.1. Setting the sequence number

  For a given PW, and a pair of routers PE1 and PE2, if PE1 supports
  frame sequencing then the following procedures should be used:

    - the initial frame transmitted on the PW MUST use sequence number
      1
    - subsequent frames MUST increment the sequence number by one for
      each frame
    - when the transmit sequence number reaches the maximum 16 bit
      value (65535) the sequence number MUST wrap to 1

  If the transmitting router PE1 does not support sequence number
  processing, then the sequence number field in the control word MUST
  be set to 0.

3.7.2. Processing the sequence number

  If a router PE2 supports receive sequence number processing, then the
  following procedures should be used:

  When a PW is initially set up, the "expected sequence number"
  associated with it MUST be initialized to 1.

  When a frame is received on that PW, the sequence number should be
  processed as follows:

    - if the sequence number on the frame is 0, then the sequence
      number check is skipped. ( sequence check disabled )

    - otherwise if the frame sequence number >= the expected sequence
      number and the frame sequence number - the expected sequence
      number < 32768, then the frame is in order.

>> I am not sure that you mean to state that this packet is in order
>> unless the expected sequence number matches the frame sequence
>> number.  See below.

    - otherwise if the frame sequence number < the expected sequence
      number and the expected sequence number - the frame sequence
      number >= 32768, then the frame is in order.

>> It might be worthwhile to state here that these comparisons are all based
>> on unsigned 32-bit numbers.

    - otherwise the frame is out of order.

  If a frame passes the sequence number check, or is in order

>> What does it mean to "pass the sequence number check" as opposed to being
>> "in order"?

  then, it
  can be delivered immediately. If the frame is in order, then the
  expected sequence number should be set using the algorithm:

  expected_sequence_number := frame_sequence_number + 1 mod 2**16
  if (expected_sequence_number = 0) then expected_sequence_number := 1;

>> If I understand this correctly, if packets are mis-ordered, we will
>> deliver any future packets immediately on processing and reset the
>> expected sequence number.  So there is no opportunity to later
>> reorder packets to reassert the correct order, right?  That's okay,
>> but it is inconsistent with the next sentence:

  Packets which are received out of order MAY be dropped or reordered
  at the discretion of the receiver.

>> Also, I think that you mean to say that packets that are received
>> out of order _MUST_ be dropped (or reordered?).  Otherwise, it would
>> be in spec to go through all of this processing and just sent the
>> packets out-or-order anyway.

  If a PE router negotiated not to use receive sequence number
  processing, and it received a non zero sequence number, then it
  SHOULD send a PW status message indicating a receive fault, and
  disable the PW.

5. PSN MTU Requirements

  The PSN MUST be configured with an MTU that is large enough to
  transport a maximum sized ethernet frame which has been encapsulated
  with a control word, a pseudo wire demultiplexor, and a tunnel
  encapsulation.  If MPLS is used as the tunneling protocol, for
  example, this is likely to be 8 or more bytes greater than the
  largest frame size. Other tunneling protocols may have longer headers
  and require larger MTUs.

>> As far as I know, MPLS is the only tunneling protocol discussed
>> in this document.  Right?

  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.

9. Normative References

>> You need normative references to Ethernet, VLANs and MPLS, I think.

[Ballot comment]
Reference/citation problems:

  !! Missing Reference for citation: [L2TPv3]
  P010 L014:    [L2TPv3] define two mechanisms for setup and maintenance of Ethernet

  !! Missing Reference for citation: [PWE3-MIB]
  P010 L021:    defined in [RFC3985] and [PWE3-MIB]. Many common PW management
  There is a citation (and refrence) for [PW-MIB], so probably just a consistency issue

  !! Missing citation for Normative reference:
  P015 L008:    [PWE3-CW] "PWE3 Control Word for use over an MPLS PSN", S. Bryant,

Weird formatting in NORMATIVE references:
  [PWE3-CTRL] "Transport of Layer 2 Frames Over MPLS", Martini L.,et al
        draft-ietf-pwe3-control-protocol-09.txt, ( work in progress ),
        September 2004.
        [RFC3031] E. Rosen, et al., RFC 3031, MPLS Architecture, January
        2001.

[Ballot comment]
Advice to new user of proto method: the wg chair shepherd's questionnaire
items before the normal writeup should go into the log, not in the
ballot.

[Ballot comment]
> 3.3. Ethernet Specific Interface Parameter Sub-TLV
>
>    This sub-TLV specifies interface specific parameters. When
>    applicable, it MUST be used to validate that the PEs, and the ingress
>    and egress ports at the edges of the circuit, have the necessary

Who does the reader decide "when applicable"?

> 3.4.2. MTU Management on the PE/CE Links
>
>    The Ethernet PW MUST NOT be enabled unless it is known that the MTUs
>    of the CE-PE links are the same at both ends of the PW.

Reference to [PWE3-CTRL] is needed here.

> 3.4.3. Frame Ordering
>
>    In general, applications running over Ethernet do not require strict
>    frame ordering. However the IEEE definition of 802.3 [802.3] requires
>    that frames from the same conversation are delivered in sequence.
>    Moreover, the PSN cannot (in the general case) be assumed to provide
>    or to guarantee frame ordering.  An ethernet PW can, through use of
>    the control word, provide strict frame ordering. If this option is
>    enabled, any frames which get misordered by the PSN will be dropped
>    by the receiving PW endpoint. If strict frame ordering is a
>    requirement for a particular PW, this option MUST be enabled.

"MUST" here is not an implementation requirement, is it?
If so, "must"?

[Ballot comment]
In many, many places: s/ethernet/Ethernet/

  Pick one of the following, and use it throughout the document:
  "PW type 0x0004" or "PW type 4"

[Ballot comment]
Fairly strong suggestion - the IANA Considerations should
cite the [IANA] reference.

From Gen-ART review by Joel Halpern:

Probably minor:
Section 3.3 sometimes refers to the information it is discussing as the VLAN tab [BC - "tag" actually] and sometimes as the VLAN ID [BC - and also as the "VLAN ID tag"].  I think these are supposed to be the same thing? [BC - I assume the tag carries the VLAN ID] If they are actually two different concepts, then some technical text is required to avoid confusing the reader.  If they are the same thing, then a sentence reminding the reader of the meaning would be helpful.  (I suspect that VLAN ID refers to a field used to carry the VLAN tag, and that all will be clear later.  But it should be clear here. [BC - yes])
Also, the wording in this section makes it appear that this document is defining the 06 code point for the sub-TLV.  If so, shouldn't that appear in the IANA considerations section? [BC - No, it is assigned by the [IANA] normative reference.]

Section 3.4.3 on Frame Ordering says that if ordering is used, and misordered frames "will be dropped by the receiving PW".  However, in section 3.7.2 it says that Packets which are received out of order "MAY be dropped or reordered".  I think that this is just a matter of fixing the words in 3.4.3.  But they ought to be consistent.

Minor:
In the introduction, it says:
  ... this document assumes that a Pseudowire (PW) has been
  set up by using the LDP protocol as described in [PWE3-CTRL]. This
  may be via manual configuration, or a signaling protocol such as LDP
The sentence therefore says it is set up via LDP, and then says either manually or via LDP?  Presumably it
should say just the second phrase.

In figure 3 there is a pair of boxes labelled PW termination with a pointer labelled B.  The text following the diagram refers to the PW as terminating at point A in the diagram.  It appears that was supposed to say B.
This occurs again when it says "The point to the left of A, ... and any adaptation (NXP) functions ..." Since point A points
at the NSP, presumably that was supposed to say "to the left of B".
And the text reading "PW Termination", between A and B presumably needs to read "at B", since B points at the PW Termination box.

Section 3.3 "Ethernet Specific Interface Parameter Sub-TLV" really ought to explicitly state what protocol and message this sub-TLV is part of.  The reader can guess that it is some LDP message, but guessing is a bad practice.

[Ballot comment]
From Gen-ART review by Joel Halpern:

Probably minor:
Section 3.3 sometimes refers to the information it is discussing as the VLAN tab [BC - "tag" actually] and sometimes as the VLAN ID [BC - and also as the "VLAN ID tag"].  I think these are supposed to be the same thing? [BC - I assume the tag carries the VLAN ID] If they are actually two different concepts, then some technical text is required to avoid confusing the reader.  If they are the same thing, then a sentence reminding the reader of the meaning would be helpful.  (I suspect that VLAN ID refers to a field used to carry the VLAN tag, and that all will be clear later.  But it should be clear here. [BC - yes])
Also, the wording in this section makes it appear that this document is defining the 06 code point for the sub-TLV.  If so, shouldn't that appear in the IANA considerations section?

Section 3.4.3 on Frame Ordering says that if ordering is used, and misordered frames "will be dropped by the receiving PW".  However, in section 3.7.2 it says that Packets which are received out of order "MAY be dropped or reordered".  I think that this is just a matter of fixing the words in 3.4.3.  But they ought to be consistent.

Minor:
In the introduction, it says:
  ... this document assumes that a Pseudowire (PW) has been
  set up by using the LDP protocol as described in [PWE3-CTRL]. This
  may be via manual configuration, or a signaling protocol such as LDP
The sentence therefore says it is set up via LDP, and then says either manually or via LDP?  Presumably it
should say just the second phrase.

In figure 3 there is a pair of boxes labelled PW termination with a pointer labelled B.  The text following the diagram refers to the PW as terminating at point A in the diagram.  It appears that was supposed to say B.
This occurs again when it says "The point to the left of A, ... and any adaptation (NXP) functions ..." Since point A points
at the NSP, presumably that was supposed to say "to the left of B".
And the text reading "PW Termination", between A and B presumably needs to read "at B", since B points at the PW Termination box.

Section 3.3 "Ethernet Specific Interface Parameter Sub-TLV" really ought to explicitly state what protocol and message this sub-TLV is part of.  The reader can guess that it is some LDP message, but guessing is a bad practice.

[Ballot comment]
From Gen-ART review by Joel Halpern:

Probably minor:
Section 3.3 sometimes refers to the information it is discussing as the VLAN tab and sometimes as the VLAN ID.  I think these are supposed to be the same thing?  If they are actually two different concepts, then some technical text is required to avoid confusing the reader.  If they are the same thing, then a sentence reminding the reader of the meaning would be helpful.  (I suspect that VLAN ID refers to a field used to carry the VLAN tag, and that all will be clear later.  But it should be clear here.)
Also, the wording in this section makes it appear that this document is defining the 06 code point for the sub-TLV.  If so, shouldn't that appear in the IANA considerations section?

Section 3.4.3 on Frame Ordering says that if ordering is used, and misordered frames "will be dropped by the receiving PW".  However, in section 3.7.2 it says that Packets which are received out of order "MAY be dropped or reordered".  I think that this is just a matter of fixing the words in 3.4.3.  But they ought to be consistent.

Minor:
In the introduction, it says:
  ... this document assumes that a Pseudowire (PW) has been
  set up by using the LDP protocol as described in [PWE3-CTRL]. This
  may be via manual configuration, or a signaling protocol such as LDP
The sentence therefore says it is set up via LDP, and then says either manually or via LDP?  Presumably it
should say just the second phrase.

In figure 3 there is a pair of boxes labelled PW termination with a pointer labelled B.  The text following the diagram refers to the PW as terminating at point A in the diagram.  It appears that was supposed to say B.
This occurs again when it says "The point to the left of A, ... and any adaptation (NXP) functions ..." Since point A points
at the NSP, presumably that was supposed to say "to the left of B".
And the text reading "PW Termination", between A and B presumably needs to read "at B", since B points at the PW Termination box.

Section 3.3 "Ethernet Specific Interface Parameter Sub-TLV" really ought to explicitly state what protocol and message this sub-TLV is part of.  The reader can guess that it is some LDP message, but guessing is a bad practice.

[Note]: '2005-02-24: WG is still discussing changes to the following set of
documents (which will be sent to the IESG together):
draft-ietf-pwe3-control-protocol-15.txt, draft-ietf-pwe3-cw-02.txt,
draft-ietf-pwe3-ethernet-encap-09.txt,
draft-ietf-pwe3-iana-allocation-08.txt.
' added by Thomas Narten

[Note]: '2004-12-17: AD re-review raises some additional questions. see
comments in log. Also, this document needs to be advanced together as
part of a 4-doc bundle that includes:
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: Luca Martini
cc: Stewart Bryant , Danny McPherson
Date: Fri, 17 Dec 2004 15:33:30 -0500
Subject: Re: AD review of draft-ietf-pwe3-ethernet-encap-07.txt

Hi Luca.

I've rereviewed the document and also spoke with Stewart for a
bit. Here are some more comments and a proposed resolution. Apologies
if these seem like new comments. In looking at your changes, I wasn't
completely satisfied and in the end re-reviewed everything. I don't
think any of these are technical, they are really about making the
document clear. I'm also willing to help reviewing proposed text and
such.

I'll be working (still) next week, and would be willing to chat by
phone if that would be helpful.

Anyway, here is what I think is needed:

First, the folowing three documents are interrelated and need to go
through the IESG  more-or-less as a package:

draft-ietf-pwe3-ethernet-encap-08.txt
draft-ietf-pwe3-control-protocol-14.txt
draft-ietf-pwe3-cw-01.txt

Once they are through, I think we'll have a good idea of how to
progress the remaining documents. All three are on my plate (I need to
review the control-protocol document), so that is good.

On draft-ietf-pwe3-ethernet-encap-08.txt:

2004-12-13: review of -08 (check revisions)

> 2. Introduction
>
>    An Ethernet Pseudowire (PW) allows Ethernet/802.3 Protocol Data Units
>    (PDUs) to be carried over an IP network or an MPLS network. In
>    addressing the issues associated with carrying an Ethernet PDU over a
>    PSN, this document assumes that a Pseudowire (PW) has been set up by
>    some means outside the scope of this document. This may be via manual
>    configuration, or a signaling protocol such as that defined in
>    [PWE3-CTRL] or [L2TPv3]. As described in [PWE3-ARCH], this PW may be
>    tunneled through an MPLS, IPv4 or IPv6 PSN.

I understand that this document is _ONLY_ about pwe3 over MPLS. But
the above is not clear, suggesting that this documetn is abotu running
over IP _or_ over MPLS. Please make clear that this document is only
about pwe3 over MPLS. Its OK to mention that there are other documents
for some of the other cases (e.g., l2tp).

I still have a bit of difficulty with the introduction section. In the
end, I think the problem is that its unclear what is "normative" to
pwe3 (i.e, a part of the pwe3 spec) vs.  what is just background
information. For most of this section, its all background and not part
of pwe3 at all. Please clarify. Some specific comments:

>    The Native Service Processing (NSP) function includes frame
>    processing that is required for the Ethernet frames that are
>    forwarded to the PW termination point. Such functions may include
>    stripping, overwriting or adding VLAN tags, physical port
>    multiplexing and demultiplexing, PW-PW bridging, L2 encapsulation,
>    shaping, policing, etc.

>    The points to the left of A, including the physical layer between the
>    CE and PE, and any adaptation (NSP) functions between it and the PW
>    terminations, are outside of the scope of PWE3 and are not defined
>    here.

Would it be good to better say what PWE3 functions an NSP does? I
would have assumed none. I.e., its unclear reading the above whether
the NSP has any PWE3 functionality, or whether you are just
identifying some ethernet-specific functionality.

>    An ethernet PW can operate in one of two modes: "raw mode" or "tagged
>    mode".  In tagged mode, each frame MUST contain an 802.1Q VLAN tag,
>    and the tag value is meaningful to the NSPs at the two PW endpoints.
>    That is, the two endpoints must have some agreement (signaled or
>    manually configured) on how to process the tag. On a raw mode PW, a
>    frame MAY contain an 802.1Q VLAN tag, but if it does, the tag is not
>    meaningful to the NSPs, and passes transparently through them.

Please change to active voice, to make clear who adds the tag (and
why). Earlier, NSPs don't do PWE3 functions. But, some sorts of
tagging are for PWE3 purposes.

I.e., I _think_ that the above is trying to say that in "tagged mode",
tags are used for the explicit purpose of providing some specific PWE3
functionality. Standard 802.1Q VLAN tags are used, but they have
special meaning to the PWE3 (PW termination point specifically?)
(Actually, in speaking with Stewart, tags are not used by pwe3, but
for many deployments tags are useful anyway. This should be made more
clear).

Also, the last sentence says "NSPs don't process VLAN Tags". But don't
they? I'm fairly confused about this. Earlier, I thought I concluded
that NSPs don't have any PWE3-specific functionality in them.

>    When the NSP/Forwarder hands a frame to the PW endpoint:

What is the "endpoint"? Different terms are used in the picture.

>    When a packet arrives over a PW, the tunnel encapsulation and PW
>    demultiplexor are stripped off. If the control word is present, any
>    processing required by the control word is performed, and the control
>    word is stripped off. The resulting is then handed to the
>    Forwarder/NSP.  Regeneration of the FCS is considered to be an NSP
>    responsibility.

Use active voice?


>      - The preamble (if any) and FCS are stripped off.

It would be good to be more rigorous in terms of exactly what bits are
not passed to the PW endpoint, and which pieces are included (and are
expected to be transported to the remote end of the PW). Can you
supply a reference that shows exactly which parts of an Ethernet frame
included?


>      - The control word as defined in the "The Control Word" section is,
>        if necessary, prepended to the resulting frame. The conditions
>        under which the control word is or is not used are specified
>        below.

This is OK.

>      - The proper Pseudowire demultiplexor is prepended to the resulting
>        packet.

Need a reference (probably normative) to the document that defines
what this multiplexer is and what its format. I understand its just an
MPLS label; that should be made explicitely clear.

>      - The proper tunnel encapsulation is prepended to the resulting
>        packet.

Again, what encapsulation is being done? what is being prepended? If
an MPLS header (to the degree that they have a header) is meant here,
please say  so and provide an appropriate reference.

>    word is stripped off. The resulting is then handed to the

typo: the resulting what?


>    As specified in [PWE3-ARCH], an implementation SHOULD support the
>    generic and specific PW MIB modules for PW set-up and monitoring.

the above makes the MIB references normative. I.e,. "SHOULD support
the ... MIB" means you need a reference to the specific MIB documents
and they are normative. I gather that is not the intention of the
WG. Reword then to make clear that implementing the MIBs are not a
part of this spec.

>    In all cases the egress router must be aware of whether the ingress
>    router will send a control word over a specific virtual circuit.
>    This may be achieved by configuration of the routers, or by
>    signaling, for example as defined in [PWE3-CRTL].
>
>    The control word is defined as follows:

Shouldn't most/all of this section be replaced with a pointer to the
control word document? I.e., this document should  not repeat what is
in the other document, though it of course does need to describe (any)
differences.

>    In general, applications running over Ethernet do not require strict
>    frame ordering. However the IEEE definition of 802.3 [802.3] requires
>    that frames from the same conversation are delivered in sequence.
>    Moreover, the PSN cannot (in the general case) be assumed to provide
>    or to guarantee frame ordering. Therefore if strict frame ordering is
>    required, the sequence number MUST be utilized and its sequence
>    number processing enabled.

doesn't this just repeat what was said in 3.1.3?

> 4. Security Considerations

This may be problematical (seems skimpy at first glance); I need to
rereview this and the related documents.

> 9. Normative References
>
>    [PWE3-CRTL] "Transport of Layer 2 Frames Over MPLS", Martini, L., et al.,
>        draft-ietf-pwe3-control-protocol-09.txt, ( work in progress ), September 2004.
>
>    [PWE3-ARCH] "PWE3 Architecture" Bryant, et al., draft-ietf-pwe3-arch-08.txt
>        ( work in progress ), March 2003.

I don't think the ARCH document shoudl be normative. Does it need to
be? For what reason is it normative?

[Note]: '2004-12-17: AD re-review raises some additional questions. see
comments in log. Also, this document needs to be advanced together as
part of a 4-doc bundle that includes:
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 14:29:44 -0400
Subject: AD review of draft-ietf-pwe3-ethernet-encap-07.txt

Hi. Here's my review of this document. My guess is we should probably
rev once more before IETF LC.

But I'd specifically also like to first understand my confusion about
raw vs. service delimiting modes.

Thomas

2004-08-27: review of -07 (WG says advance)

section 2 (IPR) would be better off at end of document.

>    The "NSP" function includes frame processing that is required for the

define or at least expand NSP at first use...

>    processing required by control word is performed, and the control

s/by/by the/

>    When the PE receives an ethernet frame from a CE, and the frame has a
>    VLAN tag, we can distinguish two cases:
>
>
>      1. The tag is "service-delimiting".  This means that the tag was
>          placed on the frame by some piece of provider-operated
>          equipment, and the tag is used by the provider to distinguish
>          the traffic.  For example, LANs from different customers might
>          be attached to the same provider switch, which applies VLAN
>          tags to distinguish one customer's traffic from another's, and
>          then forwards the frames to the PE.

I'm confused here. The CE added the tag, how can it be service
delimiting? Shouldn't service delimiting tags ONLY be added by PE?

I don't fully understand the difference between case 1 and 2 here.

Isn't service delimiting vs. raw mode just something the two PE edge
devices have to agree on? Why is the CE device involved?

>    As specified in [PWE3-ARCH], an implementation SHOULD support the
>    generic and specific PW MIB modules for PW set-up and monitoring.
>    Other mechanisms for PW set up (command line interface for example)
>    MAY be supported.

Is this implying a normative reference to these documents? My read is
yes.

>    When carrying Ethernet over an IP or MPLS backbone sequentiality may

s/backbone/backbone, /

>    When carrying Ethernet over an IP or MPLS backbone sequentiality may
>    need to be preserved.  The OPTIONAL control word defined here
>    addresses this requirement.  Implementations MUST support sending no
>    control word, and MAY support sending a control word.

I'm surprised at this MAY. It means that compliant implementations
don't need to support sequenced delivery. That seems like a bug if
this spec is to emulate ethernet.

Note: seems like for interoperability, we want MUST implement, but
operations determines whether to enable/use. If it's not implemented,
operator does not have the choice to enable...

(Or is that what the words are trying to say?)

>    In the above diagram the first 4 bits MUST be set to 0 to indicate PW
>    data.  The rest of the first 16 bits are reserved for future use.
>    They MUST be set to 0 when transmitting, and MUST be ignored upon
>    receipt.

should we reference the other document now instead? (Note that the
formats of the two control words is a bit different...)

16-bit sequence number doesn't seem big enough for today and future
networks... You will still get out-of-order packets. Especially over
IP.

>    If the transmitting router PE1 does not support sequence number
>    processing, then the sequence number field in the control word MUST
>    be set to 0.

If it is not supported, than the entire control word seems like it
wouldn't be implemented. Why send one with a 0 up front? This should
be negotiated out of band... (Indeed, I though that was required)

>      - if the sequence number on the frame is 0, then the frame passes
>        the sequence number check

Funny wording. It doesn't pass the check at all; it doesn't use a
sequence number...

>    If a router PE2 does not support receive sequence number processing,
>    then the sequence number field MAY be ignored.

This seems bad. Better to have the PW just fail, and require that it
be configured correctly. Otherwise, hard-to-diagnose operational
errors may occur.

References need to be split into normative/informative.

No IANA considerations? What about allocation of the reserved bits in
the control word?

There are too many authors in the author section. Please split up into
editor/author/contributer sections as appropriate.