Subject: Proposed changes to draft kamapabhava-01

From: "Claude Kawa"<[email-masked]>
Date: Thu, 18 Apr 2002 22:29:23 -0400

I would like to propose changes to draft kamapabhava-01 taking into account
the comments received the last few days in order to progress this work. I
will be able to produce a new draft in 2-3 weeks (next week I am out of the
office).

Proposed changes to draft-kamapabhava-01:

-Fragmentation is an important issue, if we cannot resolve it now I propose
the following changes to the FRoPW header: We encode bits I and L used to
identified the fragments as 0 0 (0 0 means a complete frame) and work on the
solution without preventing the draft to progress.

-The P bit used to identified the payload as user data or network management
data, I propose that we keep this bit with the following description:

P - Payload Type  (bit 3):
   If set to zero then the payload field contains user's data else its 
   contents is not specified in this document.
   
   With this proposal, network and vendor may use P=1 in a proprietary way
to carry whatever they want to carry with the caveat that standardization of
the use of P=1 in the future may obsolete its proprietary use.
   
With these two changes the header will look like: 

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res |P|B|F|D|C|0|0|  Length   | Sequence Number               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

We have now the header in draft-martini (when P = 0). 

Now I will address emails proposing other changes/explanations. If I missed
anything let met know.

-Sasha email: 
Item 1 was addressed above: " I have noticed that the FRoPW Control Word
still 
   contains bit "P" that distinguishes user and maintenance
   traffic - in spite of the maintenance protocol issue being
   removed from the draft."
   
Item 2: This one is about dropping frame out-of order vs. re-ordering them
We can re-introduce and improve the text of version 00: "Packets, which are
received out of order, MAY be dropped or reordered at
the discretion of the receiver".

Item 3: "The draft defines two modes of operation, but if only one of
   them - port to port - is referred to as a "mode". What is more,
   one mode (the same) is defined as OPTIONAL but neither is
   defined as REQUIRED. Setting aside - for the moment - which mode
   should be which, explicit names for all the modes and
   explicit specification of the REQUIRED mode would be very 
   much in place. In particular, this would help with creating
   a 'per mode' applicability statement (preferably inline -
   the draft is not too long)".

About what is optional and what is mandatory. I prefer to address this item
later since we have IP and L2TPv3 too in addition to MPLS tunnels. I propose
that we do not specify what is mandatory and what is optional now but wait
to see the complete spec covering other tunnels.
   
Item 4: "The draft specifies a set of requirements for FRoPW. 
   Have you considered providing a check-list
   matching these requirements with the design spec? 
   IMHO this would be very useful and (hopefully) not too 
   difficult (in the worst case you can always drop an
   especially inconvenient requirement :-). 
   Personally I would like to understand how the requirement 
   for mapping the traffic management parameters is met
   with this spec."
   
   We will check the requirements list against the design spec and
drop/change what needs to be dropped/changed. However for traffic
management, it will take a little bit more time to address. We will not do
it in the next version if we produce it in 2-3 weeks as we propose. Traffic
management is definitely a high priority item.

-Comment from George Wilkie about the control word: We will follow the
suggestion in George's email: 
  
  "The doc appears to require the use of the FRoPW control word for all
types of
PSN.I understand the need for MPLS, not clear to me for other PSNs, e.g.
L2TPv3.
L2TPv3 can do without the control word since it has its own sequencing
capability and IP has no need for length field.
The DLCI can remain on the frame to carry the FBDC bits and avoid
inefficient
copy out/in."

-Next comments are from LLoyd Wood email that came today (Thursday)

1-We will address the use of IP tunnel. We have a placeholder for that but
MPLS seemed to have a higher priority.

2-About the security section we will use what is draft-bryant-pwe3-fr-encap.
It looks good. 

3-We will try to adopt other useful material from draft bryant complementing
draft kamapabhava-01.

Anything else I missed?

Now I would like to propose to write a new version of kamapabhava  with the
above changes/additions as a working group draft.

Claude Kawa

---

From: "Claude Kawa"<[email-masked]>
Date: Fri, 19 Apr 2002 05:48:14 -0400

About item 1 in Mark's email:

"Why did you relegate I and L to 0 0, but still keep the P bit
(half)defined?
There seems to be an inconsistency here".

OK in the spirit of progressing things we can make this bit as reserved.

Item 2

"I propose that the IP section does not fit within the architecture and
should be
removed. Realistically, we have FR over MPLS and FR over L2TPv3".

It is not up to me, supporting IP tunnels is in the charter of PWE3 WG. 

CLaude

---

From: "Claude Kawa"<[email-masked]>
Date: Fri, 19 Apr 2002 09:52:07 -0400

I still see arguments for frame relay bit ordering. In draft kama...-01 they
were changed back to the martini order: BFDC at the request of some people
on the PWE3 email discussion. In version 00 they were in Q.922 "order":
FBDC.

Let us agree please on an order BFCD or FBDC? Any strong preference for one
or the other. This is an important issue to close.

Another issue raised is whether we support IP tunnel or MPLS and L2TPv3
only. PWE3 charter lists the 3 types of tunnels. May be we need guidance
from above (chair or AD). Otherwise I propose for the first version of a WG
draft to focus of MPLS and L2TPv3 (unless L2TPv3 is addressed elsewhere).

Thanks

Claude Kawa

-----Original Message-----
From: Lloyd Wood [mailto:[email-masked]]
Sent: Friday, April 19, 2002 8:20 AM
To: Kawa, Claude [CAR:CS49:EXCH]
Cc: [email-masked]
Subject: Re: [PWE3] Proposed changes to draft kamapabhava-01

> Proposed changes to draft-kamapabhava-01:

that is, draft-kamapabhava-fr-pwe3-01.txt

> With these two changes the header will look like:

I see draft-kamapabhava-fr-pwe3-00.txt had PFBDC.
The above in 01 has changed that to PBFDC, which matches the Martini
layout in draft-martini-frame-encap-mpls-00.txt
- note the reordering of B and F.

> We have now the header in draft-martini (when P = 0).

so the ordering of the bits will incur extra processing, since they're
FBD in a _real_ frame relay datagram, and reordering kawa to match
martini is a retrograde step - as discussed in detail in
draft-bryant-pwe3-fr-compare-00.txt
See also the slides at the bottom of:
http://www.ietf.org/proceedings/01dec/234.htm

I personally think that if you can choose to reorder the kama bits at
this stage, you can at least choose to reorder them efficiently.

(I do find it strange that those concerned with the efficiency of the
 number of bits on the wire -- "it's a 1.4% overhead!" "No, it isn't!"
 -- aren't also concerned with the processing efficiency of how those
 bits get there. FR congestion notification is unlikely to be made to
 work well, and the complexity of bit manipulation isn't helping.)

> MPLS seemed to have a higher priority.

so this format is mpls-specific? (Where efficiency matters?)

> 3-We will try to adopt other useful material from draft bryant
complementing

good to hear.

cheers,

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 19 Apr 2002 10:36:22 -0400

Claude,

Thanks for the updates.  It's clear from recent list activity that Martini 
backwards compatibility is very important, and so I suggest keeping 
BFDC.  It's really not that tough to do, folks - there are already several 
wire-speed Martini implementations, so there's certainly proof by example.

Regarding IP tunnels - I agree to focus on L2TPv3 and MPLS for now, and add 
IP if someone cares enough about it to write the text.

Cheers,
Andy

--------

At 4/19/2002 09:52 AM -0400, Claude Kawa wrote:

>I still see arguments for frame relay bit ordering. In draft kama...-01 
>they were changed back to the martini order: BFDC at the request of some 
>people on the PWE3 email discussion. In version 00 they were in Q.922 
>"order": FBDC.
>
>Let us agree please on an order BFCD or FBDC? Any strong preference for 
>one or the other. This is an important issue to close.
>
>from above (chair or AD). Otherwise I propose for the first version of a 
>WG draft to focus of MPLS and L2TPv3 (unless L2TPv3 is addressed elsewhere).
>
>Thanks
>
>Claude Kawa
>
>From: Lloyd Wood 
>[<mailto:[email-masked]>mailto:[email-masked]]
><http://www.ietf.org/proceedings/01dec/234.htm>http://www.ietf.org/proceedings/01dec/234.htm 
>
>
><[email-masked]>PGP<<http://www.ee.surrey.ac.uk/Personal/L.Wood/>http://www.ee.surrey.ac.uk/Personal/L.Wood/> 
>

---

From: "Claude Kawa"<[email-masked]>
Date: Fri, 19 Apr 2002 10:44:22 -0400

Ok 
 
Will follow Andy advice on the bit order and the focus on L2TPv3 and MPLS
 
Now do we have a (rough) consensus to proceed with a WG draft as we
discussed the last few days?
 
Thanks
 
Claude

-----Original Message-----
From: Andrew G. Malis [mailto:[email-masked]]
Sent: Friday, April 19, 2002 10:36 AM
To: Kawa, Claude [CAR:CS49:EXCH]
Cc: [email-masked]
Subject: RE: [PWE3] Proposed changes to draft kamapabhava-01

Claude,

Thanks for the updates.  It's clear from recent list activity that Martini
backwards compatibility is very important, and so I suggest keeping BFDC.
It's really not that tough to do, folks - there are already several
wire-speed Martini implementations, so there's certainly proof by example.

Cheers,
Andy

--------

Thanks 

Claude Kawa 

-----Original Message----- 
From: Lloyd Wood [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Friday, April 19, 2002 8:20 AM 
To: Kawa, Claude [CAR:CS49:EXCH] 
Cc: [email-masked] 
Subject: Re: [PWE3] Proposed changes to draft kamapabhava-01 

<http://www.ietf.org/proceedings/01dec/234.htm>  

good to hear. 

cheers, 

L. 

<[email-masked]>PGP< http://www.ee.surrey.ac.uk/Personal/L.Wood/
<http://www.ee.surrey.ac.uk/Personal/L.Wood/> >

---

From: Danny McPherson <[email-masked]>
Date: Fri, 19 Apr 2002 08:53:24 -0600

> this stage, you can at least choose to reorder them efficiently.

I have to agree with Lloyd on this, making them less efficient 
seems silly at best.  

As for the PSN types the draft needs to specify, if IP alone is more of
a perfunctory task I suppose the placeholders OK, but if there's only 
interest in MPLS & L2TPv3 (an IP mechanism) then I suppose there's only 
interest in these :-)  

Of course, the charter does state IP as well, but so long as nothing is 
done to abjure IP tunneling I don't think it matters.

-danny

---

From: Shahram Davari <[email-masked]>
Date: Fri, 19 Apr 2002 07:51:33 -0700

Claude,
 
Just a couple of short comments.
 
-Shahram

-----Original Message-----
From: Claude Kawa [mailto:[email-masked]]
Sent: Thursday, April 18, 2002 10:29 PM
To: [email-masked]
Subject: [PWE3] Proposed changes to draft kamapabhava-01

I would like to propose changes to draft kamapabhava-01 taking into account the comments received the last few days in order to progress this work. I will be able to produce a new draft in 2-3 weeks (next week I am out of the office).

-Fragmentation is an important issue, if we cannot resolve it now I propose the following changes to the FRoPW header: We encode bits I and L used to identified the fragments as 0 0 (0 0 means a complete frame) and work on the solution without preventing the draft to progress.

-The P bit used to identified the payload as user data or network management data, I propose that we keep this bit with the following description:

   With this proposal, network and vendor may use P=1 in a proprietary way to carry whatever they want to carry with the caveat that standardization of the use of P=1 in the future may obsolete its proprietary use.

 0                   1                   2                   3 

To be consistant with FR/MPLS-Forum and the FR header, I suggest changing the order of the flags from BFDC to FBDC.

 w e have now the header in draft-martini (when P = 0). 

Now I will address emails proposing other changes/explanations. If I missed anything let met know. 

-Sasha email: 
Item 1 was addressed above: " I have noticed that the FRoPW Control Word still 
   contains bit "P" that distinguishes user and maintenance 
   traffic - in spite of the maintenance protocol issue being 
   removed from the draft." 
   
Item 2: This one is about dropping frame out-of order vs. re-ordering them  We can re-introduce and improve the text of version 00: "Packets, which are received out of order, MAY be dropped or reordered at

About what is optional and what is mandatory. I prefer to address this item later since we have IP and L2TPv3 too in addition to MPLS tunnels. I propose that we do not specify what is mandatory and what is optional now but wait to see the complete spec covering other tunnels.

   We will check the requirements list against the design spec and drop/change what needs to be dropped/changed. However for traffic management, it will take a little bit more time to address. We will not do it in the next version if we produce it in 2-3 weeks as we propose. Traffic management is definitely a high priority item.

-Comment from George Wilkie about the control word: We will follow the suggestion in George's email: 
  
  "The doc appears to require the use of the FRoPW control word for all types of 
PSN.I understand the need for MPLS, not clear to me for other PSNs, e.g. L2TPv3. 
L2TPv3 can do without the control word since it has its own sequencing 
capability and IP has no need for length field. 
The DLCI can remain on the frame to carry the FBDC bits and avoid inefficient 
copy out/in."  

Does this mean that the FR header will be transported?

1-We will address the use of IP tunnel. We have a placeholder for that but MPLS seemed to have a higher priority. 

2-About the security section we will use what is draft-bryant-pwe3-fr-encap. It looks good. 

3-We will try to adopt other useful material from draft bryant complementing draft kamapabhava-01. 

Anything else I missed? 

Now I would like to propose to write a new version of kamapabhava  with the above changes/additions as a working group draft.

Claude Kawa

---

From: "Khalid Ahmad"<[email-masked]>
Date: Fri, 19 Apr 2002 12:06:23 -0400

Hi Danny,

thank you for this clarification.

In that case, I look forward to continued cooperation in the ATM/MPLS
drafts.

Regards,
Khalid

-----Original Message-----
From: Danny McPherson [mailto:[email-masked]]
Sent: Friday, April 19, 2002 11:49 AM
To: [email-masked]
Subject: Re: [PWE3] Proposed changes to draft kamapabhava-01 

> Hi Danny,
> 
> I assume that your point re backwards compatibility applies equally to all
> the pwe3 drafts, including the work we are currently doing for ATM over
MPLS
> &IP.

Yes Khalid, else we would have simply published the Martini drafts and
been done with it.

-danny

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

---

From: Danny McPherson <[email-masked]>
Date: Fri, 19 Apr 2002 09:49:25 -0600

> the pwe3 drafts, including the work we are currently doing for ATM over MPLS
> &IP.

-danny

---

From: Danny McPherson <[email-masked]>
Date: Fri, 19 Apr 2002 09:21:46 -0600

> wire-speed Martini implementations, so there's certainly proof by example.

Complete backwards-compatibility is not the goal of the WG, technically
sound results are.  That being the case, and I believe the ADs are in 
agreement with me, the more optimal model should be in the draft.
 
> IP if someone cares enough about it to write the text.

Agreed!

-danny

---

From: "Khalid Ahmad"<[email-masked]>
Date: Fri, 19 Apr 2002 11:45:35 -0400

Hi Danny,

This guideline is very important if we are to converge any of the drafts.

Regards,
Khalid

-----Original Message-----
From: Danny McPherson [mailto:[email-masked]]
Sent: Friday, April 19, 2002 11:22 AM
To: [email-masked]
Subject: Re: [PWE3] Proposed changes to draft kamapabhava-01 

 

Agreed!

-danny

---

From: [email-masked]
Date: Sat, 20 Apr 2002 13:43:01 +0100

Andrew....I don't agree with what you say below about backwards
compatibility with Martini being 'very important'.  I would agree with you
if this represented some agreed stds document but IMO Martini is just a
draft ID with no official stds status.  If vendors want to build to such a
'stds intercept' then they do so at risk and they must accept they may need
to change.  I also don't like this 'we've built to it therefore its the de
facto std by an existence proof' argument........because for 1 thing what is
to stop a few vendors (and maybe SPs) having some private agreement to do
this and then using this 'proof by existence' to force it on everyone else? 
 
regards, Neil

-----Original Message-----
From: Andrew G. Malis [mailto:[email-masked]]
Sent: 19 April 2002 15:36
To: Claude Kawa
Cc: [email-masked]
Subject: RE: [PWE3] Proposed changes to draft kamapabhava-01

Claude,

Cheers,
Andy

--------

Thanks 

Claude Kawa 

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

good to hear. 

cheers, 

L.

---

From: [email-masked]
Date: Sat, 20 Apr 2002 13:43:02 +0100

I also agree with Lloyd on this FBD bit ordering issue.  We are talking
about draft stds here......just because somebody has already built to an
at-risk stds intercept that is their problem, and it is no reason for our
industry to accept it if it contains bad architecture.

regards, Neil

> Sent: 19 April 2002 15:53
> To: [email-masked]

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 20 Apr 2002 11:31:40 -0400

Neil,

OK, point made .... if it's only me, then I'll be happy to concede.

Cheers,
Andy

-------

---

From: "W. Mark Townsley" <[email-masked]>
Date: Sat, 20 Apr 2002 18:22:26 +0200

> Claude Kawa wrote:
> "Why did you relegate I and L to 0 0, but still keep the P bit (half)defined?
> "I propose that the IP section does not fit within the architecture and should
> be

I think that the spirit of IP support in the charter is to ensure that PWs will
operate over an IP network. Since L2TPv3 over IP is clearly available, then we
have ultimately met this requirement.

Thanks,

- Mark

---

From: Giles Heron <[email-masked]>
Date: 21 Apr 2002 23:22:11 +0000

> have ultimately met this requirement.

ditto MPLS over GRE (and thus IP) is clearly available.

But then that solution fails the softer "must operate over an IP network
without any vestiges of MPLS anywhere in the solution" requirement ;-)

Giles

-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================

---

From: Eric Rosen <[email-masked]>
Date: Mon, 22 Apr 2002 10:05:08 -0400

Giles> ditto MPLS over GRE (and thus IP) is clearly available. 

Yes.   But since  MPLS-in-IP  and/or MPLS-in-GRE  are  general purpose  MPLS
encapsulations (i.e.,  no PW-specific stuff) they  do not need  to be called
out specifically in any of the drafts. 

So I agree with  Mark that there is no need for any  of the specs to suggest
"IP tunneling" as if it were a third option distinct from MPLS or L2TP.

---

From: "Kavi, Prabhu" <[email-masked]>
Date: Mon, 22 Apr 2002 15:56:29 -0400

Stewart and Andy,

I am glad that we are going with the Q.922 bit ordering.
Not because of a performance issue, but simply because it
is more logical.

The performance problem is less of an issue.  With the
advances in NPs, I know there exist C-coded versions 
of Martini encaps that runs in hardware and can support 
OC-192c rates for 40-byte packets.

Prabhu

> From: Andrew G. Malis [mailto:[email-masked]]
> Sent: Monday, April 22, 2002 12:35 PM
> To: [email-masked]
> Cc: Andrew G. Malis; [email-masked]
> Stewart,
> I've already thrown in the towel on this issue.  Claude is 
> going to update 
> the kamapabhava draft to use the Q.922 bit ordering.  
> Regarding what line 
> rates the Martini encapsulation can be done at for arbitrary 
> frame sizes, I 
> can't say until we go public at Supercomm.  So ask me again 
> in June ... :-)
> 
> Cheers,
> Andy
> 
> -------
> 
> At 4/22/2002 01:04 PM +0100, Stewart Bryant wrote:
> 
> 
> >"Andrew G. Malis" wrote:
> > >
> > > Claude,
> > >
> > > Thanks for the updates.  It's clear from recent list 
> activity that 
> > Martini backwards compatibility
> > > is very important, and so I suggest keeping BFDC.  It's 
> really not that 
> > tough to do, folks - there
> > > are already several wire-speed Martini implementations, 
> so there's 
> > certainly proof by example.
> > >
> >
> >At what speed?
> >
> >The issue wrt speed is not so much frame relay emulation per 
> se, it is the 
> >customers who want
> >to use the technology for VPN (ie PPVPN) multiplexing. In 
> this case we 
> >have no effective
> >ceiling on performance demand. As I have shown microcode 
> implementatons 
> >will find it tough to do
> >the bit manipulations at speeds, which can be expected to 
> rise to 10Gb/s 
> >in the reasonable
> >future. I suppose they could also just lie about the value 
> of the bits!
> >
> >Since it is the MPLS teams, looking for compatibility with 
> Martini that 
> >want the strange bit
> >ordering, can we agree that this format will be restricted to MPLS 
> >implementations?
> >
> > > Regarding IP tunnels - I agree to focus on L2TPv3 and 
> MPLS for now, and 
> > add IP if someone cares
> > > enough about it to write the text.
> >
> >I agree with this. It seems very unlikely that anyone will ever run 
> >directly over IP. It offers
> >no particular advantage, and has the disadvantage of lacking an 
> >intermediate multiplexing
> >layer. It will also consume a protocol number and it seems 
> unlikely that 
> >one will be allocated
> >given the limited number available.
> >
> >Stewart
> >
> > >
> > > Cheers,
> > > Andy
> > >
> > > --------
> > >
> > > > I still see arguments for frame relay bit ordering. In draft 
> > kama...-01 they were changed back
> > > > to the martini order: BFDC at the request of some 
> people on the PWE3 
> > email discussion. In
> > > > version 00 they were in Q.922 "order": FBDC.
> > > >
> > > > Let us agree please on an order BFCD or FBDC? Any 
> strong preference 
> > for one or the other. This
> > > > is an important issue to close.
> > > >
> > > > Another issue raised is whether we support IP tunnel or 
> MPLS and 
> > L2TPv3 only. PWE3 charter lists
> > > > the 3 types of tunnels. May be we need guidance from 
> above (chair or 
> > AD). Otherwise I propose
> > > > for the first version of a WG draft to focus of MPLS and L2TPv3 
> > (unless L2TPv3 is addressed
> > > > elsewhere).
> > > >
> > > > Thanks
> > > >
> > > > Claude Kawa
> > > >
> > > > > I would like to propose changes to draft 
> kamapabhava-01 taking into 
> > account
> > > > > the comments received the last few days in order to 
> progress this 
> > work. I
> > > > > will be able to produce a new draft in 2-3 weeks 
> (next week I am 
> > out of the
> > > > > office).
> > > > >
> > > > > -Fragmentation is an important issue, if we cannot 
> resolve it now I 
> > propose
> > > > > the following changes to the FRoPW header: We encode 
> bits I and L 
> > used to
> > > > > identified the fragments as 0 0 (0 0 means a complete 
> frame) and 
> > work on the
> > > > > -The P bit used to identified the payload as user 
> data or network 
> > management
> > > > > 1-We will address the use of IP tunnel. We have a 
> placeholder for 
> > that but
> > > > > 3-We will try to adopt other useful material from 
> draft bryant 
> > complementing
> > > > > draft kamapabhava-01.
> > > >
> > > > good to hear.
> > > >
> > > > cheers,
> > > >
> > > > L.
> > > >
> > > >

---

From: Luca Martini <[email-masked]>
Date: Tue, 23 Apr 2002 16:36:52 -0600

I would like to point out a little difference here.
There are several interoperable independent implementations of the 
draft-martini encapsulations ( some of which are currently deployed ). Can we 
say the same about all the other drafts ?

Luca

-- 
Just say no to summer. Ski all year !
Luca Martini Senior Network Architect, Level 3 Communications - Broomfield, CO
[email-masked] | VE2WKR/W0 | Phone 720-888-1225 | pager [email-masked]

---

From: Luca Martini <[email-masked]>
Date: Tue, 23 Apr 2002 16:42:12 -0600

It seems to me that efficiency of this encapsulation was never raised by any of 
the implementors. Stewart did a very good analysis of the encapsulation, but I 
don't see any limitations in today's hardware that warrant rewriting the 
encapsulation code in light of this academic exercise.

Luca

[email-masked] wrote:

>>>so the ordering of the bits will incur extra processing, 
>>>
>>since they're
>>
>>>I personally think that if you can choose to reorder the 
>>>
>>kama bits at
>>

---

From: Shahram Davari <[email-masked]>
Date: Wed, 24 Apr 2002 07:50:36 -0700

Hi Luca,

> From: Luca Martini [mailto:[email-masked]]
> Sent: Tuesday, April 23, 2002 7:10 PM
> To: [email-masked]
> Stewart Bryant wrote:
> activity that Martini backwards compatibility
> really not that tough to do, folks - there
> >>are already several wire-speed Martini implementations, so 
> there's certainly proof by example.
> >>
> >>
> Martini that want the strange bit
> > ordering, can we agree that this format will be restricted 
> to MPLS implementations?
> > 
> 
> Yes, I don't see any advantage or disadvantage in making it 
> different for L2TPv3.
> 

I think the header should stay the same for all tunneling technologies.
Because of two reasons:

1) A single chip/card may be used to encapsulate FR over different tunnel technologies.
In that case we don't want to have a separate hardware/software for the generation
of the flag for each technology.

2) Small differences such as a single bit order, could go un-noticed among developers
who usually expect consistency, and could cause interoperability issues. 

> 
> One more comment on the efficiency. We would only care about how many 
> instructions it take to manipulate the bit if we where 
> actually constrained. 
> Most microcode i know of , has lot's of extra room for a few 
> more instructions. 
> The issue is usually large insertion of data, and large data 
> moves , not so 
> much bit instructions.
>

Agree, the order of the bits is not terribly important, as long as it is
highlighted in the draft properly.

-Shahram

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 24 Apr 2002 17:23:25 +0200

> of the flag for each technology.

When you think of:

MPLS label | MPLS label | Martini Control Word | FR Data |
    IP     |    L2TPv3  | Martini Control Word | FR Data |

If you make the control words the same, you really haven't gained a lot of
common chip code here. And, you lose any common L2TPv3 Control Word code by
using the martini control word for Frame Relay vs. the L2TP sequencing word
defined in the L2TPv3 specification.

Anyway, it seems as though the strongest argument for keeping the existing
ordering and format is for backwards compatiblity. So, I don't see why that
should apply to non-MPLS cases where there isn't anything to be backwards
compatible with.

> who usually expect consistency, and could cause interoperability issues.

L2TPv3 doesn't even use the control word which these bits are being mixed into.
My feeling among the L2TP folks is that they would rather carry the entire Frame
Relay header as received, vs. translating it into a control word that they don't
need anyway. So, since the PW isn't even *touching* the bit ordering in this
case, its pretty difficult to get it wrong!

---

From: Shahram Davari <[email-masked]>
Date: Wed, 24 Apr 2002 08:44:26 -0700

Mark,

I didn't know that the intention of the WG is not to use the control word and to carry FR header in the L2TPv3 case. If that is the intention then you are correct. But why not carry the FR header in the MPLS case too? BW efficiency? 

-Shahram

> From: W. Mark Townsley [mailto:[email-masked]]
> Sent: Wednesday, April 24, 2002 11:23 AM
> To: Shahram Davari
> Cc: 'Luca Martini'; [email-masked]; Andrew G. Malis; [email-masked]

---

From: Giles Heron <[email-masked]>
Date: 24 Apr 2002 17:53:04 +0000

On Wed, 2002-04-24 at 16:44, Stewart Bryant wrote:
> The two design groups started with different requirements, different 
> protocol design philosophies etc.
> 
> I think that the best way forward is to recognise the control word
> as a mixture of MPLS PSN convergence and MPLS specific header compression.
> 
> Then perhaps we can agree that when MPLS is the PSN we use the CW, 
> but when IP is the PSN we don't.

probably makes sense - especially if the IP solution is to carry the FR
header?

> Then the MPLS team can choose between backwards compatibility and
> efficiency. As the IP team is not effected by that choice we 
> respect the outcome either way.

well the MPLS team already have both options - the port mode in
draft-kamapabhava could presumably be used without the CW (though it may
still be required for length/sequencing/fragmentation).

So on that basis I'd say let's go for backwards compatibility when using
the CW.

Giles

---

From: [email-masked]
Date: Thu, 25 Apr 2002 12:15:12 +0100

Luca Martini wrote 24 April 2002 19:56
> W. Mark Townsley wrote:
>> > 
> > Shahram Davari wrote:
> > 
> >>Mark,
> >>
> >>I didn't know that the intention of the WG is not to use 
> the control word and to carry FR header in the L2TPv3 case. 
> If that is the intention then you are correct. But why not 
> carry the FR header in the MPLS case too? BW efficiency?
> >>
> > 
> > Well, you certainly could.
> > 
> > I think the strongest arguments not to for MPLS being given 
> right now are based
> > on backwards compatibility with the draft-martini MPLS 
> implementations. I wasn't
> > part of the decision-making for draft-martini, but I 
> imagine BW efficiency was a
> > consideration.
> > 
> > - Mark
> > 
> 
> actually it was more the fact that several boxes have L2 
> processing and L3 
> processing separate.
> 
> Luca
NH=> Sorry if I am being a bit thick here, but would not what you say above
Luca suggest that this would actually be just the opposite?

One further more general point on all this stuff:
There are essentially 2 extremes of interworking various L2 protocols:
-	true client/server layer relationhip, ie the client layer PDU is
fully/transparently encapsulated within the server layer PDU payload 
-	true peer-layer relationship, ie use protocol conversion to pass PDU
payloads across transparently but map PDU O/H functions (as a best fit)

The former has no impact on the trail termination points of the client layer
network, though the server layer trail termination points must start/end at
the IWF. Whereas in the peer-layer case we have 3 peer trails in the case of
X<=>MPLS<=>X....one at each end for layer network X (say ATM, FR trails) and
one in the middle for the MPLS LSP.

Why is this important?

-	Well, in the client/server case the client layer networks exists for
all future practical time, ie this architecture does not permit migration of
end systems to MPLS nor does it allow X<=>MPLS<=>Y interworking...where X
and Y are different L2 technologies.  In the peer-layer case however, this
does allow X<=>MPLS<=>Y, and even MPLS<=>XorYorZ.....

-	There are also very different defect handling scenarios in these 2
modes, and we need to get this right.....you can only fully grasp this if
you look at where the trail termination points start/end in each case (I am
sure someone like Maarten Vissers could do us some nice functional arch
diagrams for this).  I have already noted 1 draft proposal for defect
handling which has a serious layer violation, ie Brayley, where (near-end)
ATM failures are supposed to generate (far-end) SDH/Sonet FDI (AIS)!  I am
now hearing variations on this kludge using ILMI in the ATM case....I urge
those who are contemplating this to please don't go there, we should try and
get it right in the data-plane.

It's not at all clear to me that the above type of thinking has been applied
to much of the work I have seen so for.

Its my opinion that the goal should be to strive for the peer-layer case
(where appropriate....some cases are not appropriate) and that a true
client/layer transparent service must also be offered.  What I see when I
look at some of the drafts to date is a hybrid of the 2 modes, which looks
like an attempt at a bit of BW squeezing but fails to take the wider context
into account....and as an operator who might have to live with this stuff if
it ever gets ratified, that does concern me.

regards, Neil

---

From: Luca Martini <[email-masked]>
Date: Thu, 25 Apr 2002 11:35:27 -0600

Snip...

> does allow X<=>MPLS<=>Y, and even MPLS<=>XorYorZ.....

Neil are you suggesting we should look at MPLS<=>ATM or MPLS<=>F/R  ?

I consider the migration path as follows:

ancient times  -> ATM
Current times -> ATM over MPLS trunks
Future -> IPv4,6/MPLS

Luca

---

From: [email-masked]
Date: Fri, 26 Apr 2002 12:55:32 +0100

Luca Martini asked 25 April 2002 18:35
<snip>
> Current times -> ATM over MPLS trunks
NH=> Hi Luca,

In my orginal mail which started this I only tried to make these points:
-	client/server and peer-peer are the 2 interworking extremes.....the
various AAL5 modes in the various drafts are somewhere in between these;
-	the defect handling behaviour required is quite different in the 2
extremes.  It does not seem well sorted IMO, and it was mainly this aspect I
have near-term concerns on......one key observation here, but I know some
don't agree/see this, is that it is the *trail* object that has to be
managed on co pkt-sw technologies, not the instances of pkts that use this
trail;
-	client/server does not permit the same migration strategy (or
services) for an operator as peer-peer, cf FRF5 vs FRF8 for ATM/FR
client/server and peer-peer relationships.

I largely agree with your migration view (but I know plenty who don't).
However, the 'ancient times -> ATM' observation does not quite stack-up with
what I am seeing wrt current service take-up and grwoth forecasts over the
next 5 years for our ATM networks.....same applies to FR.  Hence, these
technologies are not going to vanish that quickly, even if we might like
them to, and they are a very important revenue source to operators.....so it
would be rather foolhardy (for vendors in particular) to ignore this fact.
Further, given L2 BW services (and also BTW L1 BW services) are always in
demand (since some people like building their own L3, and L2/3, networks)
then we will need something to replace them with.....MPLS is a good
candidate IMO at L2 for building L2 VPNs as a *data-plane* PDU structure.
So, with some careful thought, I can see some good L2 convergence strategies
being available for development by vendors which may help operators reduce
capex/opex (a hot issue for our industry as most people should not need
telling), and I am indeed aware of some who are already active on this.

I am not necessarily suggesting that PWE3 works on this perspective however
if that is not what they are chartered to look at....but independent of
this, they really ought to get the defect handling sorted properly IMO even
for the client/server case.

regards, Neil