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

From: David McDysan <[email-masked]>
Date: Wed, 19 Jan 2005 11:28:41 -0500

I have snipped parts of the text that are not relevant.

Dave

>                                   Sasha Vainshtein
> > From: Luca Martini [mailto:[email-masked]]
> > > Sasha Vainshtein wrote:
> > 

> > >    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?

More good arguments for making use of the U-PE IP address a mandatory
requirement.

---

From: David McDysan <[email-masked]>
Date: Wed, 19 Jan 2005 12:10:05 -0500

In order for SP's to interconnect, some globally unique identifier is
necessary. Suggest that support for IPv4 and IPv6 addresses as such
identifiers are a mandatory requirement. 

Some other identifier (e.g., name, URI) could be used but more detailed
requirements are needed. 

Peter, in applying the VoIP analogy are you referring to a Session Border
Controller (SBC) as a means of hiding the destination IP address? If so,
then the S-PE is analogous to the SBC and at least the IP address of the
S-PE(s) that can reach the target U-PE identifier (or range of identifiers)
must be resolvable with such resolution authenticated, as Sasha suggests.

Also agree with the suggestion on adding a AAA section for MH-PW signaling. 

Also suggest some comments should be made in the security section if a
routing protocol is used between domains to exchange IP reachability
information (e.g., the domains may want to use authentication for
establishment of the routing protocol sessions).

Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Sasha Vainshtein
> Sent: Friday, December 17, 2004 8:40 AM
> To: 'Peter Willis '
> Cc: [email-masked] '; [email-masked] 
> '; [email-masked] '; [email-masked] '; Alik Shimelmits; 
> [email-masked] '; [email-masked] '; 
> ''Luca Martini' '; [email-masked] '; 
> [email-masked] '; [email-masked] 
> '; [email-masked] '; 'PWE3 WG (E-mail) '; 
> [email-masked] '; [email-masked] '; Sharon 
> Galtzur; 'Ping Pan '; [email-masked] '; 
> [email-masked] '
> Subject: RE: [PWE3] Re: I-D 
> ACTION:draft-martini-pwe3-MH-PW-requirements-0 0.txt
> 
> 
> 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 
> 
> 
> > 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
> single-touch
> > provisioning, the following logic looks correct to me:
> 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?
> > >
> 
> 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.
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>