Subject: [Fwd: Re: PWE3 drafts]

From: Luca Martini <[email-masked]>
Date: Tue, 15 Feb 2005 16:58:46 -0700

Wg,

Here are the AD review comments , and my answers.
Note that I also removed the text duplication in the IANA section of the 
control protocol document. ( also present in the iana allocation document )

Luca

Thomas Narten wrote:

[snip]
>
>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.
>
>
it was presented to them 4 years ago and we had no objections.... If you 
tell me how to get the official sign off I will pursue it.

>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.
>
>
They are in sync ( no allocation information is duplicated ). I put the 
creation of the new IANA PWE3 specific registries  in the control 
document for completeness. ( I hate documents that are hard to read , 
and point to too many references ... )
The only direct allocation suggestion to IANA are the LDP related codes.
Note that there are no PWE3 allocations made in the control document. 
PWE3 allocation are in the "IANA Allocations for pseudo Wire Edge to 
Edge Emulation  (PWE3)" document only.

>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 WG did not express any interest in this section. So myself and Eric 
wrote what is in the draft right now.
I will make appropriate changes, as you suggest.

>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 pretty simple)
>
>
This was more text there , but got pulled. It is still in the nroff 
source , I can easily put it back.

>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.
>
>
Actually the way it is subdivided right now fits several documents. The 
encapsulation documents do not have setup/control protocol related 
details in them as they are used by L2VPN WG documents that create PW 
services using BGP and no LDP signaling protocol.
I agree that we could  pull the text that references the encapsulation 
document, and move the reference to informative.
( would an informative reference block this document ? )
Still I believe that the control protocol details of the service belong 
in this document.

We need something that glues this together as follows:

            control doc.             atm encap doc             control 
doc       iana doc.
"ATM AAL5 SDU VCC Transport" -> encapsulation ATM SDU mode -> Pw type 
description ->PW type  0x0002

>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
>shouldn'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")?
>
>
PSN tunnels == MPLS LSP == MPLS tunnels
no, this document is about setting up PWs. MPLS tunnels get setup with 
RSVP-TE , or LDP or ....

Which one do you want me to use ?

>>   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-point above.
>
>
ID nits script barfs on it. If stewart stops complaining ;-) I'll put it 
back ...

>>   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?
>
>
Labels can be unique per interface , or per platform ( maybe per-PE is 
better ? )

>>   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...)
>
>
yes, my mistake.

>>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?
>
>
Yes. To build the PW service the frame-relay document needs to be normative.

>Also, for "the PE MUST communicate...", what is the actual procedure
>for doing that and where is it defined?
>
>
In this document , in the PW status TLV/message section.

>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.
>
>
Let discuss this on a conf call. I'm not sure I understand the question.

>>   mode allows for concatenation ( grouping ) of multiple cells into a
>>
>
>In several places, you have parenthesis with unneeded spaces.
>
>
>
Ha , editorial preferences ... I'll fix it.

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

>>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?
>
>
I think that this should be the last document published , or just go 
together with all the other encap documents.

>>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. 
>
there are 2 modes defined in the ethernet draft , this just select 
tagged mode encapsulation for this PW type.

>Not sure what the second sentence refers to when
>saying "outlined above".
>
>
indeed , a long forgotten remnant for the draft-martini ....

"outlined above"==[ETH] reference
I'll fix it.

>>   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.
>
ok, will fix it.

>
>>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?
>
>
PPP/HDLC PWs , it is actually one of the documents in your queue to read.
( or at least it should be )

>>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?
>
>
This is the IP PW mode that we discussed. We "switch" IP packet in a PW, 
with just the IP header...
Note that this is not a PW type  that I came up with ....

>>   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?
>
>
Ha , a forgotten reference ... it's should be [LDP, section 2.4.2 and 2.5].

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

>>   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...
>
>
nowhere . This is actually a bug in the document I realized only a few 
weeks ago that we need to create a registry for these.
On this subject.... I will move all registry creation to the iana 
document and just reference it here.

>>   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?)
>
>
second MAY is broken. I will change it to a MUST.
the first MAY in my opinion is also broken ... the problem is that we 
MUST implement receiving this TLV but then we say we say it MAY be omitted.
I will just remove the sentence. "If the PW Grouping ID is not going to 
be used for wild card messages, it MAY be omitted."

>>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?
>
>
yes. All implementations I know of , we not use that status TLV 
messaging yet.

>>     - Interface MTU
>>
>
>This is a new "Parameter 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.
>
>
yes the length is actually give n in the text, along with the description...
the length should probably not be in the IANA anyway.... IANA does not 
allocate storage ;-)

>>     - 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?
>
>
This needs to remain here so the the TDM PW document can be used with 
other control protocols, and does not get a normative reference back to 
here.

>General: it would be good to list which PWs a Parameter ID is relevant
>to.
>
>
Yes we do , it's listed by PW type.

>
>>     - 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).
>
>
another miss of my regular expression search and replace ;-)
will fix it.

>>     - 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 ...
>
>
>
or the interface ..... ;-) the point of interface parameters is to make 
sure that the PW endpoints are compatible so that we can actually 
establish a PW without doing any kind of Interworking function in the PW.

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

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

>>   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 achieving the same
>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??)
>
>
So this feature is kind of controversial. The reason for it is to have 
quick status messaging in case a port or hole card goes down.
However it has not been popular in implementations. We would like to 
leave it in , and remove it in the standards process if it will never 
get implemented.

>note: this document really would benefit from a one page overview of
>what the protocol does.
>
>
Ha we had that , but it was removed . I could write something back in 
the beginning of the document.
Let discuss this on the phone

>>   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"????
>
>
== input

>ditto for "disposition router".
>
>
== output
oops - cisco terminology
will change it.

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

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

>>   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".
>
I should not change the rfc3036 definition , ( which I think already 
specifies the MD5 Key )
but the MAY should be a may instead ...

ok ?