Subject: [Capwap] Keepalive on data channel

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 26 Jun 2006 07:08:55 -0700

All,
 
In a conversation with some of the L2TP folks, they have experience an
operational problem that we need to keep in mind. Basically, they
multiplex their control and data frames through their own header, and
mark their packets priorities based on control vs. data.

What they have found is that networks do route path selection based on
DSCP/ToS values, meaning that they send higher priority (control) frames
over different links than data frames. The network is not designed to
perform this solely for L2TP, as this is something they do for all of
their applications. The issue is that their protocol relies on a
keepalive frame that runs over the control channel, identically to
CAPWAP. However, the operational issue that they've found is that if the
path taken by the data channel is broken, and these frames are never
delivered.

The L2TP folks have found that the lack of a keepalive mechanism makes
it impossible to diagnose such an issue. When it occurs, the
administrator first has to figure out it is occurring, because the
protocol does not, and then needs to manually follow the path to find
the failure.

As far as I can tell, Scott's two primary issues with not wanting to
support UDP ports were:
1. NAT Traversal will require a keepalive on the data channel. As noted
above, we need to add a keepalive on the data channel in order to be
able to detect network routing failures.
2. Modifications to the state machine to handle data channel failure.
Given that such failures can occur, we need to be able to recover, if
possible.

I wanted to raise these issues as they are real, and actually
experienced in L2TP deployments. I believe we need to address these, and
if so, then I believe the complexity associated with the dual UDP port
ends up being resolved.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 26 Jun 2006 10:24:03 -0700 (GMT-07:00)

Hi Pat,

Since L2TP is a remote access protocol originally designed for dial-up remote access and then later used for generalized remote access over the Internet, any comparison with capwap is apples vs bananas at best.

However, I think this opens a more general question: what is a reasonable set of reference scenarios to address for capwap v1.0? Must we support each and every scenario any of us dreams up, or should we have a more narrow focus, with explicit plans to defer some things to later revisions of the protocol? A case in point has surfaced again and again in the multiport vs single port threads: must we support tunneling capwap control *and* data across arbitrary hop counts and administrative domains while expecting to maintain granular QoS?

Personally, I find this scenario unlikely to actually work in practice, and think that at best it's a corner case that should be relegated to the "not in 1.0" pile. I think it would be far more efficient to focus on an 80% solution. At least then there is some possibility of finishing in this decade.

Scott

> -----Original Message-----
> From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
> Sent: Monday, June 26, 2006 7:09 AM
> To: [email-masked]
> Subject: [Capwap] Keepalive on data channel
> 
> All,
>  
> In a conversation with some of the L2TP folks, they have 
> experience an operational problem that we need to keep in 
> mind. Basically, they multiplex their control and data frames 
> through their own header, and mark their packets priorities 
> based on control vs. data.
> 
> What they have found is that networks do route path selection 
> based on DSCP/ToS values, meaning that they send higher 
> priority (control) frames over different links than data 
> frames. The network is not designed to perform this solely 
> for L2TP, as this is something they do for all of their 
> applications. The issue is that their protocol relies on a 
> keepalive frame that runs over the control channel, 
> identically to CAPWAP. However, the operational issue that 
> they've found is that if the path taken by the data channel 
> is broken, and these frames are never delivered.
> 
> The L2TP folks have found that the lack of a keepalive 
> mechanism makes it impossible to diagnose such an issue. When 
> it occurs, the administrator first has to figure out it is 
> occurring, because the protocol does not, and then needs to 
> manually follow the path to find the failure.
> 
> As far as I can tell, Scott's two primary issues with not 
> wanting to support UDP ports were:
> 1. NAT Traversal will require a keepalive on the data 
> channel. As noted above, we need to add a keepalive on the 
> data channel in order to be able to detect network routing failures.
> Given that such failures can occur, we need to be able to 
> recover, if possible.
> 
> experienced in L2TP deployments. I believe we need to address 
> these, and if so, then I believe the complexity associated 
> with the dual UDP port ends up being resolved.

---

From: "Mani, Mahalingam (Mani)" <[email-masked]>
Date: Mon, 26 Jun 2006 18:22:17 -0600

It appears that in such a network - all flows marked for DSCP -based QoS
are at a diagnostic peril - each of a different kind - in such a failure
scenario.

-mani
-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Monday, June 26, 2006 7:09 AM
To: [email-masked]
Subject: [Capwap] Keepalive on data channel

All,

Pat Calhoun

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 26 Jun 2006 18:26:53 -0700

Mani,

Then I would recommend that you include folks from the Internet Area in
your discussions, as they have a number of tunneling standards efforts
underway, as well as operational experience.

Pat Calhoun

> From: Mani, Mahalingam (Mani) [mailto:[email-masked]] 
> Sent: Monday, June 26, 2006 5:22 PM
> To: Pat Calhoun (pacalhou); [email-masked]
> Subject: RE: [Capwap] Keepalive on data channel
> 
> It appears that in such a network - all flows marked for DSCP 
> -based QoS are at a diagnostic peril - each of a different 
> kind - in such a failure scenario.
> 
> -mani

---

From: "Mani, Mahalingam (Mani)" <[email-masked]>
Date: Tue, 27 Jun 2006 22:32:44 -0600

Pat,

The relevance of the 'Then' preceding the recommendation is not clear.

This is merely an observation of the implication of the behavior on this
given network policy instance. We expect the relevant areas to respond
when ADs take this up with them.

-mani
-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Monday, June 26, 2006 6:27 PM
To: Mani, Mahalingam (Mani); [email-masked]
Subject: RE: [Capwap] Keepalive on data channel

Mani,

Pat Calhoun