Layer Two Tunneling Protocol Extensions WG (l2tpext)
TUESDAY, July 16 at 1415-1515
=============================
CHAIR: W. Mark Townsley <
[email protected]>
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.
