Comments on draft-ietf-l2tpext-mcast-02.txt

Bonjuor Gilles,

Please find comments and questions inline by WMT. 

Thanks,

- Mark 

Network Working Group                                         G. Bourdon 
Internet Draft                                        France Telecom R&D 
Document: draft-ietf-l2tpext-mcast-02.txt                    August 2002 
Category: Experimental                                                   

                        L2TP Multicast Extension 
                   <draft-ietf-l2tpext-mcast-02.txt> 

 
Status of this Memo 

   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026. 

   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that other 
   groups may also distribute working documents as Internet-Drafts. 
   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time. It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 

Short-lived Design Team for Ethernet over L2TP doc

I have been contacted by several individuals interested in contributing 
to the ethernet over L2TP document. We will begin with the L2TP-specific 
text in draft-so-pwe3-ethernet-01.txt, and align it with the other 
l2tpext pwe3 drafts for Frame Relay and HDLC. This document is only for 
L2TP-specifics. It will focus strictly on the end to end protocol 
mechanisms for the PW itself when operating with L2TP.
It is not a VPLS document, nor an applications document.

I would like to create a small, short-lived, design team list to 
facilitate editorial details. Obviously, this is not a replacement for 
the pwe3 or l2tpext WG lists, it is merely a place for the editors to 
pass around text for version -00 which will be immediately posted to the 
WG lists for general discussion and review.

If you have spoken with me before about this effort, or can provide 
active involvement on this document, please send me email.

Thanks,

- Mark

RE: Comments on draft-ietf-l2tpext-mcast-02.txt

Hi,

Thanks again for your comments, my questions/comments inline (GB:).

Gilles.

-----Message d'origine-----
De : W. Mark Townsley [mailto:townsley <at> cisco.com]
Envoye : vendredi 2 aout 2002 16:33
A : BOURDON Gilles FTRD/DAC
Cc : l2tpext <at> ietf.org
Objet : Comments on draft-ietf-l2tpext-mcast-02.txt

Bonjuor Gilles,

Please find comments and questions inline by WMT. 

Thanks,

- Mark 

Network Working Group                                         G. Bourdon

Internet Draft                                        France Telecom R&D

Document: draft-ietf-l2tpext-mcast-02.txt                    August 2002

Category: Experimental

 

List of clarifications for next revision of the PPPoE Relay draft

Ron and I tried to capture the issues that need clarification in the 
pppoe relay draft from the thread a few weeks ago. Many thanks to David 
F. Skoll and Vipin Jain for their helpful comments, review and 
discussion. Following are the issues that we will address in the next 
version. Please let me know if the list is incomplete or in error.

Thanks,

- Mark & Ron

"Service Relay Request Message" as "SRRQ" typo fix

Near the bottom of Page 4: "The MAC address of the PADO MUST be the same 
as that which was utilized..." PADO should read PADS.

Exactly one Host-Uniq or AC-Cookie tag per PAD message.

Clients are supposed to treat AC-Cookie as a black box.  They 
distinguish PADO's only by MAC address, Service-Name tag(s) and AC-Name 
tag(s).  If an LAC sends multiple PADO's, they should contain different 
AC-Name tags.

Clarify "Relay Forward Capability" and "Relay Response Capability" 
mechanism.

Exactly one PPPoE Relay AVP is allowed per L2TP SSRP Message.

A node performing PPPoE L2TP Relay SHOULD attempt to distinguish 
retransmitted PADx messages (perhaps via the source MAC address and/or 

Re: RE: Comments on draft-ietf-l2tpext-mcast-02.txt

> BOURDON Gilles FTRD/DAC/ISS wrote:
>           
>    The Cause Code AVP SHOULD NOT be present in a multicast CDN message 
>    (because Q.931 Cause Codes make no sense in a multicast session 
>    context). However, the Cause Code AVP MUST be ignored if received in 
>    this context.
> 
> WMT An "MCDN" could be your own message along with the MCRQ/MCRP
> messages.
>        
> GB: Don't you think a CDN could suit to all Incoming/Outgoing/Multicast
> calls, since a CDN doesn't carry any information on the session type ?

Perhaps, particularly given that it is already shared among the ICxx and 
OCxx models. My only concern was in placing restrictions on what AVPs 
can and cannot be in the message (e.g. the Cause Code restriction). Some 
implementations sanity check a message when received against of list of 
AVPs that MUST/MAY be present for that message, so you might be making 
that ability more complex if you make this session-id context-dependent.

- Mark

Question concerning missing AVP between base-02 and base-03

I noticed in the draft-ietf-l2tpext-l2tp-base-03.txt in section 6.2
that the Firmware Revision is an optional AVP in the SCCRP message.
However this AVP is never defined in this document.

I remember reading about this attribute and was able to find it in
section 5.4.3 Control Connection Management AVPs in the older
base-02.txt file.

Is there a reason that this AVP has been removed in section 5.4.3 in
the latest version of the l2tpext-l2tp draft?

Anthony

Re: Question concerning missing AVP between base-02 andbase-03

On Tue, 6 Aug 2002, Anthony Chan wrote:

> I noticed in the draft-ietf-l2tpext-l2tp-base-03.txt in section 6.2
> that the Firmware Revision is an optional AVP in the SCCRP message.
> However this AVP is never defined in this document.

Thanks for catching this; it's a typo.  The Firmware Revision AVP has been
removed altogether from base-03 and should not be listed as a MAY AVP.

> I remember reading about this attribute and was able to find it in
> section 5.4.3 Control Connection Management AVPs in the older
> base-02.txt file.
>
> Is there a reason that this AVP has been removed in section 5.4.3 in
> the latest version of the l2tpext-l2tp draft?

The AVP has been removed in L2TPv3 because (1) its use has never been
clearly stated (either in RFC 2661 or in earlier L2TPv3 drafts), and (2)
it is not extensible when compared with newer proposals such as
<draft-mistretta-l2tp-infomsg-00.txt>.

Jed

> Anthony
>
>
>
>
> _______________________________________________

Draft minutes from l2tpext

Re: Draft minutes from l2tpext

Hi Cheng-Yin,

Which PWE3 drafts are you referring to?

The payload and application drafts that we discussed at IETF are
L2TP-specific, and thus, outside the sphere of PWE3.  For instance,
payload drafts can define payload-specific AVPs that are passed during
control connection or session negotiation.  Similarly, the application
drafts can define which AVPs are used for a particular application (e.g.
dial-up, cross-connect).

Jed

On 8 Aug 2002, Cheng-Yin Lee wrote:

> Regarding the payload (and application) drafts, are they not being
> specified in PWE3 WG, or perhaps I am missing something?
>
> thanks
> cheng-yin
>
>
> > [L2tpext] Draft minutes from l2tpext
> >
> >
> >
> >      To: l2tpext <at> ietf.org
> >      Subject: [L2tpext] Draft minutes from l2tpext
> >      From: "W. Mark Townsley"
> >      Date: Fri, 19 Jul 2002 10:22:12 +0900
> >      List-Id: Layer Two Tunneling Protocol Extensions
> >      Sender: l2tpext-admin <at> ietf.org
> >
> >
> >
> >
> > Please send comments, questions, or alternate recollections to the list.
> >
> > Layer Two Tunneling Protocol Extensions WG (l2tpext)
> >
> > TUESDAY, July 16 at 1415-1515
> > =============================
> >
> > CHAIR:  W. Mark Townsley
> >
> > AGENDA:
> >
> > 14:15 Agenda Bashing
> >       W. Mark Townsley
> >
> >
> > 14:20 L2TPEXT WG Update
> >       W. Mark Townsley
> >
> > No comments from floor - see slides.
> >
> > Any interest in mcast - no comments, will be put up
> > for last call.
> >
> > Need more participation in tunnel switching
> >
> > Please read pwe3-fragmentation and comment re 2661
> >
> > 14:30 L2TPv3 Update
> >       Jed Lau
> >       draft-ietf-l2tpext-l2tp-base-03.txt
> >
> > Need clarification of must and may L2TPv3 relative L2TPv2
> > Explained that must/may list resolved in v3 by checking what
> > made sense in the spec.
> > No comments on change to pw specific field or removal of offset.
> > Request for contribution - payload and application drafts
> >
>
>
>

Re: Draft minutes from l2tpext

Cheng-Yin Lee wrote:
> Regarding the payload (and application) drafts, are they not being 
> specified in PWE3 WG, or perhaps I am missing something?

Any extensions to l2tp itself, are done in l2tpext. Common mechanisms for a 
given pseudowire type are defined in PWE3, but when it comes to making 
extensions to l2tp (e.g. use of l2tp control messages, encapsulation, new AVPs, 
etc) this is done in l2tpext.

The "application" drafts, depending on how you define what an application is, 
are defined in ppvpn and perhaps other WGs or individual submissions.

- Mark

> 
> thanks
> cheng-yin
>  
> 
>>[L2tpext] Draft minutes from l2tpext
>>
>>
>>
>>     To: l2tpext <at> ietf.org 
>>     Subject: [L2tpext] Draft minutes from l2tpext 
>>     From: "W. Mark Townsley"  
>>     Date: Fri, 19 Jul 2002 10:22:12 +0900 
>>     List-Id: Layer Two Tunneling Protocol Extensions  
>>     Sender: l2tpext-admin <at> ietf.org 
>>
>>
>>
>>
>>Please send comments, questions, or alternate recollections to the list.
>>
>>Layer Two Tunneling Protocol Extensions WG (l2tpext)
>>
>>TUESDAY, July 16 at 1415-1515
>>=============================
>>
>>CHAIR:  W. Mark Townsley  
>>
>>AGENDA:
>>
>>14:15 Agenda Bashing
>>      W. Mark Townsley
>>
>>
>>14:20 L2TPEXT WG Update
>>      W. Mark Townsley
>>
>>No comments from floor - see slides.
>>
>>Any interest in mcast - no comments, will be put up
>>for last call.
>>
>>Need more participation in tunnel switching
>>
>>Please read pwe3-fragmentation and comment re 2661
>>
>>14:30 L2TPv3 Update 
>>      Jed Lau
>>      draft-ietf-l2tpext-l2tp-base-03.txt
>>
>>Need clarification of must and may L2TPv3 relative L2TPv2
>>Explained that must/may list resolved in v3 by checking what
>>made sense in the spec.
>>No comments on change to pw specific field or removal of offset.
>>Request for contribution - payload and application drafts
>>
> 
>