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

From: "Ping Pan" <[email-masked]>
Date: Mon, 28 Jun 2004 10:41:16 -0700

Hi,

Here is a brief note to point out that, instead of putting PW's over MPLS
LSP's,  PWE3 can be applied over sub-IP connections directly. The main
advantage here is that carriers can aggregate L2 flows over their existing
infrastructure before reaching to the IP/MPLS core.

Thanks!

- Ping

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Wednesday, June 23, 2004 1:47 PM
To: [email-masked]
Subject: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Dry-Martini: Supporting PWE3 Over Sub-IP Networks
	Author(s)	: P. Pan
	Filename	: draft-pan-pwe3-over-sub-ip-00.txt
	Pages		: 9
	Date		: 2004-6-23
	
This memo proposes a method for transporting layer-2 frames over existing
transport networks by establishing "pseudo-wires" between edge nodes. The
key difference with the existing PWE3 design is that, in our proposal,
pseudo-wires can be established directly on top of all types of "tunnels",
including SONET cross-connects, optical wavelength and ATM circuits without
introducing MPLS LSR functionality on all network intermediate nodes. The
general mechanism for establishing and managing pseudo-wires is the same as
what has been defined in draft-martini. At data forwarding level, we adapt
the same encapsulation methods that have been defined in IETF PWE3 WG. This
memo articulates some of the requirements for adapting such method.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pan-pwe3-over-sub-ip-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the
message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in, type
"cd internet-drafts" and then
	"get draft-pan-pwe3-over-sub-ip-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-pan-pwe3-over-sub-ip-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Shahram Davari <[email-masked]>
Date: Mon, 28 Jun 2004 13:18:03 -0700

Hi Ping,

Nice draft. In fact many implementations are already doing what this draft
suggests. So it would be nice to have it standardized.

Yours,
Shahram

-----Original Message-----
From: Ping Pan [mailto:[email-masked]]
Sent: Monday, June 28, 2004 1:41 PM
To: [email-masked]
Cc: Pan, Ping
Subject: [PWE3] FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt

Hi,

Thanks!

- Ping

-----Original Message-----

	

Send a message to:
	[email-masked].
In the body type:

---

From: "Ping Pan" <[email-masked]>
Date: Mon, 28 Jun 2004 13:28:58 -0700

Thanks! I would hope the scope of PWE3 architecture could be expanded as a
result.

One important motivation for the draft is that this is to emphasis the real
strength behind PWE3: it is the mechanism that can aggregate flow-2 flows
from network edge making it powerful. The backbone network itself could be
anything so long as it can present edge-to-edge tunnels that we can tcp LDP
messages through. :-)

Take care!

- Ping

> From: Shahram Davari [mailto:[email-masked]] 
> Sent: Monday, June 28, 2004 1:18 PM
> To: 'Ping Pan'; [email-masked]
> Cc: Pan, Ping
> Subject: RE: [PWE3] FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt
> 
> Hi Ping,
> 
> Nice draft. In fact many implementations are already doing 
> what this draft suggests. So it would be nice to have it standardized.
> 
> Yours,
> Shahram
> 
> Here is a brief note to point out that, instead of putting 
> PW's over MPLS LSP's,  PWE3 can be applied over sub-IP 
> connections directly. The main advantage here is that 
> carriers can aggregate L2 flows over their existing 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> This memo proposes a method for transporting layer-2 frames 
> over existing transport networks by establishing 
> "pseudo-wires" between edge nodes. The key difference with 
> the existing PWE3 design is that, in our proposal, 
> pseudo-wires can be established directly on top of all types 
> of "tunnels", including SONET cross-connects, optical 
> wavelength and ATM circuits without introducing MPLS LSR 
> functionality on all network intermediate nodes. The general 
> mechanism for establishing and managing pseudo-wires is the 
> same as what has been defined in draft-martini. At data 
> forwarding level, we adapt the same encapsulation methods 
> that have been defined in IETF PWE3 WG. This memo articulates 
> some of the requirements for adapting such method.
> 
> To remove yourself from the I-D Announcement list, send a 
> message to [email-masked] with the word 
> unsubscribe in the body of the message.  
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username "anonymous" and a password of your e-mail 
> address. After logging in, type "cd internet-drafts" and then
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
>

---

From: [email-masked]
Date: Tue, 29 Jun 2004 13:50:33 +0100

If I understand this draft correctly, looking at things from an IP/MPLS perspective, the proposal is to establish an IP/MPLS network using 1 hop point-to-point links between edge devices, with the point-to-point links being provided by a L1/L2 server layer. As far as IP/MPLS is concerned, the L1/L2 topology and switching/multiplexing that goes on between edge devices is transparent. I think it would be useful to highlight the benefits/drawbacks of this approach compared to the more common approach in which intermediate IP/MPLS routers are used, e.g. 

- Scalability is dependant on the L1/L2 technology used due to the number of physical/virtual bi-directional point-to-point connections/flows required, i.e. n(n-1)/2 for a full mesh

- The ability to affect per hop forwarding behaviour (at intermediate nodes) based on the EXP value in the MPLS header is not supported

- Resiliency needs to be implemented at L1/L2

Looking at things from a L1/L2 perspective, because IP is only implemented at the edge, this approach can be considered to be a L1/L2 technology independent adaptation function, where the L1/L2 server layer technology just needs to be able to carry MPLS packets. However, L1/L2 technologies already have their own adaptation/de-multiplexing functions, e.g. Ethernet has Ethertypes and VLANs, SDH/SONET has GFP and containers. Therefore, I think it would be useful to outline what some of the benefits/drawbacks/motivations of using the PW approach are, compared with existing mechanisms, e.g.

- Requires IP/MPLS support at the edge, whereas existing approaches don't 

- Offers a common signalling protocol and encapsulation method (which could potentially simplify provisioning/management)

- Existing technology specific adaptation mechanisms may be more (or less) bandwidth efficient 

- May offer improved scalability over some existing de-multiplexing mechanisms, e.g. 4K VLAN limit

Regards,

Richard

-----Original Message----- 
From: [email-masked] on behalf of Ping Pan 
Sent: Mon 28/06/2004 16:28 
To: Shahram Davari; [email-masked] 
Cc: Pan, Ping 
Subject: RE: [PWE3] FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt

	
	Take care!
	
	- Ping
	
	> version of the Internet-Draft.

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

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

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 29 Jun 2004 18:37:45 +0200

Richard and Ping,
Please see some comments/answers inline.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, June 29, 2004 2:51 PM
> To: [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]
> If I understand this draft correctly, looking at things from 
> an IP/MPLS perspective, the proposal is to establish an 
> IP/MPLS network using 1 hop point-to-point links between edge 
> devices, with the point-to-point links being provided by a 
> L1/L2 server layer. As far as IP/MPLS is concerned, the L1/L2 
> topology and switching/multiplexing that goes on between edge 
> devices is transparent. I think it would be useful to 
> highlight the benefits/drawbacks of this approach compared to 
> the more common approach in which intermediate IP/MPLS 
> routers are used, e.g. 
> 
>  
> 
> - Scalability is dependant on the L1/L2 technology used due 
> to the number of physical/virtual bi-directional 
> point-to-point connections/flows required, i.e. n(n-1)/2 for 
> a full mesh
>
[Sasha] I agree that scalability of the full mesh of transport
tunnels may be an issue. At the same time IMHO the comparison
with IP/MPLS is not always relevant since there are many
cases when intermediate nodes are not routers (as in the case
of SONET/SDH networks with the GFP functionality performed only
 at the edge). 
Note also that with IP/MPLS in functionality in the intermediate nodes
the desired scalability is only achieved with multipoint-to-point
tunnels.
> 
> - The ability to affect per hop forwarding behaviour (at 
> intermediate nodes) based on the EXP value in the MPLS header 
> is not supported
>
[Sasha] Agree. 
> - Resiliency needs to be implemented at L1/L2
[Sasha] Agree. However, with some technologies (e.g., SONET/SDH)
this is easy and provides excellent results.
>  
> 
> Looking at things from a L1/L2 perspective, because IP is 
> only implemented at the edge, this approach can be considered 
> to be a L1/L2 technology independent adaptation function, 
> where the L1/L2 server layer technology just needs to be able 
> to carry MPLS packets. However, L1/L2 technologies already 
> have their own adaptation/de-multiplexing functions, e.g. 
> Ethernet has Ethertypes and VLANs, SDH/SONET has GFP and 
> containers. Therefore, I think it would be useful to outline 
> what some of the benefits/drawbacks/motivations of using the 
> PW approach are, compared with existing mechanisms, e.g.
> 
[Sasha] I'd say that the strong side of the proposal is that
it provides a uniform approach to de-multiplexing and adaptation.
Among other things, this would allow end devices to operate
regardless of the specific transport technologies and to use a mix
of these technologies if necessary. Of course, per technology details
are welcome.
> - Requires IP/MPLS support at the edge, whereas existing 
[Sasha] I'd say that most devices support IP in some form today
(at least for the management purposes). The real problem (as
I see it) is the need to maintain multiple P2P interfaces in these
devices (scalability).
> 
> - Offers a common signalling protocol and encapsulation 
> method (which could potentially simplify provisioning/management)
> 
> - May offer improved scalability over some existing 
> de-multiplexing mechanisms, e.g. 4K VLAN limit
> 
>  
> 
> Regards,
> 
> Richard
> 
>  
> 
	> You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: Ping Pan <[email-masked]>
Date: Tue, 29 Jun 2004 19:58:49 -0700

Hi,

The goal of the draft is to allow the existing SONET/ATM infrastructure 
to aggregate layer-2 flows. There is no doubt in my mind that, 
eventually, the backbone itself will become IP/MPLS someday. The 
question is how to get there. Having that in mind, our proposal can be 
used to aggregate traffic from customer equipment to MSE's, or MSE's to 
MSA's. Thus, it will have the same scaling property as the SONET/ATM 
networks having today. No better, no worse!

> - The ability to affect per hop forwarding behaviour (at intermediate nodes) based on the EXP value in the MPLS header is not supported

This is exactly the point I brought up in the draft: when we start to 
transport traffic over sub-ip networks, we are likely dealing with 
transport carriers that sell QoS-guaranteed bandwidth for living. In 
this case, we need to have "hard" QoS enforcement at the edge. Not sure 
we need to compare MPLS QoS capability here.

> - Resiliency needs to be implemented at L1/L2

Careful. :-) It is not implementing resiliency and OAM. It is how best 
to interface the existing mechanisms. For example, if/when there is an 
AIS alarm in the SONET network, how can we translate and propagate such 
notification to the data network operators?

> - May offer improved scalability over some existing de-multiplexing mechanisms, e.g. 4K VLAN limit

Will add them in the next version. Thank you for the summary.

Regards,

- Ping

---

From: Ping Pan <[email-masked]>
Date: Tue, 29 Jun 2004 22:09:40 -0700

Sasha Vainshtein wrote:
> of these technologies if necessary.
> 

Exactly. I thought that was the intention of draft-martini.

---

From: Heiles Juergen <[email-masked]>
Date: Wed, 30 Jun 2004 14:25:15 +0200

It should be noted that for the transport over SONET/SDH, OTN or PDH additional functionality is needed, for example frame delineation in order to determine the start and length of the PW frame. Furthermore bit error detection capabilities could be requested. One can argue that for bit error detection the native methods of the L2 client signal can be used (e.g. Ethernet FCS) however a client independent method would be more useful.
With GFP SONET/SDH, OTN and PDH already provide such functionality. But GFP already supports the mapping of several L2/L1 signals like Ethernet, PPP/HDLC, MPLS, ESCON, FICON and is now widely introduced. What GFP is missing is an automatic setup like LDP signaling for PWs.

Regards

Juergen

> -----Ursprungliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]Im 
> Auftrag von
> Ping Pan
> Gesendet: Mittwoch, 30. Juni 2004 07:10
> An: Sasha Vainshtein
> Cc: Sharon Galtzur; [email-masked]; Alik Shimelmits;
> [email-masked]'
> Betreff: Re: [PWE3] FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt
> 
> 
> Sasha Vainshtein wrote:
> >

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 30 Jun 2004 15:31:07 +0200

Juergen and all,
To the best of my understanding GFP by itself does not provide
demultiplexing of L2 flows it carries. And the PTI value for MPLS is
not specified in G.7041-03 either (maybe it is specified somewhere else?).
The latter is a minor issue while the former is IMHO a real problem.
Using different (concatenated) SONET/SDH containers as the demultiplexers
clearly has scalability problems.

With best regards,
                                   Sasha Vainshtein

> From: Heiles Juergen [mailto:[email-masked]]
> Sent: Wednesday, June 30, 2004 2:25 PM
> To: 'Ping Pan'; Sasha Vainshtein
> Subject: AW: [PWE3] FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt
> 
> 
> It should be noted that for the transport over SONET/SDH, OTN 
> or PDH additional functionality is needed, for example frame 
> delineation in order to determine the start and length of the 
> PW frame. Furthermore bit error detection capabilities could 
> be requested. One can argue that for bit error detection the 
> native methods of the L2 client signal can be used (e.g. 
> Ethernet FCS) however a client independent method would be 
> more useful.
> With GFP SONET/SDH, OTN and PDH already provide such 
> functionality. But GFP already supports the mapping of 
> several L2/L1 signals like Ethernet, PPP/HDLC, MPLS, ESCON, 
> FICON and is now widely introduced. What GFP is missing is an 
> automatic setup like LDP signaling for PWs.
> 
> Regards
> 
> Juergen
> 
>

---

From: Heiles Juergen <[email-masked]>
Date: Wed, 30 Jun 2004 14:45:48 +0200

Sasha,

GFP support for direct mapping of MPLS was added at the last ITU SG15 meeting. It is part of a amendment to G.7041 which is currently in the final approval process. BTW MPLS over PW would also be needed in order to have a common mapping for all L2 clients.
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?

Regards

Juergen

> Von: Sasha Vainshtein [mailto:[email-masked]]
> Gesendet: Mittwoch, 30. Juni 2004 15:31
> An: 'Heiles Juergen'
> Cc: 'Ping Pan'; Sharon Galtzur; [email-masked]; Alik 
> Shimelmits; [email-masked]'
> Betreff: RE: [PWE3] FW: I-D ACTION:draft-pan-pwe3-over-sub-ip-00.txt
> 
> 
> Juergen and all,

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 30 Jun 2004 15:59:38 +0200

Juergen,
Lots of thanks for a prompt response and a clarification.
Please see also some comments inline.

With best regards,
                                   Sasha Vainshtein

> Sent: Wednesday, June 30, 2004 2:46 PM
> To: Sasha Vainshtein; Heiles Juergen
> GFP support for direct mapping of MPLS was added at the last 
> ITU SG15 meeting. It is part of a amendment to G.7041 which 
> is currently in the final approval process. 
>
[Sasha] Didn't know that. Hopefully it will be approved soon.
>
> 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?
>
> 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.

---

From: [email-masked]
Date: Wed, 30 Jun 2004 15:14:32 +0100

Folks,

I think we need to think this one out very carefully....speaking as an operator we need to understand what are the requirements that are being met and what are the business benefits.

For example, the (server layer) peer-partition OAM i/w problem just hi-lights one of these requirements, ie defect indication mapping to a common client is required and *not* between lower server layer peer-partitions.  But it seems there are other requirements that should be written down, for example:
-	client<=>server alignment....which includes rate-adaptation, idle-fill, packet delineation (with loss/recovery criteria....which itself generates a defect case)
-	client muxing/demuxing....which includes labels and some form of signalling of such (in-band or OOB?)
-	other?

PW_Martini is not a sufficient solution as it does not include clinet<=>server alignment, so it must still be used with GFP or PPP say.

GFP is a potentially complete solution as it can do client muxing/demuxing (albeit to the limits Juergen mentions).

We should also note that if we have the stack client/PW_martini/GFP/server this means we need OAM at *all* levels since we have a flow of server->GFP->PW_martini->client in terms of FDI mapping, and there are also potential defects at all levels.

Further, for arch valid co-ps/co-cs server layer networks the PW_martini CW is functionally redundant, ie we do not need compression, length and Seq Nos.....but noting that if Seq Nos are used (anywhere) they are still missing the definition of a defect entry/exit state for persistent aberration (maybe its still missing because no one uses them?).

Since we are going to need GFP anyway for the alignment, then why not just use this as it seems both simpler and more functionally complete?

regards, Neil

> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Heiles Juergen
> Sent: 30 June 2004 13:46
> To: 'Sasha Vainshtein'; Heiles Juergen
> Cc: Sharon Galtzur; [email-masked]; 'Ping Pan'; 
> Spencer,R,Richard,XGH5 R; Alik Shimelmits
> is currently in the final approval process. BTW MPLS over PW

---

From: Ping Pan <[email-masked]>
Date: Wed, 30 Jun 2004 19:50:17 -0700

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