Subject: Re: I-D ACTION:draft-martini-pwe3-MH-PW-requirements-00.txt

From: Luca Martini <[email-masked]>
Date: Tue, 14 Dec 2004 15:51:43 -0700

Sasha,
Bringing this discussion to the PWE3 list...

Thanks for the comments!
See below.

Luca

Sasha Vainshtein wrote:

> Luca and all, I have just started reading 
> draft-martini-pwe3-MH-PW-requirements-00.txt that has been announced 
> today. I have a few comments/questions that I'd like to discuss on 
> this list first.  
>
>    1. There are several *ediorial* nits that are worth fixing. E.g.:
>           * In Fig.2, there are PW1, PW3 and PW4, but no PW2, just an
>             "unnumbered" PW
>
???
I see PW2 in the picture.

>           * This notation contradicts, IMHO, the explanatory text
>             below that states that "PWs are used to connect the
>             Attachment circuits (ACs) attached to PE1 to the
>             corresponding ACs attached to PE3"
>
Yes, this requirement draft defines a new model , that might contradict 
the letter of some existing documents.

>           * The notion of a "PW segment" introduced later is not used
>             in the diagram
>
yes pw-segment , and SH-PW seem to be the same.
Can we remove the PW-segment definition ? or maybe alias it to SH-PW ?
Anybody ?

>           * Discussion of the scalability issues (item ii in Section 5
>             "Use Cases") states that full mesh of unidirectional PSN
>             tunnels between *N* PEs will provde *N2* tunnels (instead
>             of *N^2*)
>
This is really weird ! Somewhere in the e-mail , or the IETF directories 
the ^  got removed. The version I have locally on my computer has the ^ 
in it.

>           * Punctuation is wrong in items iii and iv of the same
>             section (neither a colon nor a full stop separate the name
>             of the issue from the first statement of the exposition) etc.
>
ok fixed.

>    1. The "Terminology" section mentions "*PW access point address*" -
>       a notion that is not used anywhere in the document (and, IMHO,
>       is not really defined in the document either). (And, BTW, I
>       think that the Client layer service accesses the server layer at
>       the *access* *point*, not at the *access point address*)
>
ok, will comment this out for now, if we use it , we'll put it back.

>    1. I think that the following statement in the "Use Cases" section
>       requires clarification: "*At a minimum PW control
>       channel establishment requires knowledge of and reachability to
>       the remote (ultimate) PE IP address*". I understand that
>       *reachability* of the remote ultuimate PE IP address may be
>       problematic in some cases; but do we really envision the case
>       when a PE can be set up without the one of the ultimate PEs
>       possessing any *knowledge* about IP address of its remote peer?
>       And, if this is the case, can in-band OAM provide end-to-end
>       connectivity verification?
>
sure. you can use 127.0.0.1 as the IP address of the in-band OAM packets .
I think that the requirement is to be able to establish a MH-PW between 
2 U-PEs with out having complete knowledge of each other's IP addresses. 
This does not mean that some S-PE in the middle does not know about at 
least one of the U-PE IP addresses.
Most of the text following is more a justification for the requirement.

>    1. Some of the MH-PW requirements look as if they equally apply to
>       SH-PWs. E.g., if "full client/server transparency" is a
>       mandatory requirement for MH-PW, why not for SH-PW? And why is
>       it limited to only S-PEs (and with exceptions)? It seems that
>       one of the editors (Luca?) was really dissatisfied with this
>       text, too...
>
I only edited format this time ;-) so I did not express any opinion.... 
I think this was Nabil.
This is probably not a valid requirement for MH-PW as it is written. We 
are not going to change the encapsulation of PWs unless there is a 
really good reason why then cannot be turned into MH-PWs.

Do you agree ?

>    1. Still more on the "full client/server transparency": I have seen
>       Neil's comments on the PWE3 list that can be interpreted as if
>       FCS retention is part of this transparency. If this is so, then
>       we cannot meet the requirement to use PWE3 encapsulations in
>       MH-PWs (since they, at best, consider FCS retention as OPTIONAL).
>
Ok, so we either say that PW do not fit , or MH-PWs have to be based on 
SH-PWs.
I think that the latter is a clear requirement, and much stronger then 
the former.

>    1. What exactly is meant by "tunneled MH-PWs" and "overlay tunnels"
>       (in item ii of Section 6.1)? These notions are not defined
>       anywhere (AFAIK)
>
I think that this means that if PW are used to build a PSN, then if the 
PSN is in turn used to carry PWs, the latter should not be impacted by 
the former PWs.
( quite frankly I cannot see how they could ... )

>    1. Change of encapsulation mode defined as an option for  S-PEs is
>       not defined unambiguously. E.g., suppose that I want to carry an
>       ATM VC bewteen two CEs: can an S-PE change encapsulation from
>       "N-to-one" to "One-to-one"? Or from Cell relay to SPDU? (In case
>       anybody has his/ger doubts, I find this ptoposal abhorrent, but
>       it is not explicitly prohibited by the text as I read it)
>
yes. Actually I would like to ask the SPs , if they really want to 
operate a network that might have an Interworking function somewhere 
along it path?  To me this is operational suicide. After all a PW could 
be interworked several times .. like ethernet -> ATM ->Frame-Relay -> 
Ethernet ....
Interworking at the S-PE  is one of the requirements that I would like 
to seriously consider removing.

>    1. Item i in Section 6.2 requires that U-PEs and S-PE are capable
>       of admission control per PSN tunnel. Does this preclude PSN
>       tunnels that do not have any explicit QoS guarantees (like
>       L2TPv3)? Or does it mean that, for these ctunnels, admission
>       control simply admits everything? (I'm pretty sure that at least
>       one of you will attribute this comment one more incaration of
>       the original PWE3 sin, namely, that MPLS = IP, but then, at
>       least one other participant of this team has explicitly
>       requested L2TPv3 becoming as standard as MPLS for PWs ;-)
>
This is not an unreasonable question. L2TPv3 might have several session 
each with different QoS settings in the DSCP bits of the IP header. 
Tunnel CAC need not be based on RSVP-TE. I believe that the intent was 
to mention only MPLS LSPs.
However I would like to hear from Lei how can CAC be used in l2TPv3.
( also this section has spell errors and grammar issues ... )
We also need to consider that TE is unidirectional , but PW are 
bi-directional.  what happens if a PW is admitted in one direction , but 
fails in the other direction ?

>    1. Item ii in Section 6.2 seems even more suspicious because it
>       requires that U-PEs and S-PEs actually select a path across the
>       PSN along which the traffic will be tunneled. IMHO we have nvere
>       before discussed this "requirement"; can somebdy please point to
>       its origin?
>
I think this is needs to be re-written to fit into the pwe3 charter :

When setting up a MH-PW, S-PEs and U-PEs MUST be able to request a 
tunnel across the PSN in such a way as to  satisfy the MH-PW QoS and 
bandwidth requirements. Restrictions may apply depending on the method 
used for setting up a PW segment and on PSN  tunnel types.
Note that this is not new, and can be achieved today in many SH-PW 
implementations.

>    1. Last (for the moment) but not least: Skipping quite a few
>       sections, what exactly is intended by the statement in item
>       iii,. Section 6.6 "*The MH-PW client SHOULD support a A Forward
>       Defect Indicator (FDI)*" ? MH-PW clients, IMHO, are native
>       services for which PWE3 is provided, right? So, if a service
>       (like Ethernet, FR or NxDS0) does not provide FDI, it does not
>       deserve becoming a client of an MH-PW (and should feel happy
>       that less restrictive SH-PWs still bother carrying it)?
>
I believe that this refers to the PW status TLV infrastructure. Where we 
can send a fault indication in the forward direction.
right ?

Thanks.
Luca

> Hopefully these comments will be helpful.   Regards, 
>                                   Sasha Vainshtein 
> email:                         [email-masked] 
> <mailto:[email-masked]> phone:                       +972-3-7569993 
> (office) fax:                            +972-3-6487779 
> mobile:                      +972-52-8674833

---

From: Chris Metz <[email-masked]>
Date: Sun, 19 Dec 2004 11:01:59 -0800

Hi-
I think we are missing a specific USE CASE from section 5.
Consider the case where we have each PE pair
run a client control plane function. This control plane
function drives creation (and deletion) of corresponding PW segments
between each PE pair. Rather then terminate
and process the PW payload at each intermediate PE
(between the source and target U-PEs),
we splice the preceding and succeeding PW segments
together ... so that the data plane at the intermediate
PE(s) becomes a PW label swap operation.

Cheers ...

---

From: Chris Metz <[email-masked]>
Date: Sun, 19 Dec 2004 11:26:25 -0800

At 03:51 PM 12/14/2004 -0700, Luca Martini wrote:
<snip>

>>       possessing any *knowledge* about IP address of its remote peer?

Yes ... especially if the MH-PW setup scheme is created in such a way
so that the source U-PE does not need to know the IP address of the
remote U-PE. This may be for variety of reasons including security, scale, 
etc.

We would need to include TAI that identifies the desired AC on the remote
U-PE.

Cheers ...

<snip>

---

From: dimitri papadimitriou <[email-masked]>
Date: Mon, 20 Dec 2004 00:09:14 +0100

PW segment definition (which is not a SH-PW) was meant to deliver such 
capability since S-PE are agnostic to both PW payload its associated 
control so that only ingress/egress U-PEs have to terminate and process 
such payload

note: the confusion comes from the following sentence where (SH-PW) 
appears in parenthis
"     - Multi-hop PW (MH-PW).  A static or dynamically configured set of
        two or more contiguous PW segments (SH-PW) that behave and
        function as a single point-to-point PW. Each end of a MH-PW by
        definition MUST terminate on a U-PE."

also a SH-PW is constituted by a single PW segment and a MH-PW is 
constituted by more than one PW segment (one between the ingress U-PE 
and the S-PE, one between each S-PE pair and one between the last S-PE 
and the egress U-PE)

Chris Metz wrote:
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 
> .
>

---

From: dimitri papadimitriou <[email-masked]>
Date: Mon, 20 Dec 2004 00:34:24 +0100

per section 5.2.1. of PW control: "The Attachment Identifier must be 
unique in the context of the PE router in which the Forwarder resides. 
The combination <PE router, AI> must be globally unique."

therefore, either the PE router is used (leaving AC selection being a 
local process) or both are explicitly specified as part of the request 
or one identifies the ACs using their mapping in the CP as IP addresses 
since a reachable point can be translated with an IP prefix (at the 
control plane level) whereas the corr. data plane end-point does not 
have to terminate IP packets

Chris Metz wrote:

> remote U-PE. This may be for variety of reasons including security, 
> scale, etc.
>