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 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.