Re: FR over PWs

[cross-posting to [email protected], 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


On 11/20/2011 3:53 PM, Andrew G. Malis wrote:
> 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 protected]> wrote:
>> 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ó:
>>>
>>> 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 protected]>  wrote:
>>>>
>>>> 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?
>>>> _______________________________________________
>>>> pwe3 mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/pwe3
>>>>
>>
>>
> _______________________________________________
> pwe3 mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pwe3
>