Subject: Re: question on kompell draft for L2VPN

From: Kireeti Kompella <[email-masked]>
Date: Thu, 1 Feb 2001 23:14:07 -0800 (PST)

> I was wondering if there was any particular reason why 2-byte Q922 header
> is stripped from data packet at ingress PE when encap is frame relay. 

A new DLCI gets put on at the far end, so why keep the old one?

> I would think it might be beneficial to preserve the header 
> (for FECN/BECN, DE info) than not.

Keep 16 bits because 4 may be useful?

There was a proposal to encode these bits in the inner label, using a
combination of the EXP bits, and the label itself.  This was vetoed in
favor of carrying these bits in the (optional) control word.  One may
argue, why 32 bits when 16 would do?  Since the control word is optional,
if < 50% of the users of Frame Relay over MPLS want these bits, this
approach comes out ahead.  Since 0% of the (admittedly small) sample of
folks I know who use FR/MPLS need these bits, the universe is ahead
(so far).  Rest assured however that there will be protocol mechanisms
to preserve these bits.

Note too that ATM AAL5 encap throws away the cell headers -- this is
entirely identical.  There are useful bits in the cell header besides
the VPI/VCI.

> If there is any overwhelming reason to strip the header, how about adding
> another encapsulation type of "frame relay with q922-header"?

What is the overwhelming reason to carry the dlci?

Kireeti.

---

From: "Shah, Himanshu" <[email-masked]>
Date: Fri, 2 Feb 2001 17:21:40 -0500

Kireeti, Chandru,

It seems rather odd of wanting to conserve on 2-bytes in the
payload when in fact we are adding a lot more bytes using 
MPLS header and 2 labels, etc.

Translating this info into inner label (or in optional control word)
at ingress and back into q922 header at egress PE is stretching 
it too far - just for sake of conserving 2-bytes!! at the expense 
of adding more processing overhead at 2 ends..

In a typical frame-relay switch, only DLCI bits get replaced from
ingress interface to egress interface. L2VPN is nothing but a 2 half
switches separated by MPLS cloud (as far as data packet processing
is concerned). There is no reason why we could not remain as close to 
the switch architecture as possible.

Also, I had like to draw your attention to following text from 
draft-martini-l2circuit-encap-mpls-00.txt (Encapsulation Methods 
for Transport of Layer 2 Frames Over MPLS). According to this 
text we would have compliancy issue.

I highly recommend we drop the 'q922 stripping' requirement...

Himanshu Shah
Tenor networks
Acton, MA

----------- text from draft-martini-l2circuit-encap-mpls-00.txt -------
"5. Protocol-Specific Issues

5.1. Frame Relay

   A Frame Relay PDU is transported in its entirety, including the Frame
   Relay header.  The sequencing control word is OPTIONAL.

   The BECN and FECN signals are carried unchanged across the network in
   the Frame Relay header. These signals do not appear in the MPLS
   header, and are unseen by the MPLS network. The Label Edge Routers
   that implement this document MAY, when either adding or removing the
   encapsulation described herein, change a zero to a one in either or
   both of these bits in order to reflect congestion in the MPLS network
   that is known to the LERs. The BECN and FECN bits MUST NEVER be
   changed from one to zero.

   The ingress LSR MAY consider the DE bit of the Frame Relay header
   when determining the value to be placed in the EXP fields of the MPLS
   label stack. In a similar way, the egress LSR MAY consider the EXP
   field of the VC label when queuing the packet for egress."

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Friday, February 02, 2001 2:14 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: question on kompell draft for L2VPN

Kireeti.