Subject: Minor comments regarding draft-ietf-pwe3-control-protocol-12.txt

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 26 Oct 2004 10:15:47 +0200

Luca and all,
I am now reading draft-ietf-pwe3-control-protocol-12.txt and it looks really
good.
However, I have some minor comments that I would like to present
for your consideration. Hopefully you will find some of them
useful.

1. The last para on Page 5 says:

<quote>
   The following two figures describe the reference models which are
   derived from [ARCH] to support the Ethernet PW emulated services.
<end quote>

However, Figures 1 and 2 (to which this text presumably refers)
do not mention Ethernet (or any specific Layer 2) at all. Indeed,
even the reference to "Layer 2 services" in Fig.2 seems over-restrictive,
as it creates an, IMHO, wrong impression that the protocol stack it
describes does not apply to TDM and/or SONET PWs.

2. The text on page 7 says:

<quote>

   So when PE1 sends a layer 2 PDU to PE2, it first pushes a PW label on
   its label stack, thereby creating an MPLS packet.  It then (if PE1 is
   not adjacent to PE2) encapsulates that MPLS packet in a PSN tunnel
   header.  (If the PSN tunnel is an LSP, this is just a matter of
   pushing on a second label.)  The PW label is not visible again until
   the MPLS packet reaches PE2. PE2's disposition of the packet is based
   on the PW label.
<end quote>

IMHO the text, as written, may create a wrong impression that pushing
a stack of several labels representing the PSN tunnel is not considered.

3. The next para on the same page says:

<quote>

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

   The following questions arise:

   a) The text uses IETF capitalized "MUST" when requesting allocation of
the PW
      from the per-platform label space and non-capitalized "must" when
      requesting the PW label at the bottom of the label stack. This may
create
      an impression that the bottom-of-stack clause is not a requirement
      of this protocol which is probably wrong.
   b) Please note taht if the "bottom-of-stack" clause were made a
requirement, 
      (by using IETF capitalized "MUST") it would preclude using Y.1711 
      as the PW OAM method. While I do not have any problems with such a 
      limitation, I believe that an explicit clarification would be
beneficial. 
   c) Per-platform allocation of PW labels has been questioned too many
      times by too many people on this list to justify a few more words 
      explaining why this requirement is necessary (or why the alternative
does not 
      make sense). In fact, most of these words are already there, but IMHO
it 
      would be nice to dot all i's and cross all t's.

4. Section 4.1 "Frame Relay"
   a) Reference [ITUQ] points to ITU-T Recommendation Q.933. Hence explicit
      mentioning Q.933 in the text

<quote>
   ...
   particular DLCI, as defined in [ITUQ] Q.933 Annex A.5 sited in IA
   FRF1.1, 
   ...
<end quote>

   looks unncesssary. Please note also that FRF1.1 is mentioned but is not
   a reference.
   b) FR LMI can report both failure and deletion of a specific DLCI
      (as two different condistions), but the text does not specify
      any difference in the processing, leaving open the following
      question (that, to the best of my memory, has been discussed
      on the list): should the PE that has been notified about deletion
      of a DLCI withdraw the associated PW label?
   c) This section does not mention FR Port Mode PWs defined in [FRAME].

5. The text describing PW ID on page 14 does not contain an explicit
specification
   of the PW ID scope. This issue has been raised on this list, and, to the
   best of my recollections, the consensus was that PW ID value MUST be
   unique per PW Type per given pair of PEs. IMHO it is worth explicitly
   saying that in the spec.
      
6. Section 5.2 "The Generalized PW ID FEC Element"
   Please note that the following text:
<quote>
   The "Generalized ID FEC Element" is FEC type 129 (provisionally,
   subject to assignment by IANA).
<end quote>

   does not match any wording used when describing FEC type 128.
   Please note also that both descriptions refer to [note1] that
   states:

<quote>
   [note1] FEC element type 128,129 is pending IANA approval.
<end quote>

   Hence, IMHO, specifically mentioning that FEC type 129 is
   used provsionally is unncessary.

7. On page 17, the fielsd AGI, SAII and TAII in the (unnamed)
   diagram actually refer to single-octet AGI, SAII and TAII
   type identifiers. IMHO it would be useful to update the diagram
   accordingly. 
   Please note also that the number "129" appears directly in the
   diagram describing the Generlized PW ID FEC, while the matching
   field in the diagram describing the PW ID FEC is marked as
   "PW tlv".

   And it would be helpful to cintinue numbering of the diagrams
   through the entire document (it stops at Figure 2, and the remaining
   diagrams are nameless:-)

8. The following two text fragments seem to be in contradiction to me:

<quote 1>
5.2.1. Attachment Identifiers
... snipped ...

   The association of two unidirectional LSPs into a single
   bidirectional pseudowire depends on the SAI and the TAI.  Each
   application and/or provisioning model which uses the Generalized ID
   FEC element must specify the rules for performing this association.
<end quote 1>

   vs.

<quote 2>
5.2.3. Signaling Procedures
... snipped ...

   If PE2 decides to accept the Label Mapping message, then it has to
   make sure that an LSP is set up in the opposite (PE1-->PE2)
   direction.  If it has already signaled for the corresponding LSP in
   that direction, nothing more need be done.  Otherwise, it must
   initiate such signaling by sending a Label Mapping message to PE1.
   This is very similar to the Label Mapping message PE2 received, but
   with the SAI and TAI reversed.

   Thus a bidirectional PW consists of two LSPs, where the FEC of one is
   the "reverse" of the FEC of the other.
<end quote 2>

   The text in Quote 2 looks to me like an explicit specification of
   an (application-independent) pairing rule which, according to Quote 1,
   is left for specific applications using the Generalized PW ID FEC.

9. [ITUG] is listed as one of informative references but never used.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked]
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)