Last Modified: 2004-09-14
|Done||Submit L2TP over Frame Relay to IESG for consideration as a Proposed Standard|
|Done||Submit L2TP Security to IESG for consideration as a Proposed Standard|
|Done||Submit L2TP PPP Disconnect Information to IESG for consideration as a Proposed Standard|
|Done||Submit L2TP ATM extensions to IESG for consideration as a Proposed Standard|
|Done||Submit L2TP MIB to IESG for consideration as a Proposed Standard|
|Done||Submit L2TP Link Information to IESG for consideration as a Proposed Standard|
|Done||Submit L2TP Session Info to IESG for consideration as a Proposed Standard|
|Done||Submit L2TP Differentiated Services to IESG for consideration as a Proposed Standard|
|Done||Submit L2TP over AAL5 to IESG for consideration as a Proposed Standard|
|Done||Submit initial Internet-Draft of L2TP Base Specification|
|Done||Submit initial Internet-Draft of PPP over L2TP|
|Done||Submit final Internet-Draft of L2TPv3 Base Specification to IESG|
|Jan 04||Submit Internet-Draft of HDLC over L2TPv3 to IESG|
|Jan 04||Submit Internet-Draft of Frame Relay over L2TPv3 to IESG|
|Feb 04||Submit Internet-Draft of Ethernet over L2TPv3 to IESG|
|Mar 04||Submit L2TP Header Compression to IESG for consideration as a Proposed Standard|
|Apr 04||Submit Internet-Draft of PPP over L2TPv3 to IESG|
|RFC3070||PS||Layer Two Tunneling Protocol (L2TP) over Frame Relay|
|RFC3145||PS||L2TP Disconnect Cause Information|
|RFC3193||PS||Securing L2TP using IPSEC|
|RFC3301||PS||Layer Two Tunnelling Protocol : ATM access network extensions|
|RFC3308||PS||L2TP IP Differentiated Services Extension|
|RFC3355||PS||L2TP Over AAL5|
|RFC3371||PS||Layer Two Tunneling Protocol 'L2TP' Management Information Base|
|RFC3437||PS||Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation|
|RFC3438||BCP||L2TP IANA Considerations Update|
|RFC3573||PS||Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP)|
|RFC3817||I||L2TP Active Discovery Relay for PPPoE|
Agenda Bashing and Status, Mark Townsley
Last met, July 2003, Vienna.
New RFCs Since:
RFC3817, L2TP active discovery relay for PPP over Ethernet
RFC3931, L2TPv3 (in the RFC editor's queue)
Draft-ietf-l2tpext-mcast-05.txt approved for publication
L2VPN Extensions for L2TP
Frame-Relay over L2TPv3
HDLC Frames over L2TPv3
ATM Pseudo-Wire Extensions for L2TP
Transport of Ethernet Frames over L2TPv3
(-02 didnít get posted for some unknown reason)
Fail Over extensions for L2TP "failover"
L2TP Session Information "sesinfo"
L2TP Tunnel Switching draft-ietf-l2tpext-tunnel-switching-04.txt
Potential WG Drafts
RADIUS & L2TP Extended NAS-Port AVPs
L2TP Call Information Messages
L2TPv3 Graceful Restart
Layer Two Tunneling Protocol - Setup of TDM Pseudowires
No comments from the audience on status or agenda.
TDM Setup, Sasha Vainshtein
TDM PW requires exchange of
- AC bit rate
- packet payload size
- Usage of RTP header
- AC trunk type - prevent E1 from being connected to T1
- TDM PW AVP
flags: rtp header, fragmentation of TDM multiflags
- Discussion on a defined flag that is no longer used.
- Comments about providing a failure reason when tearing down link due to parameter mismatch. Sasha agreed to look into providing this.
- Proposal: Accept this draft as a WG document & solicit discussion on the mailing list. No substantive objections raised.
Tom Mistretta - RADIUS-EXT/infoMsg/sesinfo
Propose to consolidate all the NAS info drafts to Radius draft.
- LAC - LNS info exchange msgs
- Three drafts going to three separate directions -- radext, sesinfo and infomsg
- Want to propagate NAS-port info from one end of network to other, for use in service provider billing --
- Central problem that 32-bit "physical channel ID" is not a number people can use;
- Currently have many different proprietary ways to do this;
- Also people want just to send simple debug msgs between LAC and LNS;
- There are resulting tunnel-switching complications to tackle as well
- Infomsg talked about debug
- Propose to let infomsg and sesinfo expire
- Continue with the Radius draft
Tom Narten: Need to get radext group signoff for RADIUS extension; as AD I will not go to Last Call until they have reviewed it; shouldn't have to present in Radext, just send to their group; Mark mentioned Glen Zorn would be good reviewer -- knows both L2TP and RADIUS
Tom Mistretta - Tunnel Switching
Propose to update tunnel-switching draft and send out early next year. Potentially remove loop detection - not much concern in audience about tunnel switching loops.
Congestion Problem: Congestion on tunnel switch aggregator (TSA) is not propagated back to the LAC; LAC might be tring to do load balancing, but not even know there is a TSA out there; only solution we know of is propagating far too much info back; we believe this can be solved in a standards approach simply by having a new message ("resources unavailable, temporary condition" message -- as have elsewhere)
MarkT: PWE3 also tackling the "PW-switching" problem. Need to reconcile this with PWE3 and L2TPv3
Try to deliver new draft to mailing list by early next year.
Sasha - L2TP Graceful Restart Overview
- Restart the control plane without affecting the forwarding state.
- Customer traffic should not be disturbed.
- behavior is split between the two peers
- peer of the restarting LCCE detects loss of control connection
- postpones breaking the associated sessions.
Protocol changes: Two new AVPs. New session state. No new security issues. Same security methods as in the native l2tpv3. Partial graceful restart support possible.
(Greg Daley) Concern about security in allowing forwarding state to remain and potentially be extended for an amount of time after the control connection goes down.
Ans: Forwarding state is kept only for finite amount of time after the control connection goes down. If a new control connection is not authenticated in a given time - the forwarding state is removed.
L2TPv3 Failover, Tom Mistretta, Paul Howard
Each L2TP peer has configured and dynamic stateful info
Need protocol ext for reconciling states between peers
Re-sync 3 phases;
pre-failover during control channel setup
Sam Henderson galtzur-l2tpext-gr vs. ietf-l2tpext-failover
- Galtzur establishes whole new control connection after failover
- Failover draft establishes new temporary control chan to reset/resync original control channel;
- After recovery time, query peer for sessions that appear to be stale
- Combining these:
- Need recovery tunnel concept to prevent updating data plane with new tunnel ID for v2
- Allow normal processing of ICRQs with GR AVP and receiving traffic to refresh
- End up with limiations of one and complexities of the other
- So now it is easier to implement both drafts separately
Mark: So far it seems like everyone wants 2 drafts