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.