Subject: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Fri, 15 Apr 2011 11:52:11 +0200

During the Prague PWE3 meeting, there was a discussion on whether draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt should be adopted as a WG draft. The minutes of this discussion are posted at: http://tools.ietf.org/wg/pwe3/minutes?item=minutes80.html

We would like to ask the same question on the list.

Please post any comments before April 29th.

Regards,

Matthew & Andy

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 17 Apr 2011 06:38:51 +0000

> During the Prague PWE3 meeting, there was a discussion on whether draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt 
> should be adopted as a WG draft. 
> The minutes of this discussion are posted at: http://tools.ietf.org/wg/pwe3/minutes?item=minutes80.html

> We would like to ask the same question on the list.

I do not support making this a WG draft, as I do not believe that the efficiency gained merits the added complexity.

As an aside, the second PW device I worked on addressed bandwidth efficiency issues
by performing speech compression on timeslots of TDM PWs,
data compression on Ethernet frames for Ethernet PWs, 
and protocol compression for various cellular framing schemes.
This device once sold strongly (not surprising since ROI was less than 6 months), 
but its sales are now limited to niche markets, such as satellite backup links.
Even with bandwidth reduction factors of 4 or greater, 
the SP community no longer deems it worthwhile to perform bandwidth optimization.

I remember that at the meeting Sasha proposed creating a new GRE PW type to handle cases
where the overhead of the present PPW is deemed excessive. 
Perhaps this idea is worth discussing.

Y(J)S

---

From: Renwei Li <[email-masked]>
Date: Mon, 18 Apr 2011 17:26:31 +0000

I'd like to support it for multiple reasons:

-          It minimizes the chance of having an MPLS-encapsulated packet fragmented in the network due to the MTU limit, since the header is smaller and thus the whole packet size is smaller.
-          In addition to the bandwidth efficiency the author claims, I believe that it can be used to support heterogeneous ACs. For example, on one side the AC is Ethernet while the other side AC is ATM AAL5 (I would appreciate it if the authors could confirm it)
-          I have heard of some proprietary implementations for IP packet over PWE3 from different vendors. A spec like this could be used as a basis for inter-op.

 Thanks,

Renwei

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bocci, Matthew (Matthew)
Sent: Friday, April 15, 2011 2:52 AM
To: [email-masked]
Subject: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt

Regards,

Matthew & Andy

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 18 Apr 2011 11:29:06 -0700

Thanks Renwei.

Correct that this encapsulation can be used for heterogeneous packet
ACs such as ethernet and ATM-AAL5.

On Mon, Apr 18, 2011 at 10:26 AM, Renwei Li <[email-masked]> wrote:
> I’d like to support it for multiple reasons:
>
>
>
> -          It minimizes the chance of having an MPLS-encapsulated packet
> fragmented in the network due to the MTU limit, since the header is smaller
> and thus the whole packet size is smaller.
>
> -          In addition to the bandwidth efficiency the author claims, I
> believe that it can be used to support heterogeneous ACs. For example, on
> one side the AC is Ethernet while the other side AC is ATM AAL5 (I would
> appreciate it if the authors could confirm it)
>
> -          I have heard of some proprietary implementations for IP packet
> over PWE3 from different vendors. A spec like this could be used as a basis
> for inter-op.
>
>
>
>
>
>  Thanks,
>
>
>
> Renwei
>
>
>
>
>
>
>
> Subject: [PWE3] Discussion on
> draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt
>
>
>
> During the Prague PWE3 meeting, there was a discussion on
> whether draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt should be adopted
> as a WG draft. The minutes of this discussion are posted
> at: http://tools.ietf.org/wg/pwe3/minutes?item=minutes80.html
>
>
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>
>

-- 
- Sri

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 18 Apr 2011 20:15:22 +0100

On 18/04/2011 18:26, Renwei Li wrote:
> -It minimizes the chance of having an MPLS-encapsulated packet 
> fragmented in the network due to the MTU limit, since the header is 
> smaller and thus the whole packet size is smaller.
>
There is no fragmentation of MPLS packets.
>
> -In addition to the bandwidth efficiency the author claims, I believe 
> that it can be used to support heterogeneous ACs. For example, on one 
> side the AC is Ethernet while the other side AC is ATM AAL5 (I would 
Both pkt PW methods do that. That is one of their purposes.
>
> -I have heard of some proprietary implementations for IP packet over 
> PWE3 from different vendors. A spec like this could be used as a basis 
> for inter-op.
>
Both pkt PW methods do that.

- Stewart

---

From: John E Drake <[email-masked]>
Date: Mon, 18 Apr 2011 13:15:40 -0700

Matthew,

I don't think this should adopted as a WG draft.  The right way to do this is to use the packet transport service described in section 3.4.5 of RFC5921.

Thanks,

John

Sent from my iPhone

Regards,

Matthew & Andy

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Mon, 18 Apr 2011 23:25:46 +0200

Hi *,

I agree with John (No support for adopting this work). The slightly better overhead does not pay off for the complexities introduced with this solution. A packet transport service is a better solution for this problem.
Cheers,
Wim

From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: maandag 18 april 2011 22:16
To: Bocci, Matthew (Matthew); [email-masked]
Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt

Matthew,

Thanks,

John

Sent from my iPhone

Regards,

Matthew & Andy

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 18 Apr 2011 15:12:23 -0700

John,

Are you suggesting that instead of (packet) PW adaptation, the network
layer adaptation of MPLS-TP be used ? What if the network does not
support MPLS-TP ? The network-layer adaptation also brings additional
encap-label and its associated signaling. So there is additional data
and control plane overhead and the service is not transparently
carried. E.g. if the service has to carry a layer-2 packet such as
LLDP, I don't think it is straightforward.

Thanks

On Mon, Apr 18, 2011 at 1:15 PM, John E Drake <[email-masked]> wrote:
> Matthew,
>
>
>
> I don’t think this should adopted as a WG draft.  The right way to do this
> is to use the packet transport service described in section 3.4.5 of
> RFC5921.
>
>
>
> Thanks,
>
>
>
> John
>
>
>
> Sent from my iPhone
>
>
>

-- 
- Sri

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 18 Apr 2011 18:19:44 -0400

I am with John on this one; do not support.

Tom

On Apr 18, 2011, at 4:15 PM, John E Drake <[email-masked]> wrote:

> Matthew,
> 
>  
> 
> I don’t think this should adopted as a WG draft.  The right way to do this is to use the packet transport service described in section 3.4.5 of RFC5921.
> 
>  
> 
> Thanks,
> 
>  
> 
> John
> 
>  
> 
> Sent from my iPhone
> 
>  
>

---

From: Renwei Li <[email-masked]>
Date: Mon, 18 Apr 2011 22:38:35 +0000

Hi Wim,

If you use the packet transport service, you still have the complexity issue.

It is my understanding the draft is not just about the header overhead. Actually I weigh more on supporting heterogeneous ACs than on reducing header overhead.

Thanks,

Renwei

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henderickx, Wim (Wim)
Sent: Monday, April 18, 2011 2:26 PM
To: John E Drake; Bocci, Matthew (Matthew); [email-masked]
Subject: Re: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt

Hi *,

Cheers,
Wim

Matthew,

Thanks,

John

Sent from my iPhone

Regards,

Matthew & Andy

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Tue, 19 Apr 2011 00:47:44 +0200

Renwei,

Look at http://tools.ietf.org/html/draft-ietf-pwe3-packet-pw-00
We analyzed the different options and the decision is in there

Cheers,
Wim

From: Renwei Li [mailto:[email-masked]]
Sent: dinsdag 19 april 2011 0:39
To: Henderickx, Wim (Wim); John E Drake; Bocci, Matthew (Matthew); [email-masked]
Subject: RE: [PWE3] Discussion on draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt

Hi Wim,

Thanks,

Renwei

Hi *,

Cheers,
Wim

Matthew,

Thanks,

John

Sent from my iPhone

Regards,

Matthew & Andy

---

From: John E Drake <[email-masked]>
Date: Mon, 18 Apr 2011 15:57:25 -0700

Sent from my iPhone

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Sriganesh Kini
> Sent: Monday, April 18, 2011 3:12 PM
> To: John E Drake
> Cc: Bocci, Matthew (Matthew); [email-masked]
> support MPLS-TP ?

JD:  The packet transport service is defined in the context of the MPLS-TP framework RFC but it is actually independent of MPLS-TP.

> The network-layer adaptation also brings additional
> encap-label and its associated signaling.

JD: There is targeted signaling for each packet type (IP v4 and v6, MPLS (upstream/downstream labels), OSI) and an associated label.  This is actually already supported in RSVP-TE signaling, so there is an existence proof.

> So there is additional data

JD:  It is a (network layer) packet transport service.  L2 frames are not carried over it.  Which also means, by definition, that the access circuits are heterogeneous.

> > I don't think this should adopted as a WG draft.  The right way to do
> this
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> > Bocci, Matthew (Matthew)
> >

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 18 Apr 2011 19:24:00 -0400

Yes, the analysis is indeed there. FYI, from the Introduction:

1.  Introduction

   There is a need to provide a method of carrying a packet service over
   an MPLS PSN in a way that provides isolation between the two
   networks.  The server MPLS network may be an MPLS network or a
   network conforming to the MPLS-TP [RFC5317].  The client may also be
   either a MPLS network of a network conforming to the MPLS-TP.
   Considerations regarding the use of an MPLS network as a server for
   an MPLS-TP network are outside the scope of this document.

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 18 Apr 2011 16:24:00 -0700

inline @ [Sri]

> JD:  The packet transport service is defined in the context of the MPLS-TP framework RFC but it is actually independent of MPLS-TP.

[Sri] So I take it that your comment applies to
draft-ietf-pwe3-packet-pw-00. The network-layer adaptation is similar
to the "Parallel PWs" approach in sec 6.3 of that doc and there is a
listing of ".. serious downsides .." in that section as well.

> JD: There is targeted signaling for each packet type (IP v4 and v6, MPLS (upstream/downstream labels), OSI) and an associated label.  This is actually already supported in RSVP-TE signaling, so the…

[Sri] Can you elaborate. Are you suggesting targeted RSVP-TE
signalling to support network-layer adaptation ?

> JD:  It is a (network layer) packet transport service.  L2 frames are not carried over it.  Which also means, by definition, that the access circuits are heterogeneous.

[Sri] See the intro section of draft-ietf-pwe3-packet-pw-00 sec 1
(Intro) that lists LLDP exchanged between clients (e.g. MPLS LSRs) and
further "... two clients require an attachment mechanism that can be
used to multiplex a number of protocols. In addition it is essential
to the correct operation of the network layer that all of these
protocols fate share."

How can this requirement be met by a (network layer) packet transport service ?

-- 
- Sri

---

From: John E Drake <[email-masked]>
Date: Mon, 18 Apr 2011 16:59:32 -0700

Snipped...

Sent from my iPhone

> > JD:  The packet transport service is defined in the context of the
> MPLS-TP framework RFC but it is actually independent of MPLS-TP.
> 

JD:  No, my comment has nothing to do with that draft.

> > JD: There is targeted signaling for each packet type (IP v4 and v6,
> MPLS (upstream/downstream labels), OSI) and an associated label.  This
> is actually already supported in RSVP-TE signaling, so there is an
> existence proof.
> 

JD:  No, I was merely pointing out that this is how RSVP-TE works. 

> > JD:  It is a (network layer) packet transport service.  L2 frames are
> not carried over it.  Which also means, by definition, that the access
> circuits are heterogeneous.
> 

JD:  For a given link layer access circuit, there may need to be link layer protocols between a (CE, PE) pair.  

> >> > whether draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt should
> be
> >> adopted

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 18 Apr 2011 17:41:41 -0700

inline @ [Sri]

> JD:  No, my comment has nothing to do with that draft.

[Sri] You had suggested that instead of packet PW, the network layer
adaptation should be used. Is there any difference between the
"Parallel PW" approach in the draft and the netw-layer adaptation and
if so what are they ? If it is similar how does it address the issues
listed in the draft ?

> JD:  No, I was merely pointing out that this is how RSVP-TE works.

[Sri] But it still adds additional overhead (both data-plane and signaling).

> JD:  For a given link layer access circuit, there may need to be link layer protocols between a (CE, PE) pair.

[Sri] So it doesn't meet the requirements. Also, this adds more
complexity in the PE to terminate every link-layer protocol. And what
if that protocol needs info from the CE at the other end ?

-- 
- Sri

---

From: John E Drake <[email-masked]>
Date: Mon, 18 Apr 2011 17:52:55 -0700

W(hatever)

Sent from my iPhone

On Apr 18, 2011, at 8:42 PM, "Sriganesh Kini" <[email-masked] 
 > wrote:

>>> How can this requirement be met by a (network layer) packet  
>>> transport
>>> service ?
>>
>> JD:  For a given link layer access circuit, there may need to be  
>> link layer protocols between a (CE, PE) pair.
>
>>>>>> I don't think this should adopted as a WG draft.  The right way  
>>>>>> to
>>> do
>>>>> this

---

From: Giles Heron <[email-masked]>
Date: Tue, 19 Apr 2011 10:39:07 +0100

Hi Renwei,

To your last point about ³proprietary implementations for IP packet over
PWE3².  There¹s already a standard encapsulation for IP packet over PWE3.
It is documented in section 4.1 of RFC4447.

Giles

On 18/04/2011 18:26, "Renwei Li" <[email-masked]> wrote:

> I¹d like to support it for multiple reasons:
>  
> -         In addition to the bandwidth efficiency the author claims, I believe
> that it can be used to support heterogeneous ACs. For example, on one side the
> AC is Ethernet while the other side AC is ATM AAL5 (I would appreciate it if
> the authors could confirm it)
> -         I have heard of some proprietary implementations for IP packet over
> PWE3 from different vendors. A spec like this could be used as a basis for
> inter-op.
>  
>  
>  Thanks,
>  
> Renwei
>  
>  
>  
> 
> 
> During the Prague PWE3 meeting, there was a discussion on whether
> draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt should be adopted as a WG
> draft. The minutes of this discussion are posted at:
> http://tools.ietf.org/wg/pwe3/minutes?item=minutes80.html
> 
>  
>

---

From: Giles Heron <[email-masked]>
Date: Tue, 19 Apr 2011 13:04:51 +0100

Right.

On the basis that draft-ietf-pwe3-packet-pw looks like the right solution to
the problem, I for one wouldn¹t support
draft-kini-pwe3-pkt-encap-efficient-ip-mpls.

Giles

On 18/04/2011 23:47, "Henderickx, Wim (Wim)"
<[email-masked]> wrote:

> Subject: RE: [PWE3] Discussion on
> It is my understanding the draft is not just about the header overhead.
> Actually I weigh more on supporting heterogeneous ACs than on reducing header
> overhead. 
>  
>  
> Thanks,
>  
> Renwei
>  
>  
>  
> 
> 
> Subject: Re: [PWE3] Discussion on
> I agree with John (No support for adopting this work). The slightly better
> overhead does not pay off for the complexities introduced with this solution.
> A packet transport service is a better solution for this problem.
>  
> Cheers,
> Wim
>  
> 
> Subject: Re: [PWE3] Discussion on
> I don¹t think this should adopted as a WG draft.  The right way to do this is
> to use the packet transport service described in section 3.4.5 of RFC5921.
>  
> Thanks,
>  
> John 
>  
> 
> Sent from my iPhone
>  
>

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 19 Apr 2011 16:06:32 -0400

In message <[email-masked]>
"Bocci, Matthew (Matthew)" writes:
>  
> During the Prague PWE3 meeting, there was a discussion on whether draft-kin> i-pwe3-pkt-encap-efficient-ip-mpls-02.txt should be adopted as a WG draft. > The minutes of this discussion are posted at: http://tools.ietf.org/wg/pwe3> /minutes?item=minutes80.html
>  

I do not support this becoming a WG draft.