Subject: [L2tpext] RFC 4591 and RFC 4349: DLCI at egress LCCE

From: Javi <[email-masked]>
Date: Tue, 15 Jun 2010 19:46:09 +0200

+ Frame Relay traffic transported in a "virtual circuit-to-virtual 
circuit" mode by L2TPv3 FRPW: Due to local significance of the DLCI, the 
egress LCCE re-writes the DLCI.

     RFC 4591 (L2TPv3 FRPW), clause 5
     The Frame Relay frame is transported in its entirety, including the 
DLCI ...  The egress LCCE re-writes the DLCI...

+ Frame Relay traffic transported in a "port" mode by L2TPv3 HDLCoPW 
(RFC 4349): It's not mentioned any DLCI modification at the egress LCCE. 
Why is it not necessary here (similarly, DLCI significance is local)?

Javi

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 15 Jun 2010 14:42:04 -0500

Javi,

Because the "port mode" does not have granularity/visibility into the
DLCI level.

Thanks,

-- Carlos.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Javi
Sent: Tuesday, June 15, 2010 1:46 PM
To: [email-masked]
Subject: [L2tpext] RFC 4591 and RFC 4349: DLCI at egress LCCE

Javi
_______________________________________________
L2tpext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/l2tpext

---

From: Javi <[email-masked]>
Date: Wed, 16 Jun 2010 01:28:49 +0200

Carlos,

I agree, but I don't understand why. If a Frame Relay circuit is 
transported over a L2TPv3 HDLCoPW, the egress LCCE builds a FR frame 
with the same DLCI as the FR frame received by the ingress LCCE. If DLCI 
has local significance, CE/ingress_LCCE may use a different DLCI as 
CE/egress_LCCE. Why is not required here that the egress LCCE re-writes 
the DLCI (although it's not visible to PW)?.

Thanks,

Javi

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 15 Jun 2010 23:45:37 -0400

Javi,

If the DLCIs are different then you cannot use the HDLCoPW. Or a  
different way, for port mode DLCIs need to match (it is extending a  
port) and for different DLCIs you need FRoPW.

Thanks,

Thumb typed by Carlos Pignataro.

On Jun 15, 2010, at 7:29 PM, "Javi" <[email-masked]> wrote:

> with the same DLCI as the FR frame received by the ingress LCCE. If  
> DLCI has local significance, CE/ingress_LCCE may use a different  
> DLCI as CE/egress_LCCE. Why is not required here that the egress  
> LCCE re-writes the DLCI (although it's not visible to PW)?.
>
> Thanks,
>
> Javi
>
>
>
> Carlos Pignataro (cpignata) escribiÃ³:
>> Javi,
>>
>> + Frame Relay traffic transported in a "port" mode by L2TPv3  
>> HDLCoPW (RFC 4349): It's not mentioned any DLCI modification at the  
>> egress LCCE.
>>

---

From: Javi <[email-masked]>
Date: Wed, 16 Jun 2010 13:29:05 +0200

Carlos,

Each CE decides the DLCI by itself (and dinamically for switched virtual 
circuits, sopported by HDLCoPW).

How may you know if both CEs use different DLCIs?. If you want to use 
HDLCoPW, you would need to ensure that.

Thanks,

Javi

El 16/06/2010 5:45, Carlos Pignataro (cpignata) escribió:
>> DLCI has local significance, CE/ingress_LCCE may use a different DLCI 
>> as CE/egress_LCCE. Why is not required here that the egress LCCE 
>> re-writes the DLCI (although it's not visible to PW)?.
>>
>> Thanks,
>>
>> Javi
>>
>>
>>

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 16 Jun 2010 07:43:55 -0400

Javi,

Please note from RFC4349:

http://tools.ietf.org/html/rfc4349#section-4.1

   Since all packets are passed in a largely transparent manner over the
   HDLCPW, any protocol that has HDLC-like framing may utilize the
   HDLCPW mode, including PPP, Frame-Relay ("port to port" Frame-Relay
   transport), X.25 (LAPB), etc.  In such cases, the negotiations and
   signaling of the specific protocols transported over the HDLCPW take
   place between the Remote Systems.  A non-exhaustive list of examples
   and considerations of this transparent nature include:
[...]
      o When the HDLCPW transports Frame-Relay traffic, PVC status
        management procedures (Local Management Interface) take place
        between Remote Systems, and LCCEs do not participate in LMI.
        Additionally, individual Frame-Relay virtual-circuits are not
        visible to the LCCEs, and the FECN, BECN, and DE bits are
        transported transparently.

Think of the HDLCoPW as a cable, with "CEs" connected back-to-back on
that port. Any configuration would need to use the same DLCIs, and any
potential signaling would be CE to CE (needing to match DLCIs).

So, again, if DLCIs are different then you cannot use the HDLCoPW.

Thanks,

-- Carlos.

---

From: Javi <[email-masked]>
Date: Wed, 16 Jun 2010 17:00:48 +0200

Carlos,

Thanks for your clarification.
> potential signaling would be CE to CE (needing to match DLCIs).
What CE to CE signalling would you use to match DLCIs?, Q.933?

Thanks

Javi

---

From: Ignacio Goyret <[email-masked]>
Date: Fri, 18 Jun 2010 12:20:11 -0700

[due to an error on my part, this response didn't go to the list -
  please, accept my apologies if you get a duplicate]

> What CE to CE signalling would you use to match DLCIs?, Q.933?

Javi,
May be a diagram may help clarify the idea:

             C1                            C2
    [ FR A ]----[ LCCE 1 ]------[ LCCE 2 ]----[ FR B ]

                <------ L2TP HDLCoPW ---->

            <------------- FR traffic ------->

In other words, the above set of devices will behave exactly
the same (bit for bit on cables C1 and C2) as if C1 and C2
were the same physical cable, eg:

    [ FR A ]----..........................----[ FR B ]

            <------------- FR traffic ------->

where the series of dots above represents the transparent PW
between LCCE 1 and LCCE 2.

Hope this makes sense,
-Ignacio

---

From: Javi <[email-masked]>
Date: Fri, 18 Jun 2010 21:37:09 +0200

Ignacio,

Thanks for the diagram.

The doubt is about FRoPW:

            C1                            C2

               <------ L2TP FRoPW ---->

 From the CE point of view, FR link is finished by remote system?:

or by its LCCE?:

            C1                            C2

               <------ L2TP FRoPW ---->

           <---->                       <---->
         FR traffic                   FR traffic

Thanks,

Javi

---

From: Ignacio Goyret <[email-masked]>
Date: Fri, 18 Jun 2010 12:46:53 -0700

> The doubt is about FRoPW:

Ok, this is a different question. You were asking earlier about FR in 
"port mode" which is HDLCoPW, not FRoPW.

>   [ FR A ]----[ LCCE 1 ]------[ LCCE 2 ]----[ FR B ]

where "FR traffic" here means Q933 exchanges. The actual data traffic
for each PVC is obviously transported end to end (ie, FR A to FR B
and viceversa).

  >  From the CE point of view, FR link is finished by remote system?:

Yes, because the DLCIs in _this_ mode have local significance.
In other words, Q933 exchanges happen between "FR A" and "LCCE 1" in
one end and between "FR B" and "LCCE 2" on the other end.

In this mode, the L2TP cloud behaves as if it were a FR switch,
if that makes it easier to understand.

-Ignacio