Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)
RFC 4447

PROTO Questionairre follows:

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

  Yes

2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

  Yes. In addition rteview in PWE3 WG the draft has been reviewed
  by MPLS WG and all of their recommendations incorporated into
  the text.

3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

  No

4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.

  No

5) How solid is the WG consensus behind this document?  Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with
  it?

  There is strong consensus

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

  No

7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

  Yes

8) Does the document a) split references into normative/informative,
  and b) are there normative references to IDs, where the IDs are not
  also ready for advancement or are otherwise in an unclear state?
  (Note: the RFC editor will not publish an RFC with normative
  references to IDs, it will delay publication until all such IDs are
  also ready for publication as RFCs.)

  a) yes

  b) It depends on draft-ietf-pwe3-iana-allocation-08.txt, which
  may be controvertial in the IESG.

9) For Standards Track and BCP documents, the IESG approval
  announcement includes a writeup section with the following
  sections:

  - Technical Summary

  This document describes how to use LDP to establish and maintain
  a pseudowire over an MPLS PSN. This document describes the
  extensions to th eLDP protocol that are needed.


  - Working Group Summary

  This work has been thoroughly analysed by the working group
  and there is consensus for the design. It has also been reviewed
  by MPLS WG and all of their recommendations have been
  incorporated.

  - Protocol Quality

  This specification is well known in the industry and
  implementations exist.

Note to RFC Editor

1. Please add an informative reference to draft-ietf-pwe3-cw-05.txt in section
6 when the Control Word is first mentioned.

Old Text:

The bit (C) is used to flag the presence of a control word as follows:

New Text:

The bit (C) is used to flag the presence of a Control Word [CW] as follows:

New Text in Informative References section:

[CW] "PWE3 Control Word for use over an MPLS PSN", S. Bryant,
    G. Swallow, D. McPherson, draft-ietf-pwe3-cw-01.txt, ( work in
    progress ), December 2004.


2. Please remove section 4 in its entirety (and adjust numbering of other
sections appropriately)

3. Please add a normative reference to RFC 2119 and cite it in section 1.

4. In the following text on Page 22:

  As mentioned above, as MPLS enabled network, should not accept MPLS
  packets from its external interfaces (i.e. interfaces to CE devices
  or to other providers' networks) unless the top label of the packet
  was legitimately distributed to the system from which the packet is
  being received.

Please change "should not" to "SHOULD NOT"

5. It was noted also that there are misspellings and typos in the document.

[Ballot discuss]
This document contains the following section:

4. Details Specific to Particular Emulated Services

4.1. IP Layer2 Transport

  This mode carries IP packets over a Pseudo-Wire. The encapsulation
  used is according to [RFC3032]. The PW control word MAY be inserted
  between the MPLS label stack and the IP payload. The encapsulation of
  the IP packets for forwarding on the attachment circuit is
  implementation specific, part of the NSP function [RFC3985], and is
  outside the scope of this document.

Why does this section say that the PW control word "MAY be inserted" when there is another section that describes how one would decide whether or not to include the PW control word?  Is this somehow different than other encapsulations?

Also, I am concerned about whether or not this specification is complete-enough to be implemented, as  it doesn't explain what the control word would contain and/or what it would be used for.  I understand that it is one component in an architecture, but the document doesn't include a reference to that architecture and as-is there seem to be some terms used in this document (most notably the control word) that are not really explained/defined.

IANA Comments:
Upon approval of this document the IANA will register 3 new LDP TLV TYPEs,
8 new LDP Status Codes, and 2 new FEC Type Name Spaces.
These registrations will be placed in the registries found at the following:
http://www.iana.org/assignments/ldp-namespaces

[Ballot discuss]
This document contains the following section:

4. Details Specific to Particular Emulated Services

4.1. IP Layer2 Transport

  This mode carries IP packets over a Pseudo-Wire. The encapsulation
  used is according to [RFC3032]. The PW control word MAY be inserted
  between the MPLS label stack and the IP payload. The encapsulation of
  the IP packets for forwarding on the attachment circuit is
  implementation specific, part of the NSP function [RFC3985], and is
  outside the scope of this document.

Why does this section say that the PW control word "MAY be inserted" when there is another section that describes how one would decide whether or not to include the PW control word?  Is this somehow different than other encapsulations?

Also, is there a mechanism wherby the insertion of the PW control word would be taken into account in the MTU of the PWE link?  If a PWE endpoint needs to add the PW control word to an MTU-sized packet, what happens?

I realize that I could probably figure this out by reading all of the references, and I thought of defering this document for that purpose.  But, the next telechat is 4 weeks away, so I thought that it might be preferable to discuss this first.

[Ballot comment]
Quite a few typos, e.g.

  Time Dividion Multiplexed

and two errors in the first line quoted below.

(From review by Spencer Dawkins)

One question on page 22 - in this sentence,

  As mentioned above, as MPLS enabled network, should not accept MPLS
  packets from its external interfaces (i.e. interfaces to CE devices
  or to other providers' networks) unless the top label of the packet
  was legitimately distributed to the system from which the packet is
  being received.

Should "should not" be SHOULD NOT? (and is there ever a reasonable justification for accepting them)?

[Ballot comment]
(From review by Spencer Dawkins)

One question on page 22 - in this sentence,

As mentioned above, as MPLS enabled network, should not accept MPLS
packets from its external interfaces (i.e. interfaces to CE devices
or to other providers' networks) unless the top label of the packet
was legitimately distributed to the system from which the packet is
being received.

Should "should not" be SHOULD NOT? (and is there ever a reasonable justification for accepting them)?

[Note]: '

-------- Original Message --------
Subject: PWE3 control draft review request
Date: Tue, 19 Apr 2005 20:47:47 +0100
From: Stewart Bryant
To: mpls@ietf.org, swallow@cisco.com, loa@pi.se,        Danny McPherson ,        "W. Mark Townsley" , zinin@psg.com,        fenner@research.att.com

The following draft:

Pseudowire Setup and Maintenance using LDP
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-16.txt

Extends LDP to allow it to set up pseudowires.

The PWE3 WG Chairs requests that the MPLS WG review this
draft.

Please sent comments by COB Wednesday 4th May.

Thank you for your help.

Stewart

' added by Mark Townsley

[Note]: 'Subject: Re: pwe3 docs...
Date: Wed, 23 Mar 2005 15:44:39 -0700
From: Luca Martini
To: W. Mark Townsley

> draft-ietf-pwe3-control-protocol

Need to change TAII,SAII,AGI to AII type , and AGI Type. Also need to re-word the security section to basically say  to use all existing security measures implemented in LDP/MPLS and reference the appropriate RFCs  instead of duplicating the text here.
' added by Mark Townsley

[Note]: 'Discussions with one of the authors (Luca Martini) indicate that a few more edits are necessary for this spec. Will move to Revised ID Needed once I get more details on what is needed (email sent asking for details).' added by Mark Townsley

[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

From: Thomas Narten
To: Stewart Bryant
cc: "'danny@tcb.net'" , Luca Martini
Date: Thu, 13 Jan 2005 11:27:37 -0500
Subject: Re: PWE3 drafts

> I have seen your comments on Ethernet and Luca is enguaged in
> addressing them. As I recall a phone call has been proposed, but not
> set up yet.

Sorry for not responding sooner. I wanted to review the other docs
first, before we had a call.

> Please can we have your comments on control (which could usefully be
> discussed in the same conf call) and on TDM.

I've reviewed the document. Here are my comments on it:

High-level comments/questions

Uses LDP; has the (appropriate) LDP WG looked at this? Would this be
MPLS? They need to sign off on this document, since it uses LDP.

I think draft-ietf-pwe3-iana-allocation-07.txt has been superceded by
events. Since control is now going forward, we don't need the separate
document. Indeed, the control document still has its own IANA
considerations (which is presumably old/incorrect). Get one version,
and I suspect it might as well just be in the control document.

The security section is week. Bottom line, what security is mandatory
to implement, should operators want to turn it on. I see only a
MAY. IESG will surely want a "MUST implement (optional to use)" in the
spec.

The document really needs a short overview of how the setup protocol
works. We can probably hammer this out pretty quickly (i.e., the
protocol seems to be prety simple)

There are a bunch of normative references to other documents that
aren't ready, and we probably _don't_ want the control document
dependent on them. In an ideal world, I would expect:

  1) a control document that describes how to set up PWs

  2) PW-specific documents, that explain the details specific to a
    type of PW. That would include encapsulation, _plus_ any service
    specific requirements.

What I think has been done is have PW-specific encapsulation drafts,
but put some of the PW-service specific stuff in the control
document. That doesn't seem right. I.e, the control  document
shoudln't need to have a normative reference to the TDM spec saying
how one does things. My assumption is that we should just move some
text that is in the control documents into the appropriate PW document.

Detailed comments:

>    is an MPLS label. Thus the packets which are transmitted from one end
>    of the pseudowire to the other are MPLS packets must be transmitted
>    through a PSN tunnel, however if the pseudowire endpoints are
>    immediately adjacent, the PSN tunnel may not be necessary. Any sort

doesn't parse.

>    sort of tunnel which can carry MPLS packets.  Procedures for setting
>    up and maintaining the PSN tunnels are outside the scope of this
>    document.

do you mean "for setting up ... other than MPLS tunnels ..." ???
I.e., isn't this document about LDP setting up MPLS tunnels (even if
you don't call them "tunnels")?

>    This document deals only with the setup and maintenance of point to
>    point pseudowires.  Neither point to multipoint nor multipoint to
>    point pseudowires are discussed.
>

should be point-to-piont above.

>    Note that the PW label must always be at the bottom of the packet's
>    label stack and labels MUST be allocated from the per-platform label
>    space.

what does "per-platform" mean?

>    In addition to the protocol specified herein, static assignment of PW
>    labels MAY be used, and implementations of this protocol SHOULD
>    provide support for static assignment.

lower case MAY? (Its not an implementation MAY, but a user MAY. The
SHOULD is the advice to the implementor...)

> 4.1. Frame Relay
>
>    When emulating a frame relay service, the Frame Relay PDUs are
>    encapsulated according to the procedures defined in [FRAME]. The PE
>    MUST provide Frame Relay PVC status signaling to the Frame Relay
>    network. If the PE detects a service-affecting condition for a
>    particular DLCI, as defined in [ITUQ] Q.933 Annex A.5 sited in IA
>    FRF1.1, the PE MUST communicate to the remote PE the status of the PW
>    corresponds to the frame relay DLCI. The Egress PE SHOULD generate
>    the corresponding errors and alarms as defined in [ITUQ] on the
>    egress Frame relay PVC. There are two frame relay flags to control
>    word bit mappings described in [FRAME]. The legacy bit ordering
>    scheme will be used for a PW of type "Frame Relay DLCI ( Martini Mode
>    )", while the new bit ordering scheme will be used for a PW of type
>    "Frame Relay DLCI".

Is the reference to FRAME normative?

Also, for "the PE MUST communicate...", what is the actual procedure
for doing that and where is it defined?

What would maybe help here is to talk about "ports" (?) so one can
talk about  (say for PE1) which link/port is the FR one and which is
the PW, and then indicate on which port/link one is talking about.

>    mode allows for concatenation ( grouping ) of multiple cells into a

In several places, you have parenthesis with unneeed spaces.


>    OPTIONAL for transmission at the ingress PE, PE1. If the Egress PE
>    PE2 supports cell concatenation the ingress PE, PE1, MUST only

s/concatenation/concatenation,/

> 4.2.4. OAM Cell Support
>
>    OAM cells MAY be transported on the PW LSP. When the PE is operating
>    in AAL5 CPCS-SDU transport mode if it does not support transport of
>    ATM cells, the PE MUST discard incoming MPLS frames on an ATM PW LSP
>    that contain a PW label with the T bit set [ATM]. When operating in
>    AAL5 SDU transport mode an PE that supports transport of OAM cells
>    using the T bit defined in [ATM], or an PE operating in any of the
>    cell transport modes MUST follow the procedures outlined in [ATM] in
>    addition to the applicable procedures specified in [ITUG].

Note: I'm a bit concerned that the above language really is making
normative references to the ATM document. Is that desired/necessary?
This may not be a problem, but it also means that this document can't
be published until the other ones are done.

Shouldn't much of this sort of text be in the ATM-specific document?

> 4.3. Ethernet Tagged Mode
>
>    The Ethernet frame will be encapsulated according to the procedures
>    in [ETH] tagged mode. It should be noted that if the VLAN identifier
>    is modified by the egress PE, according to the procedures outlined
>    above, 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.

Again, the above sure sounds like PWE3 Ethernet requires something
w.r.t. tagging. Not sure what the second sentence refers to when
saying "outlined above".

>    Ethernet input port, or the port is administratively disabled, the PE
>    MUST send a corresponding PW status notification message.

Send it where? (presumably the other PE, but better to be explicit.

> 4.5. HDLC and PPP
>
>    HDLC and PPP frames are encapsulated according to the procedures in
>    [PPPHDLC]. If the MPLS edge PE detects that the physical link has
>    failed, or the port is administratively disabled, it MUST send a PW
>    status notification message that corresponds to the HDLC or PPP PW.

Is this section still needed? i.e., what document is this reference
to?

> 4.6. IP Layer2 Transport
>
>    This mode carries IP packets over a Pseudo-Wire. The encapsulation
>    used is according to [RFC3032]. The PW control word MAY be inserted
>    between the MPLS stack and the IP payload. IP interworking is
>    implementation specific, part of the NSP function [ARCH], and is
>    outside the scope of this document.
>

What is this?

>    The PW label bindings are distributed using the LDP downstream
>    unsolicited mode described in [LDP]. The PEs will establish an LDP
>    session using the Extended Discovery mechanism described in [1,
>    section 2.4.2 and 2.5].

What is this reference?

>    The Generalized ID FEC Element not contain anything corresponding to
>    the "group id" of the PWid FEC element.  The functionality of the

doesn't parse

>    This document does not specify the SAII,TAII,AGI type field values;
>    specification of the type field values to use for a particular
>    application is part of the specification of that application. IANA
>    will assign these values based on IETF consensus.

Where are these defined, for say, ethernet? Also, move the last
sentence to an IANA considerations section...

>    remote PEs MUST implement support for wildcard messages. If the PW
>    Grouping ID is not going to be used for wild card messages, it MAY be
>    omitted. This TLV MAY only be used when sending the Generalized PW ID
>    FEC.

Both MAYs are suspect. The last one for sure. (are these
implementation MAYs?)

> 5.3.1. Use of Label Mappings.
>
>    The PEs MUST send PW label mapping messages to their peers as soon as
>    the PW is configured and administratively enabled, regardless of the
>    CE-facing interface state. The PW label should not be withdrawn
>    unless the user administratively configures the CE-facing interface
>    down (or the PW configuration is deleted entirely). Using the
>    procedures outlined in this section a simple label withdraw method
>    MAY also be supported as a primitive means of signaling PW status. It
>    is strongly RECOMMENDED that the PW status signaling procedures below
>    be fully implemented. In any case if the Label mapping is not
>    available the PW MUST be considered in the down state.

Hmm. Is all of 5.3 really optional (i.e, just SHOULD?) why not just
MUST and be done with it? Is this for backwards compatability or
something?

>      - Interface MTU

THis is a new "Paraemter ID". This document should say that
explicitely, e.g., by saying the "Parameter ID is 1", and its symbolic
value is "Interface MTU". Might as well give the length here
too. I.e., some of what you have in the IANA considerations section
should just be here.

Same comment applies to all the Parameter ID values.

>      - Payload Bytes
>
>        A 2 octet value indicating the number of TDM payload octets
>        contained in all packets on the CEM stream, from 48 to 1,023
>        octets. All of the packets in a given CEM stream have the same
>        number of payload bytes. Note that there is a possibility that
>        the packet size may exceed the SPE size in the case of an STS-1
>        SPE, which could cause two pointers to be needed in the CEM
>        header, since the payload may contain two J1 bytes for
>        consecutive SPEs. For this reason, the number of payload bytes
>        must be less than or equal to 783 for STS-1 SPEs.

So, is this only relevant to the TDM PW? If so, wouldn't it be better
to define this in the document that has TDM specific things in it?

General: it would be good to list which PWs a Parameter ID is relevant
to.


>      - CEP Options.
>
>        An optional 16 Bit value of CEM Flags. See [8] for the definition
>        of the bit values.

what is [8] (indeed, fix all references with numeric citations).

>      - Requested VLAN ID.
>
>        An Optional 16 bit value indicating the requested VLAN ID. This
>        parameter MUST be used by a PE that is incapable of rewriting the
>        802.1Q ethernet VLAN tag on output. If the ingress PE receives
>        this request, it MUST rewrite the VLAN ID tag at the input to
>        match the requested VLAN ID. If this is not possible, and the
>        VLAN ID does not already match the configured ingress VLAN ID,
>        the PW MUST not be enabled. This parameter is applicable only to
>        PW type 4.

sure sounds like munging VLAN tags are a part of PWE ...


>        An optional 16 bit value indicating the lenght of the frame-relay

spelling.

>    As mentioned above the Group ID field of the PWid FEC element, or the

s/above/above,/

>    As mentioned above the Group ID field of the PWid FEC element, or the
>    PW Grouping ID TLV used with the Generalized ID FEC element, can be
>    used to withdraw all PW labels associated with a particular PW group.
>    This procedure is OPTIONAL, and if it is implemented the LDP label
>    withdraw message should be as follows: If the PWid FEC element is
>    used, the PW information length field is set to 0, the PW ID field is
>    not present, and the interface parameters field is not present. If
>    the Generalized FEC element is used, the AGI, SAII, and TAII are not
>    present,the PW information length field is set to 0, the PW Grouping
>    ID TLV is included, and the Interface Parameters TLV is omitted. For
>    the purpose of this document this is called the "wild card withdraw
>    procedure", and all PEs implementing this design are REQUIRED to
>    accept such withdrawn message, but are not required to send it. Note
>    that the PW Grouping ID TLV only applies to PW using the Generalized
>    ID FEC element, while the Group ID only applies to PWid FEC element.

please clarify what is optional. Is it optional to implement on the
sender side? (well, OK, but that isn't something this document needs
to say, if there is an alternate way of acheiving the samet
results). Is it Required that everyone implement processing the
receipt of the message? (and if so, why is it necessary to make it
optional to send??)

note: this document really would benefit from a one page overview of
what the protocol does.

>    release message MUST include only the group ID, or Grouping ID TLV. A
>    Label Release message initiated from the imposition router must
>    always include the PW ID.

what is an "imposition router"????

ditto for "disposition router".


>    This document uses two new FEC element types, 128 and 129. IANA
>    already maintains a registry of values of the "FEC Type Name Space"
>    for the Label Distribution Protocol (LDP RFC3036). In that registry,
>    values in the range 128-191 are assignable on a First Come, First
>    Served basis. IANA should assign values 128 and 129 from that space
>    as specified in this document.

In the IANA considerations section, please remove all wording saying
what the assignment policy is you are asking for a code point
from. IANA knows  what policy is in effect (and it might change
later...). Just say what namespace and the value needed. That
suffices.

> 7.4. Pseudowire Type
>
>    IANA needs to set up a registry of "Pseudowire Type".  These are 15-
>

This text is duplicated in the other iana document...

Note: I didn't read these carefully. Let's first figure out which text
is the definitive text...

>    When a MPLS PSN is used to provide pseudowire service, there is a
>    perception that security MUST be at least equal to the currently

"there is a perception" is pretty poor wording, as it can easily be
read to mean the authors don't really think security is important.

>    The three main security problem faced when using an MPLS network to

s/problem/problems/

>    transport PWs are spoofing, alteration, and inspection. First there
>    is a possibility that the PW receive endpoint will get a PDU which
>    appears to be from the PE encapsulating the PW into the PSN, but
>    which was not actually transmitted by the PE originating the PW.

"PW receive endpoint"?? can this be reworded?

>    For a greater degree of security, the LDP MD5 authentication key
>    option, as described in section 2.9 of RFC 3036, MAY be used.  This

seems like this should be "MUST be implemented, may be used by
operator".