Subject: X/MPLS vs X/IP

From: Mark Seery <[email-masked]>
Date: Wed, 21 May 2003 13:16:08 -0700 (PDT)

So hadn't felt the need to get in to this before, but
the "is PWE a layer" discussion kind of forces it, in
a way.

NH has lots of thoughts about why X/MPLS is different
than X/IP, and perhaps when Neil has time he can
briefly enumerate them, so leave the general question
in his hands.

But OAM raises a specific issue. If you run a client
(ethernet) over a server (IP), then what server OAM
are you going to use? And if neither the server nor
the client have OAM, then where do you put it?

More generally, how often are we going to be tempted
to throw something into the PWE layer, because one or
all server layers is missing something?

Those questions invite the following questions:
+ Do we define one server layer, or multiple server
layers in the IETF?
+ If we define multiple server layers in the IETF, do
they have to be functionally equivalent?
+ If we have multiple server layers and they are not
functionally equivalent, then can PWE work without
turning PWE into a server layer itself?

Mark

---

From: "Jack Pugaczewski" <[email-masked]>
Date: Wed, 21 May 2003 15:30:05 -0500

Why can we not standardize the FM OAM functionality for PWE-3 in a similar
manner as Frame Relay and ATM have been defined ?

PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Shahram Davari
> Sent: Wednesday, May 21, 2003 2:58 PM
> To: 'Mark Seery'; [email-masked]
> Cc: [email-masked]
> Subject: RE: [PWE3] RE: Is PWE a layer?
>
>
> Mark,
>
> >So let me start by saying I think PWE OAM is a mistake
> >in principal (architecturally speaking - under any
> >circumstances) and a mistake in practice unless we can
> >not get these other issues resolved. There are some
> >big picture issues which play in here with respect to
> >PWEs role and x/MPLS vs x/IP - but perhaps that should
> >be a separate thread.
>
> Agree.
>
> >Now to your point. In the absence of an edge-to-edge
> >OAM, how are you going to know where the problem is in
> >the first place to go use the proprietary OAM between
> >the line cards? You then have to go running the
> >proprietary OAM on every edge to find out where the
> >problem is don't you? Isn't this a lot of work for the
> >operator,
>
> I don't think so. This is confined within a box and should
> be easily configurable.
>
>  ?ot to mention the impact on historical
> >verification of SLAs and pinning down transient
> >errors. So then I guess you should run the proprietary
> >OAM constantly.
>
> Yes, my suggestion was to run it continuously.
>
>
> >Now what, do you interwork it with the
> >server layer, do you treat it as a client layer.....?
> >It is really the same problem all over again.
>
> I think you have to generate AIS on the payload the PW
> is carrying such as ATM AIS.
>
> >
> >Clearly the solution is a) only design systems in
> >certain ways or b) work with client layers to make
> >sure they have the OAM they want. I think operators
> >might want to have a chat with their vendors and
> >understand a) before they put a hard stake in the
> >ground on this one. b) is preferrable but the
> >cooperation of other organizations is not exactly
> >guaranteed.
> >
> >If as an industry we can't rely on client layers
> >having their own OAM, then we have to force the PSN
> >processing (for example MPLS) back to the client
> >service interface (as we do today with TDM networks)
> >or create an in-between kludge. Forcing the PSN
> >processing back to the client interface essentially
> >means that vendors have to develop two cards. One is a
> >cost effective card that does not have the PSN
> >processing, the other is a more expensive card that
> >does have the PSN processing. The reason I say this is
> >because MPLS processing, which essentially means IP as
> >well, is non trivial today; much more say than TDM
> >processing (and even if it is not, market forces with
> >create a pricing difference to the operator). This is
> >further complicated by the fact that for similar
> >reasons, vendors will often have two versions of the
> >network-side card already.
> >
> >My preference would be for the IETF to go back to
> >client layer organizations and let them know that
> >services can not be offered using their technology,
> >that have strong SLAs, unless they do certain things.
>
> Agreed. As I said before the tunnel LSP (and even
> the multiplexing LSP) could be tested using MPLS-ping.
> If the client/server mapping needs to be tested then client segment
> OAM should be used. If that is not available, then the client/server
> mapping can't be tested.
>
>
> -Shahram
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>