[L2tpext] IETF 61 Working Group Minutes

["W. Mark Townsley" <[e-mail]>]

Many thanks to Sam Henderson, Dennis Frett, and David Hunter who all sent in 
notes from the l2tpext meeting. Following is my consolidation of the three. 
Please respond with any clarifications, additions, subtractions, etc. I will 
send these to the secretariat for archiving no earlier than Dec 1, and no later 
than Dec 10.

Thanks,

- Mark


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

WG Drafts:

L2VPN Extensions for L2TP
   draft-ietf-l2tpext-l2vpn-02.txt
Frame-Relay over L2TPv3
   draft-ietf-l2tpext-pwe3-fr-04.txt
HDLC Frames over L2TPv3
   draft-ietf-l2tpext-pwe3-hdlc-04.txt
ATM Pseudo-Wire Extensions for L2TP
   draft-ietf-l2tpext-pwe3-atm-02.txt
Transport of Ethernet Frames over L2TPv3
   draft-ietf-l2tpext-pwe3-ethernet-02.txt
   (-02 didn’t get posted for some unknown reason)
Fail Over extensions for L2TP "failover"
   draft-ietf-l2tpext-failover-04.txt

Expired/Stalled Drafts

L2TP Session Information "sesinfo"
   draft-ietf-l2tpext-sesinfo-04.txt
L2TP Tunnel Switching draft-ietf-l2tpext-tunnel-switching-04.txt
   draft-ietf-l2tpext-tunnel-switching-04.txt

Potential WG Drafts

RADIUS & L2TP Extended NAS-Port AVPs
   draft-nmcgill-l2tp-radius-ext-nas-port-02.txt
L2TP Call Information Messages
   draft-mistretta-l2tp-infomsg-01.txt
L2TPv3 Graceful Restart
   draft-galtzur-l2tpext-gr-02.txt
Layer Two Tunneling Protocol - Setup of TDM Pseudowires
   draft-galtzur-l2tpext-tdm-01.txt

No comments from the audience on status or agenda.

TDM Setup, Sasha Vainshtein
draft-galtzur-l2tpext-tdm-01.txt
--------------------------------
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

New AVPs
  - 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

    SESINFO draft

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

draft-galtzur-l2tpext-gr-02.txt

Objective:
  - Restart the control plane without affecting the forwarding state.
  - Customer traffic should not be disturbed.

How:
  - 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
-------------------------------------------

draft-ietf-l2tpext-failover-04.txt

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
        recovery
        synchronization

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



_______________________________________________
L2tpext mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/l2tpext