[L2tpext] Draft minutes from l2tpext

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 <townsley@cisco.com> 

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

Juha Huien (JH) - If you set up an l2tp session how does 
     app know of the attachment
JL - Defined by the app
JH - Applications need to register identifier 
MT - PW type and end ident (opaque type defined by higher layer)
     help this identification, but there is not a lot of help
     in the protocol per se.
     Need something like JH VPLS @ DNS draft
     Additional AVPs, or a "application type" AVP, may be needed

14:40 L2TPv3 MIB
      Jed Lau
      draft-ietf-l2tpext-l2tpmib-base-00.txt

Payload specific l2tp mib - not the same as pwe3 payload

Jun Kyun  - How do we combind l2tp xport mib with MPLS MIB
JL - defines transport and l2tp session specific
JL - when L2TP runs over mpls may not be able to 
     combine mib
     Concen at overlap between xport layer mibs and 
     l2tp mibs
JL - mibs will only be created if needed and will be
     l2tp session specific 

14:50 L2TP Call Information Messages
      W. Mark Townsley (for Tom Mistretta)
      draft-mistretta-l2tp-infomsg-00.txt

Radius stuff will be moved to radius mib leaving just
l2tp stuff. Vendor specific info - "text"
Request accept as WG doc.
Need to resolve conflict/intersections with atmex and sessio

Glen - Standards a good thing by as you said much of this is
       vendor specific. Don't we need to do better than text
       messaging (ie vendor specific AVP's because need to do
       machine interpretation.

MT   - This is for human readable trouble-shooting only.
       MAchines should not attempt to understsnd these msgs

Glen - Fine, but customers may want to act on data, so may
       make more sence to have vendor specific AVP's.

MT   - Asked industry and answer was needed only for trouble
       shooting. This is better than putting it into 32bit physical 
       channel id as some people are trying to do.

JH   - Why can't the vendor id be defined
MT   - Problem encourages vendor specific rather than standard
       behaviour. Also names change.
??   - Could send SMI code.

_______________________________________________
L2tpext mailing list
L2tpext@ietf.org
https://www1.ietf.org/mailman/listinfo/l2tpext