Subject: AW: FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt

From: Heiles Juergen <[email-masked]>
Date: Thu, 1 Jul 2004 09:13:05 +0200

Sasha,

see my comments below.

Regards

Juergen

.....

> > BTW MPLS over PW 
> > would also be needed in order to have a common mapping for 
> > all L2 clients.
> >
> [Sasha] Sorry, I do not understand why this is needed. Can
> you elaborate?
> >

MPLS can be a L2 signal like ATM and Ethernet and has to be supported over Sonet/SDH and OTN (see the MPLS GFP mapping above). In case the PW is used as a common encapsulation and multiplexing mechanism for all L2 signals it should also support MPLS like it supports ATM or Ethernet.

> > GFP allows for multiplexing of 256 client signals/flows with 
> > the Channel ID field of the linear extension header. 256 
> > seems not to be much, but how often will you have 256 
> > different client signals/flows/services between the same two 
> > end points?
> >
> [Sasha] This is correct even if I do not know whether linear extension
> headers are supported by the existing implementation and deployed.
> But I am not sure your remark about 256 different cliets between
> the same two end points is justified: G.7041 is not very clear
> about the CID space (per trail or global). 
> And, IMHO, the strong side of draft-pan is about ONE demultiplexing
> mechanism
> for all kinds of server-client relationships.
> > 
Demultiplexing is only a small part of the overall functionality at the PE. You need frame delineation, supervision and native service processing which will always be client signal specific. GFP has some functions which are missing in a PW and the PW has some functions which are not supported by GFP (e.g. signaling). May be we can combine them if needed.

....

---

From: Luis Aguirre <[email-masked]>
Date: Thu, 1 Jul 2004 00:24:34 -0800

I agree we should be careful in how we present things:

Martini PWs are a good method for aggregating and transporting L3/L2 and L2
services across the metro and core transport networks (CPE to MSE or between
MSEs across an optical core.) However, PW technology by itself is not enough
to provide an economic incentive for service providers to move in this
direction and change their service definition. Remember that some of the
reasons some large service providers (according to different sources such as
Light Reading) are actively looking into this is, among other things, to
reduce the cost structure of the Metro/access network and move a step closer
towards the integration of the metro and core data networks. The existing
metro transport network infrastructure, primarily SONET/SDH, has been
optimized to carry private line and conventional voice - transport of data
services, in any form, is sub-optimal. A flexible frame delineation
mechanism (i.e. GFP) to map data services (e.g. HDLC or Ethernet frames as
MPLS packets) into SONET, as well as service adaptation and possibly inverse
multiplexing techniques are definitively required to fully realize the
benefits of aggregating and transporting data services in the direction of
and between network service edge NEs. Aggregating data flows using PWs will
remain an academic exercise unless service providers are presented with the
economic incentive and a complete architecture, including OAM and end-to-end
CoS differentiation to comply with service and customer specific SLAs.  

Luis

-----Original Message-----
From: Ping Pan [mailto:[email-masked]] 
Sent: Thursday, July 01, 2004 4:50 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [PWE3] FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt

Hi,

The way this thread is going, I think we need to be careful:

First, dry-martini is a proposal to aggregate flow over ANY media types, 
not for SONET/SDH only. I do aware of the ITU attempt to support 
GFP/MPLS/PW switching in the core. But our idea is much generic and 
flexible here. As far as I am concerned, we can aggregate a bunch of 
Ethernet or ATM flows over a WiMax connection using 
martini-encapsulation, and target LDP. :-)

In terms of OAM, it has been a touchy issue for a long time. At the end 
of the day, we need to provide a combination of LSP-ping, VCCV, BFD, 
SONET PM, ATM OAM, Ethernet Mibs, AAA, billing... to the carriers, 
a.k.a. a clean OSS solution (or get HeavyReading to run another survey 
on the topic :-)). To avoid getting side-tracked, we intentionally 
avoided OAM discussion in the draft. If people like to work on it, let's 
talk off-line.

All we are proposing here is to re-use draft-martini to transport data 
over packet/circuit networks!

(By the way, I have no problem with GFP itself. I am just not sure why I 
need it for traffic aggregation at edge. In fact, I have the GFP-F, 
VCAT, LCAS, the whole nine-yard running in my lab. The only useful GFP 
application I can see so far is the function of sending EFFI as client 
frame to notification link outage when I pull a client port. Other than 
that, GFP is a simpler version of GRE to me, IMHO. :-) From packet 
encapsulation point of view, I can find a half dozen vendors that can 
support draft-martini on the MAC/Mapper/Framer chips today, but not a 
single one that would allow me to modify GFP extension headers. :-()

2 cents,

- Ping

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

---

From: [email-masked]
Date: Thu, 1 Jul 2004 10:22:40 +0100

Bang on the money Luis.  If we do not see a sound commercial reason (backed up by technical correctness/efficacy) then why should we do it?

And OAM should not be an afterthought either.....do folks remember the BOF we ran a couple of years ago and were told by a few vendors that MPLS OAM was not required (I seem to recall we were told to (paraphrased) 'go buy kit from vendors who don't have problems....don't add OAM to fix problems')  Seems there has been a significant change of heart now......but of course only to OAM that suits ;-)

Irrespective of the protocols we finally decide on here, the functions (and order of processing) are the same.  And I also wish folks would stop pushing this notion of 'PWs' here.....this has nothing to do with 'PWs' or the so-called Martini CW (which is effectively redundant for a well-behaved co-ps or co-cs server layer network).  This is all to do with:
-	adopting LDP signalling
-	using the shim header for muxing/demuxing

So its a limited case of MPLS deployment and the notion of PWs is a misleading issue IMO, eg suppose we wanted to carry ATM over SDH say....do you really think we would do ATM->Martini_CW(set to null)->LDP_shim-header->GFP->VC4 etc....I think you might find we would do ATM->VC4 in this case.  Same goes for ethernet over SDH, but here GFP would be used as eth->GFP->VC4 and not eth->Martini_CW(set to null)->LDP_shim-header->GFP->VC4.

regards, Neil

> From: Luis Aguirre [mailto:[email-masked]]
> Sent: 01 July 2004 09:25
> To: 'Ping Pan'; Harrison,N,Neil,IKR2 R
> Cc: [email-masked]
> Subject: RE: [PWE3] FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt
> 
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 1 Jul 2004 10:42:51 -0400

This is definitely one of those rare occasions where Neil and
I agree completely. *)  In addition to the MIB support which is
generally mandatory, we should make it a requirement to build OAM
functionality into new solutions like this one from the get-go.

	--Tom

> Bang on the money Luis.  If we do not see a sound commercial reason 
> (backed up by technical correctness/efficacy) then why should we do 
> it?
>
> And OAM should not be an afterthought either.....do folks remember the 
> BOF we ran a couple of years ago and were told by a few vendors that 
> MPLS OAM was not required (I seem to recall we were told to 
> (paraphrased) 'go buy kit from vendors who don't have 
> problems....don't add OAM to fix problems')  Seems there has been a 
> significant change of heart now......but of course only to OAM that 
> suits ;-)
>
> Irrespective of the protocols we finally decide on here, the functions 
> (and order of processing) are the same.  And I also wish folks would 
> stop pushing this notion of 'PWs' here.....this has nothing to do with 
> 'PWs' or the so-called Martini CW (which is effectively redundant for 
> a well-behaved co-ps or co-cs server layer network).  This is all to 
> do with:
> So its a limited case of MPLS deployment and the notion of PWs is a 
> misleading issue IMO, eg suppose we wanted to carry ATM over SDH 
> say....do you really think we would do ATM->Martini_CW(set to 
> null)->LDP_shim-header->GFP->VC4 etc....I think you might find we 
> would do ATM->VC4 in this case.  Same goes for ethernet over SDH, but 
> here GFP would be used as eth->GFP->VC4 and not eth->Martini_CW(set to 
> null)->LDP_shim-header->GFP->VC4.
>
> regards, Neil
>

---

From: Ping Pan <[email-masked]>
Date: Thu, 01 Jul 2004 07:45:13 -0700

Luis Aguirre wrote:
> Aggregating data flows using PWs will

Good comment. Does this statement hold for both PW-over-MPLS and 
PW-over-sub-ip? It sounds it applies to both.

Regards,

- Ping

---

From: [email-masked]
Date: Fri, 2 Jul 2004 09:38:19 +0200

I am a little bit lost in this discussion.

IMO, if we have a sub-IP tunnel like an SDH VC4 trail, between two PEs (let's
call them PE1 and PE2) and MPLS on top of it, then from the MPLS perpective the
two PEs are adjacent PE.

This case of adjacent PE seems to me already covered by the current Martini
draft: the tunnel label is not used and only the PW label is used.

In this scenario, I can apply whatever PW OAM tool I have for the more general
case addressed by the Martini draft.

Am I missing something?

Thanks, Italo

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Thomas D. Nadeau
> Sent: Thursday, July 01, 2004 16:43
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]

---

From: [email-masked]
Date: Fri, 2 Jul 2004 11:46:42 +0100

Are you familar with G.805 Italo?  If not, then may I suggest a look at G.805 might help (or better, a read of chapter 3 of Reid/Sexton 'BB networking' or even go talk to Maarten Vissers of your company).  The key issue Tom is now raising (and I have since forever it seems) is that when we create a layer network, the OAM for that layer network is an important intrinsic functional component that *must* be incorporated into the design (of the data-plane) from t=0....not addded later as an afterthought.

Further, when the layer network concerned belongs to either the co-cs or co-ps modes the control (and management) plane protocols can exist OOB wrt to the traffic data-plane (and there are actually very good reasons for doing this, security being one reason).  This makes the (taffic) data-plane OAM absolutely essential.

Now G.805 defines the concepts of layering (ie vertical client/server relationships between layer networks) and partitioning (where we can break down a layer network horizontally into various levels of detail in terms of subnetworks (these are not IP subnetworks), links, connection-points, adaptation functions, and trail termination functions amongst others).  This is all quite important for defining equipment specifications and in particular the network management information models (if you know any TMF folks or SG15 folks go talk to them and they will reinforce this point).

In a client/server relationship the client and server layer networks are often not owned by the same party.....so a golden rule here is layer independence.  From the fault management perspective each layer network therefore must have its own OAM.

Now there are 3 networks modes, viz: cl-ps, co-ps and co-cs and all technologies map to one of these modes.  The 'goodness' of the technology is determined by how complete its functional specification is (inc OAM) and whether it respects the connectivity constraints of the mode it belongs to.  The behaviour of each mode is quite different, and this includes the types of defects that can occur in each mode....they are for sure not the same.

The are 9 possible client/server relationships between the 3 modes....some make more sense than others (you can figure that one out yourself), but the principle I mentioned above still holds, ie each layer network must be independent and have its own OAM.

Hope that helps paints (some of) the bigger picture here for you.

regards, Neil

> From: [email-masked] [mailto:[email-masked]]
> Sent: 02 July 2004 08:38
> To: Thomas D. Nadeau; Harrison,N,Neil,IKR2 R
> Cc: Flavin,AJ,Tony,XGH6 FLAVINAJ R; [email-masked];
> [email-masked]; Mcguire,A,Alan,XGH6 MCGUIRA R; [email-masked]
> Subject: RE: FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt
> 
> 
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > Thomas D. Nadeau

---

From: Ping Pan <[email-masked]>
Date: Fri, 02 Jul 2004 06:48:19 -0700

> draft: the tunnel label is not used and only the PW label is used.

Yeap! In which case, the PE's do not need to be MPLS LER's.

> case addressed by the Martini draft.

If everything is MPLS LER and LSR, then the entire suite of MPLS and IP 
tools would apply to the problem. However, in this case, it is a sub-IP 
network connecting the PE's. We may need to interface the sub-IP OAM to 
the PW OAM IF/WHEN NECESSARY.

In your example of SDH VC4 trail, yes, we need to interface SONET/SDH PM 
and alarms to PW layer. If the sub-IP tunnel is an ATM connection, we 
will have more things to interface with, unfortunately. :-) But if the 
sub-IP tunnel is a Gigabit Ethernet tunnel, unless ITU defines Ethernet 
PM and alarms, the life is good. :-)

Hope this has explained it.

Thanks!

- Ping