Subject: RE: [PWE3] re: draft-bryant-pwe3-mpls-transport-00.txt

From: <[email-masked]>
Date: Wed, 8 Nov 2006 11:08:03 -0000

Thanks Yakov,

At this stage we are simply trying to get a common understanding and
agreement on the requirement and the basic carrier network scenarios.
What is the appropriate shim is open to debate.

The requirement we have is for the MPLS layer network of party A to be
carried over the MPLS layer network of party B in a proper client/server
manner, ie full functional decoupling of the 2 MPLS layer networks (so,
in particular, this means no control-plane peering). Note that as
operators sunset many current technologies (eg FR, ATM, PDH, SDH_VC12)
this issue is becoming increasingly more important.

Now how we discharge this requirement is for discussion. It is too late
to go back and 're-engineer' MPLS per se to provide this client/server
requirement directly.

There is a scenario where LSR A1 has its MPLS on an Ethernet interface
as does LSR A2. In this scenario, A1 and A2 would reasonably expect the
MAC layer to be available to them and so it needs to be supported
transparently. This scenario is addressed in Stewart's draft. But what
if A1 and A2 have POS interfaces, or A1 has an Ethernet interface and A2
has a POS interface?

Having stated the requirement, I think it is now up to the WG to
consider how best to meet this requirement given the current status of
MPLS rfcs and the deployed base.

regards, Neil

> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]] 
> Sent: 08 November 2006 02:33
> To: Harrison,N,Neil,JCGA1 R
> Cc: [email-masked]; [email-masked]; Willis,PJ,Peter,CXM R; 
> Reid,ABD,Andy,CXM R; Mcguire,A,Alan,XGH62 R
> Subject: Re: [PWE3] re: draft-bryant-pwe3-mpls-transport-00.txt 
> 
> 
> Neil,
> 
> > Stewart,
> > 
> > Interesting suggestions on MPLS transport. As you are going 
> to discuss 
> > it this week we thought that you may wish to take the 
> following into 
> > consideration.
> > 
> > First of all, a major requirement for network operators is backward 
> > compatability with existing RFC's and reuse of widely 
> installed base. 
> > These probably outweigh any other considerations.
> > 
> > An application that is of interest is how to transport the MPLS 
> > network of one operator (A) over the transport network of 
> another (B), 
> > rather than by means of peering.  By this I mean provide MPLS 
> > transport between LSR A1 and A2 of operator A over an MPLS 
> network of 
> > B. This might occur for example in international networks where 
> > operator A requires an in-country transport capability from B.
> > 
> > This supports an operational requirement that many 
> operators apply in 
> > practise, namely, isolation of the control plane of network A from 
> > that of network B. This can be for a number of reasons including 
> > scalability and security. As such it is not possible for 
> operator A to 
> > mandate the control plane that should be used by B, rather 
> A is only 
> > interested in the service offered by B. Therefore I would 
> suggest that 
> > how B provides its control plane is not a primary requirement.
> >  
> > One mechanism for providing isolation is to provide a common "shim" 
> > technology such as ethernet. This isolates the two 
> forwarding stacks. 
> > An alternative would be to consider a suitable PW. Another option 
> > would be to continue the label stack, although there may be 
> > considerations regarding misconnectivity.
> 
> Since you view the reuse of widely installed base as a major 
> requirement, which of the three options you mentioned above 
> meet this requirement ?
> 
> Yakov.
> 

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

---

From: <[email-masked]>
Date: Mon, 13 Nov 2006 10:09:26 -0000

Colleagues,

Just to follow up Neil's comment.  We provided some
background/discussion on SP requirements for client/server relationships
in Section 1.1 of draft-willis-pwe3-requirements-00 which has now
expired but is available here:

http://www.niven-jenkins.co.uk/draft-willis-pwe3-requirements-00.txt

Ben

[email-masked] <mailto:[email-masked]> wrote:
> Thanks Yakov,
> 
> At this stage we are simply trying to get a common
> understanding and agreement on the requirement and the basic carrier
> network scenarios. What is the appropriate shim is open to debate.
> 
> The requirement we have is for the MPLS layer network of
> party A to be carried over the MPLS layer network of party B
> in a proper client/server manner, ie full functional
> decoupling of the 2 MPLS layer networks (so, in particular,
> this means no control-plane peering). Note that as operators
> sunset many current technologies (eg FR, ATM, PDH, SDH_VC12)
> Now how we discharge this requirement is for discussion. It
> is too late to go back and 're-engineer' MPLS per se to
> provide this client/server requirement directly.
> 
> There is a scenario where LSR A1 has its MPLS on an Ethernet
> interface as does LSR A2. In this scenario, A1 and A2 would
> reasonably expect the MAC layer to be available to them and
> so it needs to be supported transparently. This scenario is
> addressed in Stewart's draft. But what if A1 and A2 have POS
> interfaces, or A1 has an Ethernet interface and A2 has a POS
> interface? 
> 
> Having stated the requirement, I think it is now up to the WG
> to consider how best to meet this requirement given the
> current status of MPLS rfcs and the deployed base.
> 
> regards, Neil
> 
> 
>>> Interesting suggestions on MPLS transport. As you are going to
>>> discuss it this week we thought that you may wish to take the
>>> following into consideration. 
>>> 
>>> compatability with existing RFC's and reuse of widely installed
>>> base. These probably outweigh any other considerations.
>>> 
>>> network of one operator (A) over the transport network of another
>>> (B), rather than by means of peering.  By this I mean provide MPLS
>>> transport between LSR A1 and A2 of operator A over an MPLS network
>>> of B. This might occur for example in international networks where
>>> This supports an operational requirement that many operators apply
>>> in practise, namely, isolation of the control plane of network A
>>> from that of network B. This can be for a number of reasons
>>> including scalability and security. As such it is not possible for
>>> operator A to mandate the control plane that should be used by B,
>>> rather A is only interested in the service offered by B. Therefore
>>> I would suggest that how B provides its control plane is not a
>>> primary requirement. 
>>> 
>>> technology such as ethernet. This isolates the two forwarding
>>> stacks. An alternative would be to consider a suitable PW. Another
>>> option would be to continue the label stack, although there may be
>> requirement, which of the three options you mentioned above meet
>> this requirement ? 
>> 
>> Yakov.
>> 
>