Subject: Re: Draft Minutes from PWE3 at IETF54

From: Stewart Bryant <[email-masked]>
Date: Thu, 25 Jul 2002 11:38:50 +0100

The fragmentation exchange was long and complex, and very
difficult to minute.

Why don't we minute it as long complex with no descisions
and take it to the list.

The only agreement that I recall was that it was OK to make
answering signalled a fragmentation support request mandatory. 
Scott wanted fragmantation mandatory - as noted below, and I recall 
Kriti answered along the lines "that OK so long as I can answer 
'not supported'". There were others that wanted to mandate
fragmenting an ATM SDU in order to insert an OAM cell in
exactly the right spot. I noted an order preservation issue.

Stewart

"Andrew G. Malis" wrote:
> 
> Comments inline ....
> 
> At 7/24/2002 06:50 AM -0600, Danny McPherson wrote:
> 
> >Thanks to Jeremy Brayley for recording these!
> >
> >Comments/corrections?
> >
> >-danny
> >
> >-----------------------------------------------------------------
> >PWE3 Fragmentation and Reassembly - Andy Malis
> >draft-malis-pwe3-fragmentation-00.txt
> >
> >Fragmentation is required to send a frame larger than that supported by the
> >PSN
> >Want a single set of Fragmentation/Reassembly procedures rather than
> >specifying the procedures in each PWE3 service draft
> >
> >Procedures adopted directly from RFC 1990 MLPPP
> >         Also used by FRF.12 and ATMF FAST
> >Bit usage inverted from RFC1490
> >Therefore not-fragmented packet looks the same as a packet from a PE that
> >doesn't implement fragmentation
> >Signaling additions - New VCFEC element parameter ID to signal the ability
> >to reassemble fragments
> >         Two new L2TP AVP pairs
> >
> >Scott Bradner - questions why reassembly is optional.  He believes it should
> >be mandatory or not used at all
> >Andy - PSN MTUs are typically limited to 9K bytes
> >Scott - The question of whether to signal the ability to fragment and
> >        whether to implement fragmentation are orthogonal
> >         If mandatory to implement, you can still use slowpath even if it
> >        doesn't work well
> 
> I don't think this quite reflected the exchange, although Scott was quoted
> accurately.
> 
> My primary point in the discussion was that I personally had no problem
> with Scott's suggestion that reassembly be made mandatory, even though the
> specified signaling is pretty simple.
> 
> Other speakers disagreed and felt that the ability reassembly shouldn't be
> required, and that the signaling should be retained.  As I recall, the
> conclusion was to take the discussion to the list.
> 
> >-----------------------------------------------------------------------
> >Andy Malis   - Frame Relay draft
> >         no slides - We have seen the presentation too many times already
> >         Have reached agreement on encapsulation
> >         Must decide how to organize documents (1 doc, 2 docs ?)
> 
> I said that the discussion at this point is strictly editorial on document
> organization.
> 
> Thanks,
> Andy
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 25 Jul 2002 12:17:18 +0100

So now lets start the fragmentation thread.

I think the issues are:

1) Some applications require fragmentation

Operating a L2VPN over a PW might easily hit the MTU limit
of the underlying PSN. A route flap in the PSN might invalidate
any path configuration designed to work around MTU limits.
In some circumstances path engineering might not be possible.

Some ATM circuits want to have the data-compression advantage
of SDU, but need to preserve the positional order of OAM, and
see fragmentation as the solution.

others....

2) Some implementations can only support slow path fragmentation

Fragmentation (well normally re-assembly) is memory and CPU 
intensive and some hardware designs cannot support it. Frames needing 
fragmention support are sent to a slower, more general purpose, 
software forwarding engine.

The exact processing operation depend on the internal details
of the payloads being carried over the PW. For example, if
it is known a priori that the protocol carried is not order
sensitive (ie IP), then it is acceptable to just slow path
those packets that need fragmentation support. However if
the order is important, ie a wire emulation, then
order requirements may mean that all PWE3 packets need to follow
the slow path. 

3) Some existing implementations cannot even slow path fragmentation

As it says.

4) Slow path fragmentation may invalidate a wire emulation

If the PW is emulating a high-speed order-sensitive circuit
and the slow path cannot maintain the performance (think 10Gb/s
for a moment), then the PW service cannot be provided. This 
would be unfortunate when it turned out that fragmentation
was not needed, and the only thing standing in the way of 
deployment was a line in an RFC.

5) We need a common interworking definition

There needs to be a common agreed reference baseline to promote
interworking.

My view is that the baseline should just require signalling
fragmentation request/response, and MAYBE some defined
behaviour when fragmentation was required but not available
during the lifetime of a PW. However it should not be
mandatory to support payload fragmentation.

Stewart

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 25 Jul 2002 09:36:29 -0400

Stewart,

>deployment was a line in an RFC.

I'm curious which line in an RFC you're concerned about.  If you don't need 
fragmentation, then everything works fine.  But if you DO need 
fragmentation (say, in order to send 9K Ethernet jumbograms or AAL5 SDUs 
over a path with a 1500-octet MTU), then there is no alternative other than 
not providing the pseudo-wire service at all.  You seem to be saying that 
because some existing implementations can't support reassembly in the fast 
path, we shouldn't be doing it all.  Or maybe I misunderstood your message.

Cheers,
Andy

---

From: Eric Rosen <[email-masked]>
Date: Thu, 25 Jul 2002 10:11:25 -0400

Scott> If  mandatory to implement,  you can  still use  slowpath even  if it
Scott> doesn't work well

I'd have to disagree with this.  

I think that fragmentation is only needed on a frame relay pseudowire if (a)
the CEs  are supporting a large  MTU, (b) the CEs  cannot themselves support
frame relay  fragmentation, (c) it is  infeasible to change the  MTUs on the
CE.

In this situation, there is no  reason to suppose that fragmentation will be
uncommon; indeed, it might be quite common. 

It  is only acceptable  to implement  a feature  in slowpath  if its  use is
uncommon. 

What  I  conclude  is  that  there  is  no  point  to  providing  fragmenta-
tion/reassembly for  frame relay  pseudowires in slowpath.   If it  can't be
provided in fastpath, you might as well omit it. 

Stewart> Some applications require fragmentation

I think the important question is whether Service Providers have any use for
a PWE3 mechanism which can't  fragment.  In deploying such a mechanism, they
would have to specify the MTU,  and they wouldn't be able to provide service
to customers that require a larger MTU. 

Stewart> Fragmentation  (well  normally   re-assembly)  is  memory  and  CPU
Stewart> intensive and some hardware designs cannot support it. 

This  is  certainly  true  of  IP   reassembly.   But  if  we  have  a  PWE3
fragmentation function  in which it is  allowable to discard a  frame if its
fragments do not arrive in order, it's not quite as difficult, especially if
we can  start transmitting a frame to  the CE before all  the fragments have
arrived. Of course, it's still far from being free.
          
Stewart> My  view  is  that  the  baseline should  just  require  signalling
Stewart> fragmentation  request/response, and  MAYBE some  defined behaviour
Stewart> when  fragmentation  was  required  but not  available  during  the
Stewart> lifetime of  a PW.  However it should  not be mandatory  to support
Stewart> payload fragmentation.  

I agree.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 25 Jul 2002 17:15:00 +0100

> path, we shouldn't be doing it all.  Or maybe I misunderstood your message.

Right, if you need fragmentation, you need it.

If we follow Scott's line of reasoning, then fragmentation becomes mandatory 
ie no frag, no RFC compliance.

I am not sure that is reasonable.

Stewart

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 26 Jul 2002 02:03:56 -0400

Stewart,

>I am not sure that is reasonable.

What Scott said was the receiver must always support reassembly so that it 
doesn't need to signal whether or not it CAN reassemble to the 
transmitter.  He made no statement about the transmitter.

Cheers,
Andy

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 26 Jul 2002 09:59:55 +0100

> transmitter.  He made no statement about the transmitter.

But receive fragmentation is meaningless unless it is fast enought
to support the service. 

Stewart