Skip to main content

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

Yes

(Mark Townsley)

No Objection

(Bill Fenner)
(David Kessens)
(Jon Peterson)
(Margaret Cullen)
(Scott Hollenbeck)
(Ted Hardie)

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

Mark Townsley Former IESG member
Yes
Yes () Unknown

                            
Alex Zinin Former IESG member
No Objection
No Objection (2005-08-18) Unknown
> 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"?
Allison Mankin Former IESG member
(was Discuss) No Objection
No Objection (2005-08-18) Unknown
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.
Bert Wijnen Former IESG member
No Objection
No Objection (2005-08-18) Unknown
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.
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
Brian Carpenter Former IESG member
No Objection
No Objection (2005-08-16) Unknown
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.
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Margaret Cullen Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2005-08-17) Unknown
  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"
Sam Hartman Former IESG member
No Objection
No Objection (2005-08-18) Unknown
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.
Scott Hollenbeck Former IESG member
No Objection
No Objection () Unknown

                            
Ted Hardie Former IESG member
No Objection
No Objection () Unknown