Subject: Re: Proposed changes to draft kamapabhava-01

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

On Wed, 2002-04-24 at 16:35, 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.

that was part of it, but there are other issues - including the fact
that there are different lengths of FR header and that we may be
translating the DLCI across the circuit (though the latter wouldn't be a
big issue if the header was carried - that's how the Ethernet VLAN mode
works).

Giles

> 
> - Mark
> 
> > 
> > -Shahram
> > 
> > > -----Original Message-----
> > > 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]
> > > Subject: Re: [PWE3] Proposed changes to draft kamapabhava-01
> > >
> > >
> > > Shahram Davari wrote:
> > > >
> > > > Hi Luca,
> > > >
> > > > > -----Original Message-----
> > > > > From: Luca Martini [mailto:[email-masked]]
> > > > > Sent: Tuesday, April 23, 2002 7:10 PM
> > > > > To: [email-masked]
> > > > > Cc: Andrew G. Malis; [email-masked]
> > > > > Subject: Re: [PWE3] Proposed changes to draft kamapabhava-01
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 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.
> > > > > >>
> > > > > >>
> > > > > > 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?
> > > > > >
> > > > >
> > > > > 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.
> > >
> > > 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.
> > >
> > > >
> > > > 2) Small differences such as a single bit order, could go
> > > un-noticed among developers
> > > > 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!
> > >
> > > >
> > > > >
> > > > > 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
> > > >
> > > > > Luca
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > pwe3 mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/pwe3
> > > > >
> > > >
> > > > _______________________________________________
> > > > pwe3 mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/pwe3
> > >
> > 
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 
-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 24 Apr 2002 18:35:13 +0200

- Mark

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 24 Apr 2002 17:44:00 +0100

> 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 i…

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.

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.

Stewart

---

From: Luca Martini <[email-masked]>
Date: Wed, 24 Apr 2002 12:56:15 -0600

> part of the decision-making for draft-martini, but I imagine BW efficiency was a

actually it was more the fact that several boxes have L2 processing and L3 
processing separate.

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]