Subject: Questions and comments regarding draft-martini-pwe3-MH-PW-require ments-01.txt

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 8 Mar 2005 11:56:02 +0200

Hi all,

I have read the updated MH-PW Requirements draft and it looks
as a substantial improvement from the previous version.

At the same time I'd like to present some questions and comments
to the proposed text. 

1. Can the PW Type Change Across a MH-PW?
========================================
Section 3.2 "Architecture" states (in the explanation
to Figure 2) that:

<quote>
	PW segments of the same MS-PW (e.g., PW1 and PW3) 
	MAY be of the same PW type or different type
<end quote>

It is not clear to me which application scenarios would
benefit from splicing of PW segments of different PW 
types. What's more, item (i) in Section 6.1 states that

<quote>
      S-PEs MAY only support switching PWs of the same PW type. In
      this case, the PW type is transparent to the S-PE in the
      forwarding plane, except for functions needed to provide for
      interworking between different PSN technologies.
<end quote>

This statement strengthens the impression that splicing
PW segments of different types is not really important for
the operators (in addition to being an implementor's nightmare).

So why not to kill this option from the very beginning?

2. Can the PW Encapsulation Change Across a MH-PW?
=================================================
Section 6.1 also discusses the possibility of changing the
PW encapsultion in the S-PE while keeping PW Type intact.
I am not sure I understand the intention behind this requirement;
IMHO some examples would be really benefitial for the reader.

One possible example that comes to my mind is an ATM Cell stream
PW in many-to-one mode that starts mapping a single cell to packet
but changes this encpaulstion somewhere in the middle by packing
multiple cells into a single packet. At the same time, such a
change would mean that an S-PE would not be transparent to the 
PW Type in the data plane (see the quote from Section 6.1 above).

3. Are PW Segments Single-Hop PWs?
=================================
The last requirement in Section 6.1 states that "MS-PW are composed 
of SS-PWs". While I do not have any issues with the conclusion
(the same set of S-PEs must be used in both directions), I still think
that MS-PW are composed of PW segments, not of SS-PWs. One reason 
for that is identification of the PW Segment endpoint vs. identification
of the (MH- or SH-) PW end point as discussed in another thread on this
list.

Please note that equivalence between SS-PWs and PW segments is
also mentioned in Section 7, item (vi).

4. Application Scenarios and Reasons to Use MH-PW
=================================================
Reading Section 5 "Use Cases" I have come to the conclusion that
the draft considers several different problems that hopefully
can be resolved by using MH-PWs:

(1) Inability to set up a single end-to-end PSN tunnel with the required
    properties. Inter-domain PWs look to me like one special scenario 
    where this problem can be encountered

(2) Inability to set up an end-to-end control connection. It would be nice
    to understand the application scenarios where this problem can be
    encounterd as, IMHO, none are present in the current text

(3) Scalability of the full mesh of end-to-end PSN tunnels. Please
    note that this problem is different from (1) above  since you can 
    set up each specific end-to-end PSN tunnel, but cannot maintain 
    all the needed tunnels simultaneously. The application scenario
    where this problem can be encountered and possible alternatives 
    to using MH-PWs are discussed in the draft

(4) Scalability of the full mesh of control connections (e.g.,
    because you must maintain too many security relashionships).
    Again, this is different from (2) above since you can set up
    any specific control connection but cannot maintain all of them
    simultaneously. And it is distinct from (3) if, say, a
    full mesh of end-to-end PSN tunnels is provided (directly
    or indirectly) by IP routing. 

IMHO classification of problems can be useful because certain application 
scenarios can encounter several of them. IMHO, such mixed cases require 
special attention, because the MH-PW as a solution for these cases 
must effectlvely address ALL the problems.

5. Consistency between Requirements for SH- and MH-PWs
======================================================

Certain requirements in the draft look to me as if they are
equally applicable (or not applicable) to SH- and MH-PWs.
One example is the requirement that an MH-PW Setup MUST fail
if there is no PSN tunnel for one of its segments meeting the
QoS requirements. 

AFAIK, RFC 3916 does not mention any such requirement, nor does 
the current PWE3 Control Protocol draft support QoS signaling. 

And the fact that the draft refers such a requirement to the case 
when U-PE tries to signal an MH-PW makes the inconsistency
even less understandable to me.

Another example in this calss is the requirement 
(Section 6.4, item (v))that 

<quote>
	Addressing of MS-PW end point at the U-PE MUST be
      independent of the IP address of the U-PEs themselves.
<end point>

Note that "addressing" of an SS-PW end point as discussed in
the current PWE3 Control Protocol draft is represented by:

- IP address of the peer U-PE
- PW Type
- PWID (for FEC 128) or {AGI, TAII) (for FEC 129)

and hence, IMHO,  does not meet this requirement.
Did I miss something here?

6. Requirements vs. Wishes
==========================

I believe that requirements worth defining must allow 
verification. Hence I have a problem with the following 
requirement found in the draft (Section 6.4, item vi):

<quote>
     Solutions MUST strive to minimize the amount of
     configuration needed to setup an MS-PW.
<end quote>

The only case when I could really say that this requirement is met
would be a signaling solution that did not require ANY configuration 
at all to setup an MS-PW (you can hardly expect have less configuration
than NONE). But I am not sure this is achievable.

Another example of this kind is the requirement found in
Section 6.4, item (vii):

<quote>
    MS-PW signaling procedures MUST define clear rules for
    triggering the setup of segments of a MS-PW.
<end quote>

Clarity, like beauty, is, IMHO, in the eye of the beholder!

Hopefully, these comments will be useful.

Regards,
                                  Sasha Vainshtein
email:                         [email-masked]
phone:                       +972-3-7569993 (office)
fax:                            +972-3-6487779
mobile:                      +972-52-8674833