headers
Carlos Pignataro | 4 Jun 2010 03:41
X-Face
Picon
Favicon

Re: L2TPEXT review of L2TPv3 extensions in draft-ietf-pwe3-segmented-pw-15

L2tpext WG,

I would like to ask for two or three volunteers to review the L2TPv3
extensions defined in this document, mostly localized in Sections 8 and
14. Rev -15 just posted, but it does not appear to have L2TPv3 relevant
changes. Please volunteer and reply to l2tpext-chairs <at> tools.ietf.org if
you are willing. Thanks in advance !

Luca, PWE3,

Many Thanks for asking !

Please note that there was an early review by Matthew Bocci and myself
that you requested of the I-D rev draft-ietf-pwe3-segmented-pw-10, at
<http://www.ietf.org/mail-archive/web/pwe3/current/msg10236.html>. It
appears that there are comments including in Section 8 (and in
particular in Section 8.4.1 onwards) that seem to not have been
addressed (as per list archive thread or diff with new I-D rev).

Thanks,

-- Carlos.

On 6/3/2010 6:14 PM, Luca Martini wrote:
> L2TPEXT WG,
> he IESG as asked that you review the proposed L2TPv3 extensions 
> documented in draft-ietf-pwe3-segmented-pw-14.
> 
> These extensions are documented in section 8.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Carlos Pignataro | 9 Jun 2010 20:23
X-Face
Picon
Favicon

Re: [PWE3] L2TPEXT review of L2TPv3 extensions in draft-ietf-pwe3-segmented-pw-15

We received three responses volunteering to review the document for
L2TPext: Prashant Jhingran, Sam Aldrin, and Neil McGill in Cc.

The current version is at
<http://tools.ietf.org/html/draft-ietf-pwe3-segmented-pw-15>. Please
send your comments and Acks/Nacks to pwe3 <at> ietf.org, Cc to L2tpext <at> ietf.org.

Thanks,

-- Carlos, on behalf of L2TPext.

On 6/3/2010 6:14 PM, Luca Martini wrote:
> L2TPEXT WG,
> he IESG as asked that you review the proposed L2TPv3 extensions 
> documented in draft-ietf-pwe3-segmented-pw-14.
> 
> These extensions are documented in section 8.
> 
> Please advise us if you have any objections to the proposed additions.
> 
> Thanks.
> Luca Martini
> on behalf of pwe3 WG.
> 
> _______________________________________________
> pwe3 mailing list
> pwe3 <at> ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Neil McGill | 9 Jun 2010 21:23
Picon
Favicon

Re: [PWE3] L2TPEXT review of L2TPv3 extensions in draft-ietf-pwe3-segmented-pw-15


Acked, but it would be good to have at least a note that the LDP PW status 
TLV should be mapped to the L2TPv3 Extended Circuit Status Values TLV at 
switching points.  The mappings themselves are obvious enough.

The v3 TLV is specified in http://tools.ietf.org/html/rfc5641

Thanks,

Neil.

On Wed, 9 Jun 2010, Carlos Pignataro wrote:

> We received three responses volunteering to review the document for
> L2TPext: Prashant Jhingran, Sam Aldrin, and Neil McGill in Cc.
> 
> The current version is at
> <http://tools.ietf.org/html/draft-ietf-pwe3-segmented-pw-15>. Please
> send your comments and Acks/Nacks to pwe3 <at> ietf.org, Cc to L2tpext <at> ietf.org.
> 
> Thanks,
> 
> -- Carlos, on behalf of L2TPext.
> 
> On 6/3/2010 6:14 PM, Luca Martini wrote:
> > L2TPEXT WG,
> > he IESG as asked that you review the proposed L2TPv3 extensions 
> > documented in draft-ietf-pwe3-segmented-pw-14.
> > 
> > These extensions are documented in section 8.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Carlos Pignataro | 10 Jun 2010 19:33
X-Face
Picon
Favicon

L2TPext | Interest on Expired Milestones

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,

-- Carlos and Ignacio.
Permalink | Reply | 1 comment |
headers
Javi | 15 Jun 2010 16:56
Picon

RFC 4591: SVCs

===
RFC 4591, clause 1

Support for Switched Virtual Circuits (SVCs) and  Switched/Soft 
Permanent Virtual Circuits (SPVCs) are outside the scope of this document
===

Why does L2TPv3 FRoPW not support switched virtual circuits?

Javi
Permalink | Reply | 1 comment |
headers
Carlos Pignataro | 15 Jun 2010 18:53
X-Face
Picon
Favicon

Re: RFC 4591: SVCs

Javi,

The responses in the thread about RFC 4619 at
<http://www.ietf.org/mail-archive/web/pwe3/current/msg11280.html> are, I
think, also relevant and applicable to RFC 4591 and your question here.

The paragraph you quote does not say that RFC 4591 "does not support FR
SVCs". It says that it was not explored, as it was outside of scope.

Thanks,

-- Carlos.

On 6/15/2010 10:56 AM, Javi wrote:
> ===
> RFC 4591, clause 1
> 
> Support for Switched Virtual Circuits (SVCs) and  Switched/Soft 
> Permanent Virtual Circuits (SPVCs) are outside the scope of this document
> ===
> 
> Why does L2TPv3 FRoPW not support switched virtual circuits?
> 
> Javi
> _______________________________________________
> L2tpext mailing list
> L2tpext <at> ietf.org
> https://www.ietf.org/mailman/listinfo/l2tpext
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Javi | 15 Jun 2010 19:46
Picon

RFC 4591 and RFC 4349: DLCI at egress LCCE

+ 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
Permalink | Reply | 5 comments |
headers
Carlos Pignataro (cpignata | 15 Jun 2010 21:42
Picon
Favicon

Re: RFC 4591 and RFC 4349: DLCI at egress LCCE

Javi,

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

Thanks,

-- Carlos.

-----Original Message-----
From: l2tpext-bounces <at> ietf.org [mailto:l2tpext-bounces <at> ietf.org] On
Behalf Of Javi
Sent: Tuesday, June 15, 2010 1:46 PM
To: l2tpext <at> ietf.org
Subject: [L2tpext] RFC 4591 and RFC 4349: DLCI at egress LCCE

+ 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)?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Javi | 16 Jun 2010 01:28
Picon

Re: RFC 4591 and RFC 4349: DLCI at egress LCCE

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

Carlos Pignataro (cpignata) escribió:
> Javi,
>
> Because the "port mode" does not have granularity/visibility into the
> DLCI level.
>
> Thanks,
>
> -- Carlos.
>
> -----Original Message-----
> From: l2tpext-bounces <at> ietf.org [mailto:l2tpext-bounces <at> ietf.org] On
> Behalf Of Javi
> Sent: Tuesday, June 15, 2010 1:46 PM
> To: l2tpext <at> ietf.org
> Subject: [L2tpext] RFC 4591 and RFC 4349: DLCI at egress LCCE
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Carlos Pignataro (cpignata | 16 Jun 2010 05:45
Picon
Favicon

Re: RFC 4591 and RFC 4349: DLCI at egress LCCE

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" <javi <at> trajano.us.es> wrote:

> 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
>
>
>
> Carlos Pignataro (cpignata) escribió:
>> Javi,
>>
(Continue reading)

Permalink | Reply | 2 comments |

Gmane