Subject: [L2tpext] L2TPEXT Milestones past due

From: Ignacio Goyret <[email-masked]>
Date: Thu, 15 Dec 2005 19:54:52 -0800

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
>---------------------------------------------------------------------------------
>
>Past Due Milestones:
>
>Mar 04  Submit L2TP Header Compression to IESG for consideration as a Proposed 
>        Standard 
>Jan 05  Submit Internet-Draft of HDLC over L2TPv3 to IESG 
>Jan 05  Submit L2VPN Extensions for L2TP to IESG 
>Feb 05  Submit Internet-Draft of Ethernet over L2TPv3 to IESG 
>Mar 05  WG Last Call on L2TP RADIUS and Infomsg Extensions 
>---------------------------------------------------------------------------------

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

---

From: Vipin Jain <[email-masked]>
Date: Thu, 15 Dec 2005 20:35:31 -0800 (PST)

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

> >status reports regarding these milestones directly to your Area Directors.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: Mark Townsley <[email-masked]>
Date: Fri, 16 Dec 2005 13:05:06 +0100

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:

>>>Mar 04  Submit L2TP Header Compression to IESG for consideration as a
>>>      
>>>
>>Proposed 
>>    
>>
>>>       Standard

---

From: Ignacio Goyret <[email-masked]>
Date: Fri, 16 Dec 2005 11:44:19 -0800

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

---

From: Carlos Pignataro <[email-masked]>
Date: Fri, 16 Dec 2005 16:22:41 -0500

Hi Ignacio,

Please see inline.

>>status reports regarding these milestones directly to your Area Directors.

The Milestone above (HDLC over L2TPv3 to IESG) is actually Done, but
"PPP over L2TPv3 to IESG" Milestone (an active document) shows Done in
the charter when it's not:
	Done	  	Submit Internet-Draft of PPP over L2TPv3 to IESG

It appears there was a mistake when the FR and HDLC I-Ds were submitted
to the IESG, the FR and PPP (mistakenly instead of FR and HDLC)
Milestones were updated as Done in the charter. The previous value for
PPP over L2TPv3 was:
	Apr 04	  	Submit Internet-Draft of PPP over L2TPv3 to IESG

Additionally, as Vipin already mentioned, I think `L2TP Failover' and
`L2TP Tunnel Switching' to IESG (that were recently WG LC'ed) should be
Milestones. Finally, the ATM, TDM and IP over L2TPv3 active documents do
not have any associated Milestones.

Thanks and Happy Holidays !

--Carlos.

-- 
--Carlos.
Escalation RTP - cisco Systems

---

From: Ignacio Goyret <[email-masked]>
Date: Fri, 16 Dec 2005 20:56:03 -0800

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):

     "...For tunnel sessions,
     the inconsistency in its sequence numbers, when used, can cause
     significant data loss thus giving perception of "service loss" to the
     end user."
  to 
     "...For tunnel sessions,
     the inconsistency in its sequence numbers, when used, can cause
     significant data loss thus giving the perception of "service loss" to the
                                       ^^^
     end user."

* Page 4:
  This text needs clarification or a rewrite:

  "Upon establishing the recovery tunnel two endpoints reset
   their control and/or data channel; after which recovery tunnel could
   be torn down."

  The use of the word "reset" is one of the confusing points here.

  Is this what you meant?

     "Using the recovery tunnel, the two endpoints reestablish the
      control and/or data channels of the recovered tunnel. The recovery
      tunnel can then be torn down."

* Page 4: (nitpicking)
     "To synchronize, two endpoints first silently clear the sessions that
     were not in established state. At this point they can allow new
     sessions to establish on the recovered tunnel."
  to
     "To synchronize, the two endpoints first silently clear the sessions
                      ^^^
     that were not in the established state. At this point, they can allow
                      ^^^                                 ^
     new sessions to establish on the recovered tunnel."

* Failover Capability AVP:

  - There is no explanation of what is the meaning of a C-bit set to 0,
    and it is not clear to me why is the C-bit needed at all. Isn't the
    presence of this AVP sufficient indication that the sender is capable
    of understanding failover?

  - This text (for the D-bit) needs rewording:

      "This bit is applicable only for the sessions using sequence numbers
       on the data channel i.e. data channel failure on the system not
       exhibiting D bit capability could still recover sessions that do
       not use sequence numbers."

    The section after "i.e." needs special care.

* Section 2.2:
- page 5 (nitpicking)
    "For control channel failure, failed endpoint establishes a new..."
  to
    "After a control channel failure, the failed endpoint establishes a new..."
     ^^^^^^^                          ^^^

- page 6:
  "...recovery tunnel...
   An endpoint SHOULD not send any control message on this tunnel, other than
   those required to manage the life of the recovery tunnel."

  I think we should be explicit as to which control messages should or should
  not be used. An explicit list helps interoperability.

- Tunnel Recovery AVP:

  How does an endpoint know which tunnels to recover? Should this information
  somehow have been exchanged between points A and B (in the above diagram)
  before the failure?

  The draft should provide some hints. If it is intended to be implementation
  specific, it should say so.

- Suggested Control Sequence AVP:

  I find odd that the name of the AVP includes the word "suggested" in it but
  the text describing it says that if present, the values of Nr and Ns MUST be
  set as indicated. If that's so, then the word "suggested" seems inappropriate.

There are more nitpicking details, but I really have to run now.
We can pick this up upon my return in mid-Jan.

Also, idnits-1.82 (http://tools.ietf.org/tools/idnits/) notes the
following issues that may need to be corrected:

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  * The document seems to lack separate sections for Informative/Normative
    References.
    
    Checking conformance with RFC 3978/3979 boilerplate...

  * Found rfc3978 Section 5.4 paragraph 1 boilerplate (on line 616), which
    is fine, but *also* found rfc2026 Section 10.4C paragraph 1 boilerplate on
    line 33. It should be removed.

  (rfc2026 Section 10.4C paragraph 1 text:
    "Copyright ([Cc]) The Internet Society (2005).  All Rights Reserved.")

  (rfc3978 Section 5.4 paragraph 1 text:
    "Copyright (C) The Internet Society (2005).")

  * The document seems to lack an RFC 3979 Section 5, para 3 IPR Disclosure
    Invitation. 

  (rfc3979 Section 5 paragraph 3 text:
    "The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard.  Please address the information to the IETF at
    [email-masked].")

Cheers,
-Ignacio

---

From: Vipin Jain <[email-masked]>
Date: Mon, 19 Dec 2005 09:08:17 -0800 (PST)

Ignacio,

Thanks for the review. Some comments inline.

>   A diagram like this (assuming it is correct) would go a long way to help:
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
should be avoided, please let me know if you still feel otherwise.

>   throughout the draft but there is no explanation what do you mean.
Correct point. I will define them in the Terminology.

>   The use of the word "reset" is one of the confusing points here.
The definition of Control/Data plane reset is defined in section 2.2.2, perhaps I'll refer that in
the text to make it clear.

>     of understanding failover?
C-bit and D-bit could be set indepdently. If D-bit is set of zero, as per the definition of C-bit,
an end point could not initiate or respond to control channel failure. Then it would send this AVP
only to indicate D-bit capability.

>     The section after "i.e." needs special care.
How about:
"This bit governs the failover capability for sessions using sequence numbers. Sessions that do
not use sequence numbers need not exhibit this capability to successfully recover from the data
channel failure."

If you have a particular text in mind, please feel free to suggest.

>   not be used. An explicit list helps interoperability.
How about:
An endpoint SHOULD only send messages required for the control connection management (section 3.2
[L2TPv2], section 3.1 [L2TPv3]): SCCRQ, SCCRP, SCCCN, StopCCN, StopCCN, HELLO and ZLB-Ack.

>   specific, it should say so.
It is implementation specific, as indicated in section 2.2.1 in the beginning of page 6 ("for
every old tunnel it wishes to recover..").

> We can pick this up upon my return in mid-Jan.
Sure.

I will also take care of some of the I-D nits you identified. 

thanks,
-- vipin