[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [PWE3] New PWE3 Charter Items: SPVC Interworking
Neil,
I hope that you can help me understand what the practical implictions are of some of your generic statements. Please see below.
Peter
>
> NH=> In simple client/server i/w (aka network i/w) the
> control-planes of both the client and the server layers are
> independent with no i/w at all.
Mustapha's email addressed control plane interworking between ATM and MPLS. In that context, how should I interpret your statement? Are you saying that the only valid way of carrying ATM over MPLS is the following: establish a Pseudo Wire that carries multiple VPs in such a way that ATM signaling and routing information is carried transparently over that PW and the establishment of new VPs or VCs through that PW should be done in such a way that it doesn't require any additional signaling in the MPLS plane? This would exclude any form of 1-1 encapsulation where VC or VP setup necessarily triggers PW setup.
> * Because PWE3 does not recognise MPLS as a layer
> network in its own right we don't have i/w with MPLS LSPs
> directly but rather a forced client/server i/w with PWs on a
> client specific basis. This is a mistake in our view for
> several reasons, but that is what has happened and is now
> something some folks are going to have to live with. This
> means there will be (at least) O(N^2) possible mapping
> relationships in the data-plane
As a generic statement this sounds reasonable, but when you look at the specifics of existing protocols, I don't think it holds.
The MPLS-FR Alliance has recently examined Service Interworking in-depth. One of the conclusions was that you can't do generic (i.e. payload-independent) service interworking between Ethernet on the one hand and Frame Relay or ATM on the other. (This was explained in detail in a contribution by Rao Cherukuri and Ali Sajassi.) As a result, the MPLS-FR Alliance decided that Service Interworking can only be done in very specific cases:
1) Between Frame Relay and ATM, according to FRF.8
2) In case of end-to-end transport of Ethernet traffic (i.e. where ATM and FR use bridge-mode encapsulation)
3) In case of end-to-end transport of IP traffic (i.e. where ATM and FR use routed-mode encapsulation)
Of these, (2) can hardly be considered as Service Interworing in the traditional sense of the word. It is essentially a variant of network interworking of Ethernet over ATM or FR. (3) is more complicated due to IP specific issues that have been identified by Himanshu Shah and Ali Sajassi in earlier drafts, but still it is not Service Interworking in the traditional sense of the word.
The same holds for MPLS: it would be possible to define SI between FR and MPLS or ATM and MPLS. However, it is not possible to define generic (payload-independent) Service Interworking between Ethernet and MPLS.
Therefore, your statement about the service interworking between N different protocols reduces to a statement about Frame Relay and ATM only. For N=2, it seems that PW emulation of ATM (or FR) over MPLS in conjunction with FRF.8 is a more pragmatic approach than the alternative that you propose: SI between ATM and MPLS followed by SI of MPLS to FR.
Am I missing something?
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3