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

From: [email-masked]
Date: Mon, 7 Feb 2005 11:12:11 -0500

Peter,
Comments in line.

Thanks,
Nabil

                      "Peter Willis"                                                                                                 
                      <pjw@ip-engineeri        To:       "Sasha Vainshtein" <[email-masked]>                                       
                      ng.bt.com>               cc:       "'Luca Martini'" <[email-masked]>, [email-masked],    
                                                [email-masked], [email-masked], "Alik Shimelmits" <[email-masked]>,              
                      12/16/2004 12:05          [email-masked], [email-masked], Nabil N. Bitar/EMPL/MA/Verizon@VZNotes,    
                      PM                        [email-masked], [email-masked], [email-masked],     
                                                [email-masked], "PWE3 WG (E-mail)" <[email-masked]>,                  
                                                [email-masked], [email-masked], "Sharon Galtzur" <[email-masked]>,     
                                                "Ping Pan" <[email-masked]>, [email-masked],                         
                                                [email-masked]                                                          
                                               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
> 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?
> >

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.

<NB> Agree. This is an important distinction from security and
confidentiality view point.

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 later makes reusing PPP/radius like mechanisms easier?

<NB> Did you mean single-ended provisioning or endpoint provisining and
single-ended signaling?
<NB> I do agree with the general poicing function at the interprovider
<NB> boundaries. Authentication of the signaling entities is necessary.
Regarding authentication
<NB> per MH-PW, I can see a case where you may want to ensure that one
source point for a MH-PW
<NB> can actually connect to the destination it wants to connect to. Since
the MH-PW can be entering the destination domain
<NB> through one ore more S-PEs, one may want to autenticate that at the
ingress ASBR (from signaling view
<NB> point) or at the destination U-PE.

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.

<NB> To do this hiding, there are many possible mechanisms and may depend
on the way that
<NB> that the MH-PW is setup. In the static stitching case between
segments, I think that
<NB> it is clear that the hiding that can be easily achieved, as the U-PE
needs to signal
<NB> for a PW segment that can be identified at an S-PE where the endpoint
of the segment
<NB> is configured. That is in turn can be statically correlated with the
next statically
<NB> configured segment. In that way, the signaling message is addressed to
the S-PE (not the remote
<NB> U-PE). This can repeat across boundaries.
<NB> The issue here is related to single-end signaling and the contraint is
the signaling
<NB> message has to get finally to get to the remote U-PE through
intermediate S-PEs.
<NB> One possible way to achieve the hiding here is to include in something
like a TAI an identifier
<NB> for the destination (I think Others have indicated something along
that line).
<NB> That identifier can be of many form but may include something like
(network address and a connection identifier in that context
<NB> of that address. However that network addrees must be usable by the
S-PE or some proxy to find an IP route
<NB> to the destination.  In addition, for the general case, that address
should be globally unique so that an S-PE
<NB> that happens to be the next domain ASBR can uniquely identify the
destination. Otherwise, one has to configure
<NB> translations or resolutions at every domain boundaries (which defeats
the purpose of only endpoint provisioning), especially if the MH-PW
<NB> crosses multiple provider domains (which one may argue it is the not
the most common case). Thus, the simplest form is to have
<NB> the network to be an IPv4 address based on existing network
deployments. To perform the hiding, U-PEs can be assigned loopback
addresses
<NB> that are aggregatable and get used for this purpose for instance or
have IPv4 addresses assigned to UNI ports etc. These aggregates
<NB> can be advertised in BGP for instance, only the destination domain
will have the host address reachability. The alternative of having
<NB> an IPv6 address, NSAP, E.164 addresses are also possible. They will
either require assigning the destination <NB> addresses or require some
mapping or resolution
<NB> of these addresses to U-PE addresses or routes that lead to the
destination network where ultimately
<NB> that endpoint network address is resolved to the U-PE IPv4 address.

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

---

From: David McDysan <[email-masked]>
Date: Wed, 09 Feb 2005 09:56:10 -0500

A few responses in line.

Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Monday, February 07, 2005 11:12 AM
> To: Peter Willis
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; Alik Shimelmits; [email-masked]; 
> 'Luca Martini'; [email-masked]; 
> [email-masked]; Sasha Vainshtein; 
> [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,
> Comments in line.
> 
> Thanks,
> Nabil
> 
> 
> 
> 
>                                                               
>                                                               
>          
>                       "Peter Willis"                          
>                                                               
>          
>                       <pjw@ip-engineeri        To:       
>                       ng.bt.com>               cc:       
> "'Luca Martini'" <[email-masked]>, 
> [email-masked],    
>                                                 
>                       12/16/2004 12:05          
> [email-masked], [email-masked], Nabil N. 
> Bitar/EMPL/MA/Verizon@VZNotes,    
>                       PM                        
> [email-masked], [email-masked], 
> [email-masked],     
>                                                 
>                                                 "Ping Pan" 
> <[email-masked]>, [email-masked],             
>             
>                                                 
>                                                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)
> > 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
> > * It MUST receive the information containg unambiguous 
> identification 
> > of
> the
> > remote
> > 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
> 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.
> 
> <NB> Agree. This is an important distinction from security 
> and confidentiality view point.
> 

Suggest that intra versus inter operator is more of a use case description
and that the requirements should focus on the protocol. For example a
technical requirement could be use of IP addresses or some other to be
specified identifier mentioned previously on this list (e.g., phone number
or something else). Either identifier could be employed in an inter or intra
operator context.

> 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 later 
> makes reusing PPP/radius like mechanisms easier?
> 
> <NB> Did you mean single-ended provisioning or endpoint 
> provisining and single-ended signaling? <NB> I do agree with 
> the general poicing function at the interprovider <NB> 
> boundaries. Authentication of the signaling entities is 
> necessary. Regarding authentication <NB> per MH-PW, I can see 
> a case where you may want to ensure that one source point for 
> a MH-PW <NB> can actually connect to the destination it wants 
> to connect to. Since the MH-PW can be entering the 
> destination domain <NB> through one ore more S-PEs, one may 
> want to autenticate that at the ingress ASBR (from signaling 
> view <NB> point) or at the destination U-PE.
> 
> 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 
> <NB> To do this hiding, there are many possible mechanisms 
> and may depend on the way that <NB> that the MH-PW is setup. 
> In the static stitching case between segments, I think that 
> <NB> it is clear that the hiding that can be easily achieved, 
> as the U-PE needs to signal <NB> for a PW segment that can be 
> identified at an S-PE where the endpoint of the segment <NB> 
> is configured. That is in turn can be statically correlated 
> with the next statically <NB> configured segment. In that 
> way, the signaling message is addressed to the S-PE (not the 
> remote <NB> U-PE). This can repeat across boundaries. <NB> 
> The issue here is related to single-end signaling and the 
> contraint is the signaling <NB> message has to get finally to 
> get to the remote U-PE through intermediate S-PEs. <NB> One 
> possible way to achieve the hiding here is to include in 
> something like a TAI an identifier <NB> for the destination 
> (I think Others have indicated something along that line). 

Do we want to (re)define the TAI for this purpose, or consider defining
another object?

> <NB> That identifier can be of many form but may include 
> something like (network address and a connection identifier 
> in that context <NB> of that address. However that network 
> addrees must be usable by the S-PE or some proxy to find an 
> IP route <NB> to the destination.  
        Suggest^^^ toward

> In addition, for the 
> general case, that address should be globally unique so that 
> an S-PE <NB> that happens to be the next domain ASBR can 
> uniquely identify the destination. Otherwise, one has to 
> configure <NB> translations or resolutions at every domain 
> boundaries (which defeats the purpose of only endpoint 
> provisioning), especially if the MH-PW <NB> crosses multiple 
> provider domains (which one may argue it is the not the most 
> common case). Thus, the simplest form is to have <NB> the 
> network to be an IPv4 address based on existing network 

suggest or IPv6

> deployments. To perform the hiding, U-PEs can be assigned 
> loopback addresses <NB> that are aggregatable and get used 
> for this purpose for instance or have IPv4 addresses assigned 
> to UNI ports etc. These aggregates <NB> can be advertised in 
> BGP for instance, only the destination domain will have the 
> host address reachability. 

Other IP routing protocols can be used for this purpose as well.

> The alternative of having <NB> an 
> IPv6 address, NSAP, E.164 addresses are also possible. 
> They 
> will either require assigning the destination <NB> addresses 
> or require some mapping or resolution <NB> of these addresses 
> to U-PE addresses or routes that lead to the destination 
> network where ultimately <NB> that endpoint network address 
> is resolved to the U-PE IPv4 address.

Suggest that you add the essence of the above text to the next draft and
attempt to use requirements verbs (SHALL, SHOULD). It is a good description
of what needs to be done.

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