Subject: [PWE3] FR over PWs

From: Javi <[email-masked]>
Date: Sun, 20 Nov 2011 14:32:37 +0100

In the emulation of Core-LAPF links over PWs:

a) [RFC4591] (FRoPW L2TPv3):

     + FRPW Payload: Core-LAPF PDU is transported in its entirety, 
excluding flags and FCS, bit stuffing is undone. So, FRPW payload 
transports Core-LAPF "address and data" fields.

     + L2-Specific Sublayer: presents if sequencing or other features 
required. The Default format defined in Section 4.6 of [RFC3931] MUST be 
used.

     + Bits of the Core-LAPF Address:
        * C/R: conveyed transparently.  Its value MUST NOT be changed by 
the LCCE.
        * FECN, BECN, DE: MAY be set by the LCCE.

b) [RFC4619] (FRoMPLS):

     + FRPW Payload: Core-LAPF PDU is transported in its entirety, 
excluding bit/byte stuffing, frame relay header, and FCS. I understand 
"frame relay header" means "Core-LAPF address field". So, FRPW payload 
would ONLY transport Core-LAPF data field.

     + L2-Specific Sublayer (CW): always presents, with the bits C, D, F, B

     + Bits of the Core-LAPF Address:
        * C/R: copied unchanged in the CW (bit C)
        * FECN: copied in the CW (bit F). If it is not already set, it 
MAY be set as a result of ingress frame policing.
        * BECN: copied in the CW (bit B). If it is not already set, it 
MAY be set as a result of ingress frame policing.
        * DE: copied in the CW (bit D). If it is not already set, it MAY 
be set as a result of ingress frame policing.

Why these differences?

In RFC4591, I understand FRPW payload transports "Core-LAPF address 
field", but egress LCCE does not use it (apart from "C/R" bit). Why?

Why does RFC4591 transports "Core-LAPF address field" in the FRPW 
payload insteed of using the L2-Specific Sublayer such as RFC4619?

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sun, 20 Nov 2011 14:13:26 -0500

Javi,

You're getting into ancient history here.

The short answer - because 4619 did it right. :-)

More seriously, 4619 didn't transport the DLCI because it was variable
length (2-4 octets), local to the interface, and could be a different
length at each end of the PW. So we did a local label/DLCI mapping at
each end of the PW.

RFC 4618 provides a transparent Frame Relay port mode over MPLS, if
that's what you want (section 5.2). In that case, all the frames to
and from that port are transported over a single PW. This mode
requires the headers to be transported, since multiple DLCIs are being
multiplexed over the same PW.

I don't really remember why RFC 4591 did it differently. Maybe Mark remembers.

Cheers,
Andy

On Sun, Nov 20, 2011 at 8:32 AM, Javi <[email-masked]> wrote:
>    + FRPW Payload: Core-LAPF PDU is transported in its entirety, excluding
> flags and FCS, bit stuffing is undone. So, FRPW payload transports Core-LAPF
> "address and data" fields.
>
>       * C/R: conveyed transparently.  Its value MUST NOT be changed by the
> LCCE.
>    + FRPW Payload: Core-LAPF PDU is transported in its entirety, excluding
> bit/byte stuffing, frame relay header, and FCS. I understand "frame relay
> header" means "Core-LAPF address field". So, FRPW payload would ONLY
> transport Core-LAPF data field.
>
>       * FECN: copied in the CW (bit F). If it is not already set, it MAY be
> set as a result of ingress frame policing.
>       * BECN: copied in the CW (bit B). If it is not already set, it MAY be
> set as a result of ingress frame policing.
>       * DE: copied in the CW (bit D). If it is not already set, it MAY be
> set as a result of ingress frame policing.
>
>
>
> Why these differences?
>
> In RFC4591, I understand FRPW payload transports "Core-LAPF address field",
> but egress LCCE does not use it (apart from "C/R" bit). Why?
>
> Why does RFC4591 transports "Core-LAPF address field" in the FRPW payload
> insteed of using the L2-Specific Sublayer such as RFC4619?
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>

---

From: Javi <[email-masked]>
Date: Sun, 20 Nov 2011 21:11:01 +0100

Andy,

Why does RFC4619 copy the C/R bit copied in the CW (bit C)?.

According to ITU-T Q.922, the C/R bit is not used in Core-LAPF (only in 
LAPF). So, the ingress/egress PE might omit this bit.

Why does RFC4619 transport the bits BECN, FECN and DE in the CW?. I 
understand these bits have sense in each FR circuit, it has no sense to 
use the bits of one circuit in the other circuit across the PW. I think 
the right is what RFC4591 does: "FECN, BECN, DE MAY be set by the egress 
LCCE". Or not?

Regards,

Javi

El 20/11/2011 20:13, Andrew G. Malis escribió:
> On Sun, Nov 20, 2011 at 8:32 AM, Javi<[email-masked]>  wrote:

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sun, 20 Nov 2011 15:53:22 -0500

Javi,

As I recall, the C/R bit was used in Frame Relay Forum specs, FR/ATM
interworking in particular. Also, again as I recall (it's been a
while) the FRF specs, X.36, and especially X.76 required that the B,
F, and DE bits be preserved if set along the path of a FR connection,
so that congestion and discard eligibility indications could be
carried, for example, across FR network boundaries when you had a
concatenated FR circuit.

Cheers,
Andy

On Sun, Nov 20, 2011 at 3:11 PM, Javi <[email-masked]> wrote:
> understand these bits have sense in each FR circuit, it has no sense to use
> the bits of one circuit in the other circuit across the PW. I think the
> right is what RFC4591 does: "FECN, BECN, DE MAY be set by the egress LCCE".
> Or not?
>
> Regards,
>
> Javi
>
>
>>> excluding
>>> the
>>> excluding
>>> field",

---

From: Carlos Pignataro <[email-masked]>
Date: Mon, 21 Nov 2011 09:11:57 -0500

[cross-posting to [email-masked], as this is also asked at
<http://www.ietf.org/mail-archive/web/l2tpext/current/msg01282.html>]

Javi,

I have the same recollection as Andy as to the importance of those bits.

Additionally, my notes do not include why the different choice between
RFC 4591 (that I helped edit) and RFC 4619, different starting points.
But ultimately the same bits are transported (in a different way,
agreed) and the DLCI is generated and rewritten at disposition. A couple
of additional notes: have in mind that RFC 4619 includes two DLCI PW
Types (legacy CW); also, the equivalent to port-mode is RFC 4349.

Note also that the difference in encapsulation is accounted for in
heterogeneous Segmented Pseudowire in RFC 6073 at
<http://tools.ietf.org/html/rfc6073#section-8.7.1>, bullet 'ii', but
otherwise has absolutely no effect. Chapters 12 and 14 of [1] include
some details as well. I seem to recall also Sasha (?) pointing out that
retaining the FR header made a PW mode suitable also for FCS retention,
but that's not in RFC 4720.

Thanks,

-- Carlos.
[1] "Layer 2 VPN Architectures", ISBN 1-58705-168-0