headers
Ignacio Goyret | 8 Dec 2005 05:04
Picon
Favicon

draft-ieft-l2tpext-tdm-02.txt review

Hi,
Just a few minor details:
1) In section 2.1, in regards to the "Bit Rate" field, it reads:

    "Bit Rate is defined in [PWE3-IANA]. Its usage for all types of TDM
     PWs assumes the following semantics: 
     1. This interface parameter MAY be omitted, if the attachment circuit 
         bit-rate is unambiguously derived from the PW Type."

  Does this mean that the "Bit Rate" field can be omitted from the AVP?
  If so, how can you tell that this field is omitted but "Payload Bytes"
  is not?
  If that's not the case, the phrase needs to be rewritten to avoid confusions.
  May be a simple solution is to replace these paragraphs with something
  like this:

      "Bit Rate is defined in [PWE3-IANA]. Typically, it is expressed
       as the number of DS0 channels in the corresponding attachment
       circuit."

   Or even better:

      "Bit Rate is defined in [PWE3-IANA]."

2) There are similar issues on the definition of "Payload Bytes".
   For example, the term "payload type" is used in semantic #1.
   semantic number 2b probably needs to be rephrased to make it easier
   to parse and understand.

3) Why do you need the R bit in the TDM PW AVP? Why is the presence of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ignacio Goyret | 13 Dec 2005 01:47
Picon
Favicon

Re: I-D ACTION: draft-kelkar-l2tpext-eap-proxy-authen-ext-01.txt

Group,
It has been asked that this draft be taken as a work item of this WG.
Personally, I believe that would be appropriate but I want to give
people a chance to object. So, unless someone objects by the end of day
tomorrow Dec/13/2005 (Pacific), this draft will accepted as a WG item.

Agreements? Objections?
-Ignacio

At 16:36 11/28/2005 -0500, Mahesh Kelkar wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>	Title		: L2tp Proxy Authenticate Extensions for EAP
>	Author(s)	: M. Kelkar
>	Filename	: draft-kelkar-l2tpext-eap-proxy-authen-ext-01.txt
>	Pages		: 11
>	Date		: 2005-11-28
>	
>L2TP [1] defines Proxy Authentication AVPs that MAY be exchanged 
>   during session establishment, to provide forwarding of PPP 
>   authentication information obtained at the LAC to the LNS for 
>   validation.  This document defines contents of this PPP authenticate 
>   information for the Extensible Authentication Protocol (EAP).
>
>A URL for this Internet-Draft is:
><http://www.ietf.org/internet-drafts/draft-kelkar-l2tpext-eap-proxy-authen-ext-01.txt>
>
>To remove yourself from the I-D Announcement list, send a message to 
>i-d-announce-request at ietf.org with the word unsubscribe in the body of the message.  
>You can also visit <https://www1.ietf.org/mailman/listinfo/I-D-announce>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Carlos Pignataro | 13 Dec 2005 18:21
X-Face
Picon
Favicon

Re: I-D ACTION: draft-kelkar-l2tpext-eap-proxy-authen-ext-01.txt


Circa 12/12/2005 7:47 PM, Ignacio Goyret said the following:
> Group,
> It has been asked that this draft be taken as a work item of this WG.
> Personally, I believe that would be appropriate but I want to give
> people a chance to object. So, unless someone objects by the end of day
> tomorrow Dec/13/2005 (Pacific), this draft will accepted as a WG item.
> 
> Agreements? Objections?

I agree, I think this should become a WG document.

My only nit comment would be to make the `L2tp' acronym in the title all
upper case.

Thanks,

--Carlos.

> -Ignacio
> 
> 
> At 16:36 11/28/2005 -0500, Mahesh Kelkar wrote:
> 
>>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>>	Title		: L2tp Proxy Authenticate Extensions for EAP
>>	Author(s)	: M. Kelkar
>>	Filename	: draft-kelkar-l2tpext-eap-proxy-authen-ext-01.txt
>>	Pages		: 11
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ignacio Goyret | 16 Dec 2005 04:54
Picon
Favicon

L2TPEXT Milestones past due

As the message indicates, a lot of milestones on this WG are past due.
Some of that has been due to lack of attention from your chairs and
for that, let me apologize.

Some of the milestones are already completed (eg, 'submit I-D of HDLC
over L2TPv3'), others may not be applicable anymore, and we may need
to add new ones (eg, proxy EAP auth).

We need to come up with a realistic list of milestones. I want to ask the
group to discuss possible milestones and completion dates.

As I'm about to leave on a month long vacation, I won't be able to answer
any emails until my return. Hopefully, there will be plenty of good ideas
by then. :-)

Your input is highly appreciated.

Happy holidays,
-Ignacio Goyret

>Dear L2TPEXT Working Group Chair(s):
>
>Below is a list of the L2TPEXT Working Group milestones that are past due.
>Please be reminded that changes to existing milestones or due dates require
>Area Director approval.  Therefore, please send comments, requests, or
>status reports regarding these milestones directly to your Area Directors.
>
>The IESG Secretariat
>---------------------------------------------------------------------------------
>
(Continue reading)

Permalink | Reply | 752 comments |
headers
Vipin Jain | 16 Dec 2005 05:35
Picon
Favicon

Re: L2TPEXT Milestones past due

Ignacio,

Thank you for your attention.

I would certainly think 'L2TP Failover' and 'PPP over L2TP Tunnel Switching'
drafts be submitted to IESG for consideration as a proposed standard.

The work on both of them had started in year 2000 (they would be 6 years old
then!). Both documents are in WG last call.

thanks,
-- vipin

--- Ignacio Goyret <igoyret <at> lucent.com> wrote:

> As the message indicates, a lot of milestones on this WG are past due.
> Some of that has been due to lack of attention from your chairs and
> for that, let me apologize.
> 
> Some of the milestones are already completed (eg, 'submit I-D of HDLC
> over L2TPv3'), others may not be applicable anymore, and we may need
> to add new ones (eg, proxy EAP auth).
> 
> We need to come up with a realistic list of milestones. I want to ask the
> group to discuss possible milestones and completion dates.
> 
> As I'm about to leave on a month long vacation, I won't be able to answer
> any emails until my return. Hopefully, there will be plenty of good ideas
> by then. :-)
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Mark Townsley | 16 Dec 2005 13:05
Picon
Favicon

Re: L2TPEXT Milestones past due


As ex-chair, I fully agree, these have been around FOREVER. I'm just 
happy that someone like Vipin is still paying attention trying to get 
these efforts through. Ignacio, I think we need proto questionairres for 
these, and then a publication request.

- Mark

Vipin Jain wrote:

>Ignacio,
>
>Thank you for your attention.
>
>I would certainly think 'L2TP Failover' and 'PPP over L2TP Tunnel Switching'
>drafts be submitted to IESG for consideration as a proposed standard.
>
>The work on both of them had started in year 2000 (they would be 6 years old
>then!). Both documents are in WG last call.
>
>thanks,
>-- vipin
>
>
>--- Ignacio Goyret <igoyret <at> lucent.com> wrote:
>
>  
>
>>As the message indicates, a lot of milestones on this WG are past due.
>>Some of that has been due to lack of attention from your chairs and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ignacio Goyret | 16 Dec 2005 20:44
Picon
Favicon

Re: L2TPEXT Milestones past due

Hi Vipin,
Yes, it was my intention to finish that this week. Alas, customers
"conspired" to prevent me from finishing my work on that end.
Thanks for your amazing patience.
-Ignacio

At 20:35 12/15/2005 -0800, Vipin Jain wrote:
>Ignacio,
>
>Thank you for your attention.
>
>I would certainly think 'L2TP Failover' and 'PPP over L2TP Tunnel Switching'
>drafts be submitted to IESG for consideration as a proposed standard.
>
>The work on both of them had started in year 2000 (they would be 6 years old
>then!). Both documents are in WG last call.
>
>thanks,
>-- vipin
>
>
>--- Ignacio Goyret <igoyret <at> lucent.com> wrote:
>
>> As the message indicates, a lot of milestones on this WG are past due.
>> Some of that has been due to lack of attention from your chairs and
>> for that, let me apologize.
>> 
>> Some of the milestones are already completed (eg, 'submit I-D of HDLC
>> over L2TPv3'), others may not be applicable anymore, and we may need
>> to add new ones (eg, proxy EAP auth).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carlos Pignataro | 16 Dec 2005 22:22
X-Face
Picon
Favicon

Re: L2TPEXT Milestones past due

Hi Ignacio,

Please see inline.

Circa 12/15/2005 10:54 PM, Ignacio Goyret said the following:
> As the message indicates, a lot of milestones on this WG are past due.
> Some of that has been due to lack of attention from your chairs and
> for that, let me apologize.
> 
> Some of the milestones are already completed (eg, 'submit I-D of HDLC
> over L2TPv3'), others may not be applicable anymore, and we may need
> to add new ones (eg, proxy EAP auth).
> 
> We need to come up with a realistic list of milestones. I want to ask the
> group to discuss possible milestones and completion dates.
> 
> As I'm about to leave on a month long vacation, I won't be able to answer
> any emails until my return. Hopefully, there will be plenty of good ideas
> by then. :-)
> 
> Your input is highly appreciated.
> 
> Happy holidays,
> -Ignacio Goyret
> 
> 
> 
>>Dear L2TPEXT Working Group Chair(s):
>>
>>Below is a list of the L2TPEXT Working Group milestones that are past due.
(Continue reading)

Permalink | Reply | 751 comments |
headers
Ignacio Goyret | 17 Dec 2005 05:56
Picon
Favicon

Re: L2TP failover nits

Hi Vipin,
While reviewing your draft in preparation for publication, I found
a few details that need answers.

* Introduction:
  There are a few things which are not clearly answered in this draft.
  For instance, who are the players? (I assume there are three)
  A diagram like this (assuming it is correct) would go a long way to help:

                                            +--------------+
                                            | L2TP active  |
    +----------+                        ----| endpoint (A) |
    |   L2TP   |                       /    +--------------+
    | endpoint |-----( IP cloud )-----/
    |    (R)   |                      \     +--------------+
    +----------+                       \    | L2TP backup  |
                                        ----| endpoint (B) |
                                            +--------------+

   Using the above diagram's reference points, R, A and B, is it true that
   the L2TP endpoints are:
     - R and A for "old tunnels"
     - A and B for "recovery tunnels" (or is it R and B?)
     - R and B for "recovered tunnels"

* Terms:
  The terms "data channel failure" and "control channel failure" are used
  throughout the draft but there is no explanation what do you mean.

* Page 3 (nitpicking):
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vipin Jain | 19 Dec 2005 18:08
Picon
Favicon

Re: L2TP failover nits


Ignacio,

Thanks for the review. Some comments inline.

> * Introduction:
>   There are a few things which are not clearly answered in this draft.
>   For instance, who are the players? (I assume there are three)
>   A diagram like this (assuming it is correct) would go a long way to help:
> 
>                                             +--------------+
>                                             | L2TP active  |
>     +----------+                        ----| endpoint (A) |
>     |   L2TP   |                       /    +--------------+
>     | endpoint |-----( IP cloud )-----/
>     |    (R)   |                      \     +--------------+
>     +----------+                       \    | L2TP backup  |
>                                         ----| endpoint (B) |
>                                             +--------------+
> 
>    Using the above diagram's reference points, R, A and B, is it true that
>    the L2TP endpoints are:
>      - R and A for "old tunnels"
>      - A and B for "recovery tunnels" (or is it R and B?)
>      - R and B for "recovered tunnels"
Recovery tunnel is between R and B. The reason for not putting this in the draft is because A and
B resides in the same device and we'd rather not dictate how people model the redundancy in their
device. In many situations (as mentioned in the Introduction) there is a hot standby, even in
absense of such an entity, the recovery could be made - therefore B really need not exist as a
physical card or something, it could be reincarnation of A. I feel the classification like this
(Continue reading)

Permalink | Reply | 0 comments |

Gmane