Carlos Pignataro | 4 Jul 2010 17:21
X-Face
Picon
Favicon

Re: L2TPext | Interest on Expired Milestones

Deadline passed, we will instruct the Secretariat to remove these
milestones from our charter.

Thanks,

-- Carlos.

On 6/10/2010 1:33 PM, Carlos Pignataro wrote:
> L2tpext,
> 
> We were discussing our Charter's past-due milestones with our Internet
> Area Advisor / AD Ralph during our phone conf. Ignacio and I took the
> action of following-up offline with the editors, authors, contributors,
> etc. on each document relating to a milestone; after that exercise we
> concluded that there does not appear to be enough energy or interest to
> continue these:
> 
> Mar 2008 WG Last Call on L2TP Proxy Authenticate Extensions for EAP
> Mar 2008 WG Last Call on L2TP Tunnel Switching
> Jun 2008 WG Last Call on L2TP RADIUS and Infomsg Extensions
> 
> We want to now ask broadly on the list, before having them removed. If
> you disagree with removing either of these 3 milestones, please reply
> (either on list or to the chairs at l2tpext-chairs <at> tools.ietf.org and Cc
> Ralph.)
> 
> Deadline for comments is July 1st.
> 
> Thanks,
> 
(Continue reading)

Javi Muñoz | 22 Jul 2010 13:19
Picon

RFC 4591 and RFC 4349

Ignacio,

Some yeras ago, you explained me the next working of the HDLCPWs and FRPWs:

===
a) HDLCPWs (port mode):

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

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

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

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.

b) FRoPW (DLCI mode):

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

(Continue reading)

Javi Muñoz | 22 Jul 2010 13:35
Picon

RFC 4591 and RFC 4349

[I resend the e-mail with the graphics fixed. Sorry the inconvenience]

Ignacio,

Some yeras ago, you explained me the next working of the HDLCPWs and FRPWs:

===
a) HDLCPWs (port mode):

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

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

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

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.

b) FRoPW (DLCI mode):

            C1                            C2
(Continue reading)

Ignacio Goyret | 22 Jul 2010 21:50
Favicon

Re: RFC 4591 and RFC 4349

At 01:35 PM 7/22/2010 +0200, Javi Muñoz wrote:

>b) FRoPW (DLCI mode):
>
>           C1                            C2
>  [ FR A ]----[ LCCE 1 ]------[ LCCE 2 ]----[ FR B ]
>
>               <------ L2TP FRoPW ---->
>         <---->                        <---->
>        FR traffic                   FR traffic
>
>...
>In this mode, the L2TP cloud behaves as if it were a FR switch.
>
>===

>b) FRPWs: according with your explanation, I would understand the next one:
>
>                                           ¿ ?
>                                            |
>                                            |
>                                           \ /
>DTE - PE/DCE <== FRPW ==> PE/DCE - ¿DTE? <== Data Network ==> DCE - DTE
>  <Q.933>                     <Q.933>                          <Q.933>
>  <-------------------------- FR VC -------------------------------->
>  <DLCI_1> [DLCI switching] <DLCI_2>     [ DLCI switching ]   <DLCI_3>
>           [DLCI_1 => DLCI_2]            [DLCI_2 => DLCI_3]
>
>    However, it would not be possible, due to the access nodes to the data network must be DCEs.

(Continue reading)

Javi Muñoz | 23 Jul 2010 10:59
Picon

Re: RFC 4591 and RFC 4349

Hi Ignacio,

b) FRoPW (DLCI mode): C1 C2 [ FR A ]----[ LCCE 1 ]------[ LCCE 2 ]----[ FR B ] <------ L2TP FRoPW ----> <----> <----> FR traffic FR traffic ... In this mode, the L2TP cloud behaves as if it were a FR switch. ===
b) FRPWs: according with your explanation, I would understand the next one: ¿ ? | | \ / DTE - PE/DCE <== FRPW ==> PE/DCE - ¿DTE? <== Data Network ==> DCE - DTE <Q.933> <Q.933> <Q.933> <-------------------------- FR VC --------------------------------> <DLCI_1> [DLCI switching] <DLCI_2> [ DLCI switching ] <DLCI_3> [DLCI_1 => DLCI_2] [DLCI_2 => DLCI_3] However, it would not be possible, due to the access nodes to the data network must be DCEs.
I imagine that if someone wanted to use FR over an L2TP PW, the LCCEs (or the devices feeding into the LCCEs) would have to be DCE or DTE as needed. There are many devices out there that can be configured as either DCE or DTE so this shouldn't really be a problem.

I need to detail this scenario for an specific application of the FRPWs (to ISDNs).

According to the working of the FRPWs, I think that the DTE/DCE funcionality of each CEs and PEs would be:

CE1(DTE) - PE1(DCE) <== FRPW(DLCI switching) ==> PE2(DCE) - CE2(DTE) However, when I consider a back to back comunication between tww FR terminals, that behaviour is not coherent with the classical FR working:

CE1(DTE,FR terminal) - PE1(DCE) <=FRPW=> PE2(DCE) - CE2(DTE) <=Data Network=> DCE - DTE (FR terminal) From the point of view of the "Data network", it would be:

CE1(DTE,FR terminal) - PE1(DCE) <=FRPW=> PE2(DTE) - CE2(DCE) <=Data Network=> DCE - DTE (FR terminal)


but it would not coincide with the "DLCI swithing" working of the FRPWs.


Could you help me to assign the DTE or DCE behaviour of each equipment in this back-to-back communication?


Thanks,

Javi

_______________________________________________
L2tpext mailing list
L2tpext <at> ietf.org
https://www.ietf.org/mailman/listinfo/l2tpext

Gmane