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

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 15 Dec 2004 10:01:30 +0200

Luca and all,
Please see some answers inline.
I have snipped parts of the text that are not relevant to the key issues.

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

> -----Original Message-----
> From: Luca Martini [mailto:[email-masked]]
> Sent: Wednesday, December 15, 2004 12:52 AM
> To: Sasha Vainshtein
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; Alik Shimelmits; PWE3 WG (E-mail); 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; 
> [email-masked]; [email-masked]; Sharon 
> Galtzur; Ping Pan; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: [PWE3] Re: I-D 
> ACTION:draft-martini-pwe3-MH-PW-requirements-00.txt
> 
> 
> Sasha,
> Bringing this discussion to the PWE3 list...
>
[Sasha] OK.
> 
> 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. 
>
[Sasha] ... snipped ...
>
> >    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.
>
[Sasha] I am still not so sure. Here are two issues that require discussion

1. E2E connectivity verification for MH-PWs. If the corresponding
OAM packets do not carry unambigouous identification of the expected 
remote end point, this functionality cannot be fully supported, IMHO.
And unambiguous identification of the remote peer end point that does not
yield an umbiguous identification of the containing U-PE seems highly
problematic to me. There is a difference between carrying such an
identification
in the CV packets and carrying it as the Destination IP address in the IP
header of these packets (assuming that they are IP packets) - a
situation dealt with in the LSP Ping proposal: Destination IP address
of the LSP Ping packets is from 127.0.0.0/8 so that it would be recognized
as
having local destination by every LSR that terminates the LSP (e.g., 
in the traceroute mode or due to misconnection). But the payload carries
the explicit FEC stack.

2. Requirement (mentioned by several people in the discussion on the DT
list)
for "one-touch single-ended provisioning of an MH-PE". The draft in question
presents a weaker form of this requirement (Section 6.5., item ii), speaking
about
an option to signal a MH-PW using a minimal number of OSS touches, where 
the minimal number" may be greater than 1. But if we tend for single-touch
provisioning, the following logic looks correct to me:
* The device to be touched MUST be one of the U-PEs
* It MUST receive the information containg unambiguous identification of the
remote 
peer end point, including unambiguous identification of the remote U-PE

Of course, one could argue that unambiguous identification of the remote
U-PE
does not have to be its IP address. But in real life, what other unambiguous
identification of devices do we have? Phone numbers?
>
> >    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 ?
> 
[Sasha] Of course I agree that we should preserve PW encapsulations when 
going from SH-PWs to MH-PWs. Any other approach would be a nightmare
for the vendors and operators.

At the same time, please note that the current PWE3 Architecture document
has its own wording for "client/servr transparency". It is called
"Principle of Minimum Intervention" (Section 3.3.5). So I have two
practical suggestions for the next revision of the draft:

* Use one consistent set of notions and terms, presumably based
  on the existing PWE3 architecture with the necessary extensions
* Provide (as an Annex?) consistent translation between this set of terms 
  and the applicable terms/motions of G.805.

The alternative is the current situation when a requirement that has been
explicitly formulated (even if not always met) for SH-PWs looks like a
new requirement restricted to MH-PWs because it is formulated
using a different language.
> 
> >    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.
>
[Sasha] AsI have said already, I agree that MH-PWs and SH-PWs
MUST use the same encapsulation. And I think that this should
be explicitly stated in the MH-PW requirements draft.
... snipped ...
>
> >    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/her 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.
>
[Sasha] I could not say it better! 
>
> >    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.
>
[Sasha] If this was the intent, let's implement it!
>
> 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 ?
>
[Sasha] I assume the setup should fail?
>
> >    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 somebody 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.
>
[Sasha] This sounds reasonable to me.  
>
> >    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 ?
>
[Sasha] I think that the text, as written, admits too many interpretations,
partly due to the fact that it uses terms (like MH-PW client) that are
not explicitly defined. 

And I suspect that FDI belongs to the data plane, not to the control plane, 
so I doubt if the PW Status TLV is relevant for the text as written...
(That is why FR does not have any FDI...)
> 
> 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 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Sasha Vainshtein <[email-masked]>
Date: Fri, 17 Dec 2004 15:39:31 +0200

Peter and all,
Please see a brief comment inline below.
Regards,
               Sasha

-----Original Message-----
From: Peter Willis
To: Sasha Vainshtein
Cc: 'Luca Martini'; [email-masked]; [email-masked];
[email-masked]; Alik Shimelmits; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; PWE3 WG
(E-mail); [email-masked]; [email-masked]; Sharon Galtzur; Ping
Pan; [email-masked]; [email-masked]
Sent: 12/16/2004 7:05 PM
Subject: Re: [PWE3] Re: I-D ACTION:draft-martini-pwe3-MH-PW-requirements-0
0.txt 

> identification of devices do we have? Phone numbers?

We should be clear whether the 1 touch single-ended provisioning of
an MH-PW applies to both the intra-operator & inter-operator cases? 
If it only applied to the intra-operator case then the solution may be
simpler.

[Sasha] I agree. And it seems to me that the one-touch single-ended
provisioning has been mentioned wrt the intra-provider use case
(cannot check that since I cannot access my archive at the moment).

If we want 1 touch single-ended provisioning for the inter-operator case
then I think we would want an AAA mechanism on the S-PEs (but we can
abstract that and just say the S-PEs have a policy mechanism for 
policing the set-up of MH-PWs) and then I'm not sure whether 
authentication of the signalling entities between operators is sufficient
or whether each MH-PW needs its own AAA. I suspect the latter makes reusing
PPP/radius like mechanisms easier?

[Sasha] A nice touch - on at least two counts:
- seems like we need an AAA section in the requirements document, and
  this was not touched so far
- I would expect the SPs to push strongly for reuse of the existing
  AAA architecture and methods; but then I do not work for an SP.
  
If you look at PSTN style VoIP interconnects (see
http://www.msforum.org/) 
you'll see examples of how IP connections are set-up between operators
where 
the IP addresses of the infrastructures are hidden and a common
identifier 
(the telephone number) is used to set-up the connection. I can see
similar 
requirements for inter-operator MH-PWs, i.e. Operators will want to hide
the 
IP addresses of their infrastructure (signalling & media connection
points) 
from each other. Of course there is no reason why the MH-PW attachement
points 
could not use IP addresses (I'd be ambitious and suggest IPv6 addresses)
that 
have nothing to do with the IP addresses used for the control planes &
the 
network infrastructure. The solution here will look very complex
(something 
like the MSF solution?) so the requirement for single-ended provisioning
of 
PWs inter-operator must be really strong to justify this.

[Sasha] I am not sure this example is valid - for two reasons:
- U-PEs are not (or not always) part of the operators' infrastructure,
  so hiding their IP addresses may be not really necessary
- Telephony has its own identification (phone numbers) already
  in place,and this identification is essentialfor the service (you
  do not dial an IP address, at least not today!), so the justtification
  for the translation mechanism between two identifications is easy.
  Such a system does not exist in the case of MH-PWs, and developing it
  involves,IMHO, substantial cost...
But I agree that the requirement level for one-touch single-ended
provisioning probably differs for the intra-operator and inter-operator
cases.

Regards,
Peter Willis,
Office of the BT Group CTO.

---

From: Peter Willis <[email-masked]>
Date: Tue, 21 Dec 2004 16:43:57 +0000

The other advantage of AAAing each MH-PW and reusing existing RADIUS 
infrastructure is that the FQDN could be used to identify the U-PE attchement 
circuit. We can hide the IP addresses of the operators' infrastructure from each other and use FQDN
 without resorting to using "phone numbers".

Did someone did say we should look at lessons learnt from L2TP for MH-PW?

AAAing each PW also solves my business processes of how I'm going to trust 
the other operator to authenticate their attached customers and it could 
solve the problem of ensuring that PW provisioning does not get PWs 
crossed over.

So dynamically signalling inter-operator PWs might not be that difficult if 
we're willing to think "outside the box".

> I'm not sure whether 

Regards,

Peter.