Layer Two Tunneling Protocol Extensions (l2tpext)

Vipin Jain | 1 Oct 2003 08:45

Re: Hidden AVPs and NAT

Avinash,

my comments inline..

>   On other hand if you are not the originator, then
>   implementing NAT for incoming calls from outside is
>   little confusing. NAT, typically makes sense, when
>   connections/sessions (whether TCP, UDP, L2TP, etc.)
>   are initiated from within.
> 
>   Or did I not understand your point?
> 
>   ---Yes, i am always the originator, everything is initiated from inside the
> NAT.
>   But the prob is, the NAT i am talking about does a comparison for the
> entire session information
>   for any incoming packet. So comparison is made at nat for src ip,dstn
> ip,src port and 
>   dstn port. Now the source port of the SCCRP could be different from the
> 1701(since recepient
>   can use any free port as source port while responding to a SCCRQ). This wud
> cause
>   a failure in the NAT lookup. i've deviced a workaround for the same with
> the port table 
>   kindof thing i had sent earlier in the group as the basis...
True; The response to SCCRQ could have a different port (source port) not the
destination port, which would was indicated in SCCRQ. It invites keeping extra
information of mapped ports to be mapped to when doing NAT, i.e. it would have
to be stateful as opposed to stateless NAT. As indicated in section 8.1 the
solution is not very NAT friendly.

(Continue reading)

headers

Vipin Jain | 1 Oct 2003 23:49

Re: Questions about draft-ietf-l2tpext-failover-02.txt

Paul,

You have some good points and feedback.
I am responding to your original email while
keeping in mind the discussion you and Keyur have
had so far and bringing them to the list.
my comments inline..

> I've got some questions about the failover draft.
> 
> sec 2.3 - "Endpoints MUST avoid sending any control packets over the old 
> tunnel that is being recovered".   What is the behavior for in-transit 
> control packets?   I presume the receiver should silently discard any 
> control packets on the old tunnel (no acknowledgement, no action based 
> on received control packet).   I presume such behavior should start once 
> recovery is detected (either by failed endpoint sending new SCCRQ or by 
> failed endpoint's peer receiving new SCCRQ)?
True. Probably we we should clarify that the packets received on receiving end
MUST be sliently discarded.

> 
> sec 2.3.1, last bullet - "...it SHOULD clear the tunnel and sessions 
> within that tunnel on its end".   I presume this is a silent clearing 
> (no transmit of StopCCN or CDN)?
True. Probably we should clarify that too explicitly.

> sec 2.3.3, last bullet - Would it not be potentially premature to start 
> establishing new sessions prior to re-synchornization of the session 
> state?  
As Keyur pointed out, the session re-synchronization is not mandatory

(Continue reading)

headers

Paul Howard | 14 Oct 2003 20:56

Re: Questions about draft-ietf-l2tpext-failover-02.txt

Vipin,

Thanx for your comments. See [pwh2] inline.

Thanx,

Paul

Vipin Jain wrote:

Paul, You have some good points and feedback. I am responding to your original email while keeping in mind the discussion you and Keyur have had so far and bringing them to the list. my comments inline..
I've got some questions about the failover draft. sec 2.3 - "Endpoints MUST avoid sending any control packets over the old tunnel that is being recovered". What is the behavior for in-transit control packets? I presume the receiver should silently discard any control packets on the old tunnel (no acknowledgement, no action based on received control packet). I presume such behavior should start once recovery is detected (either by failed endpoint sending new SCCRQ or by failed endpoint's peer receiving new SCCRQ)?
True. Probably we we should clarify that the packets received on receiving end MUST be sliently discarded.
sec 2.3.1, last bullet - "...it SHOULD clear the tunnel and sessions within that tunnel on its end". I presume this is a silent clearing (no transmit of StopCCN or CDN)?
True. Probably we should clarify that too explicitly.
sec 2.3.3, last bullet - Would it not be potentially premature to start establishing new sessions prior to re-synchornization of the session state?
As Keyur pointed out, the session re-synchronization is not mandatory aspect and is provided to bring predictability at an end to know session's state. Therefore we have to allow the tunnel to accept new sesisons upon it getting established. Later in your response, you pointed out that it could result in a problem where session ids are reused while the session states are being synchronized. Well, that is a possibility and was discussed earlier. It was decided to leave it to the implementation. From you comments it does look it should be at least clearly identified and following suggestions could be made for an implementation to handle it: - upon detecting the reuse, both the old and new session MUST be discarded (the new one discarded with CDN other one silently dicarded). This would lead to some sessions not being able to establish temporarily. But then, considering the number of sessions that would be in incosistent states on the two endpoints, in average situations, it may be an acceptable solution. - The session-id allocation is LRU basis would ensure the sessions do not get recycled quick enough. This is true even for tunnels, though it doesn't go along with section The reason we did not go for mandating synchronizing session ahead of calling news sessions being allowed was following: - If session state is synchronized, then all sessions would have to be synchronized to keep both ends on the same page. This process for a scalable setup (about 32k sessions on 8k tunnels or so) might take long enough (in order of tens of seconds) by which it may be too late to respond to new sessions anyways, considering default PPP timeout values. - The idea was to identify the sessions that have idled-out by some means. One ways is to observe the traffic. Besides, the FSQ/FSR message construct allows an implementation to identify if the session is considered alive or is is idle just due to 'traffic not present on that session during a given time'. Assuming PPP Echo request would trigger some packets in a targeted time period.
sec 2.3.4 - "The Session State Inconsistency mechanism SHOULD be carried out only for sessions that are not getting any traffic". It would seem that this would be based on observation of data flow after determining that a failover has started. How would the failed endpoint do this reliably? Consider that data is in-transit from the failed endpoint's peer when the failed endpoint starts tunnel recovery. If this in-transit data is the last data to be sent and the failed endpoint's peer has initiated a disconnect then it would seem possible to have the failed endpoint consider the session established with data flow (and therefore not query it's peer) and for the peer to consider it not established (and thus not query the peer). The result would seem to be a mis-match in the session state even after exchange of the FSQ and FSR.
To answer 'how would an endpoint do this reliably?' I'd say it need not be done that accuracy, because FSQ and FSR would ultimately resolve that and do achieve the same reliably. Say an endpoint suspects a session that might have been removed on the peer because there is no traffic. Then it could ask the peer the same in an FSQ, thereby reliably determining if it needs to consider that session 'hung' or not. FSQ and FSR are facilitated to exchange the state to bring them in sync, not to conclude that they are inconsistent and should be kept that way. I think in the draft we could emphasize that: Upon detecting a session gone away on the peer, an endpoint MUST silently clean up the session on its end. Let me comment here on discussion you and Keyur had, to quickly bring all of us on the same page:
KRP> again, my interpretation here would be that, if not in this period, in the next period - due to inactivity the failed node would sync the session and should clean up. The idea here was (correct if I am wrong Vipin) to avoid permanent "hang" of the session. PWH> But, the draft also mentions the importance of time limiting the acceptability of these messages. It doesn't really seem possible that an endpoint can really wait to determine which sessions are potentially out of sync. If we have one implementation waiting for a period of inactivity on the new TID and the other implementation locking out FSQ after a period, we are going to end up with the FSQ lockout period < inactivity period and thus end up with "hung" sessions. It would seem that a positive handshake of the established sessions would eliminate any issues here with timing. Using dedicated handshake messages (which include the session resync data) instead of SCCRQ, SCCRP, SCCCN would allow accomplishment of this task with a potential reduction in the number of control messages required.
The importance of timing of FSQ and FSR comes from the fact that this mechanism should not be used in any post failover operation. And it should be considered concluded once a peer think its sessions are in sync. However if it is running out of time to conclude such a thing, it SHOULD use FSQ/FSR messages to resolve state of such sessions.
sec 2.3.4 - "Data Plane Behavior" - When should the data flow be transitioned from the old TID to the new TID? Should data flow be interrupted upon start of tunnel recovery until completion of tunnel recovery? What about in-transit data that arrives after the switch to the new TID? Should data on the old TID be accepted until data is received on the new TID?
The trigger to new tunnel is the establishment of new tunnel. Based on the discussions Keyur, myself and other folks had so far, the idea was not to disturb the data path as much as possible. Keeping that in mind, the data on the old tid would be allowed to go through till the new tunnel is established. Upon having established (not just received SCCRQ, for example) the new tunnel the switch over should trigger and the old tunnel would be considered stale from there on.
sec 2.3.4 - "Data Plane Behavior" - "...the non-failed endpoint MUST set the next expected Ns based on the incoming Ns value..." - I presume the next expected Ns is set based on the incoming Ns value of the first data received on the new TID? Why is this only required at the non-failed endpoint?
The data plane getting affected on the failed node is likely. I don't know why you say on non failed node data plane getting affected is a possibility at all?

[pwh2] In the case of a data plane failover, one side (the failed side) has lost it's next Ns and it's next expected Ns. Thus the failed endpoint must reset it's next expected Ns based on the Ns from the next incoming data frame from the non-failed endpoint. On the non-failed endpoint, neither the next Ns or the next expected Ns have been lost. However, the next incoming data frame from the failed endpoint will not have an Ns matching the next expected Ns. Thus the non-failed endpoint must also reset it's next expected Ns based on the incoming Ns. Thus the sentence should really read "....each endpoint MUST set the next expected Ns based on the incoming Ns value..."

Considering the possibility of data plane not being affected by failure on the endpoint - then it need not reset the Ns, it could simply use whatever it was using (thereby allowing peer to choose that number). Where as if data plane was affected then the failed node may choose to reset the Ns value to zero.
sec 3.1 - I presume multiple FSQs are allowed to handle situations with large numbers of sessions on a single tunnel? Similarly with multiple FSRs?
True.
sec a.2 - "target time of 3-5 seconds for 30K tunnels" - Does this really set a realistic expection? It would seem that we're looking at on the order of 210K control packets to recovery 30K tunnels (SCCRQ, SCCRP, SCCCN, FSQ(2), FSR(2)). This works out to 40K to 70K pps of control traffic at a time when one peer is doing failover recovery and is likely to be rather busy with activity over and above L2TP requirements.
sure, that was the design consideration. Not to set the realistic expectations. But it was the trigger point for us to say that we do not want to exchange the state of each and every session right away before we can conclude the recovery process to be complete.
General - What was the reasoning behind creating a new tunnel instead of just doing a resync exchange on the extant tunnel? Depending upon the
structure of the implementation this could potentially be a rather
expensive operation to "move" sessions to the new tunnel resulting in increased forwarding interruption, increased cpu intensiveness, and slower recovery. I guess I don't understand the value in changing the TIDs. KRP> Interesting you bring this up - Vipin and I had a long discussion on this way back. The conclusion was that we need a 3 way handshake to resync after failover - to authenticate each other. Since we already have a tunnel setup handshake, why not augment that? and hence the procedure in this draft. The other question is why assigned a different TID after a failover? and honestly I can't remember why it has to be a different TID - it can very well be the old TID and the implementation supports that - does not recommend that a implementation SHOULD do that when possible - may be Vipin can shed more light on this.

PWH> I think unless there is specific value in using a new TID, then it shouldn't be part of the procedure. I think the expectation of a reader of the draft will be that a new TID gets assigned and thus implementations won't be necessarily expecting re-use of the existing TID. Changing the TID has a potentially signficant peformance hit depending upon how the implementation has structured their forwarding database and how expensive it is to update said forwarding database. It would seem that what we are really trying to do here is reset the control plane (and if necessary the data plane) sequence numbers and detect any sessions that are in an inconsistent state. Changing the TID seems to be an unnecessary complication. If there's real value in changing the TID, then we should do so, but I'd like to understand what this value is.
The new tunnel id was choosen to avoid interference with old control messages. Even though it has side effects of having a hit on data plane, it was considered to give control plane negotiations a mechanism for recovery. However if we change the tid, after having established the new tunnel we would minimize the data plane. Would it be truly hitless, probably not. thanks, -- vipin __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

headers

Vipin Jain | 15 Oct 2003 20:40

Re: Re: Questions about draft-ietf-l2tpext-failover-02.txt

Paul,

I am snipping out plenty of text that you didn't comment
on in this email..

> <pwh> sec 2.3.4 - "Data Plane Behavior" - "...the non-failed endpoint
> MUST set the next expected Ns based on the incoming Ns value..." - I
> presume the next expected Ns is set based on the incoming Ns value of
> the first data received on the new TID?   Why is this only required at
> the non-failed endpoint?    
>   
> <vipin> The data plane getting affected on the failed node is likely.
> I don't know why you say on non failed node data plane getting affected
> is a possibility at all?  
>
> [pwh2] In the case of a data plane failover, one side (the failed side)
> haslost it's next Ns and it's next expected Ns.   Thus the failed endpoint 
> mustreset it's next expected Ns based on the Ns from the next incoming data
> framefrom the non-failed endpoint.   On the non-failed endpoint, neither the 
> nextNs or the next expected Ns have been lost.   However, the next incoming 
> dataframe from the failed endpoint will not have an Ns matching the next 
> expectedNs.   Thus the non-failed endpoint must also reset it's next expected

> Nsbased on the incoming Ns.   Thus the sentence should really 
> read "....eachendpoint MUST set the next expected Ns based on the incoming Ns

> value..."
I see your point; The clause to omit 'failed node' resulted from the assumption
we made that upon detecting failure the non-failed endpoint would also reset
its Ns to 'zero' as if the session was started afresh and so the expected Ns on
the failed node would be 'zero'.
However, to keep smoother transition, it may not be desired particularly when
data plane is not failing over. And as you point out, mandating both ends reset
their 'expected Ns' is safer approach in all situations.

thanks,
-- vipin

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

headers

Vipin Jain | 17 Oct 2003 19:35

Re: Questions about draft-ietf-l2tpext-failover-02.txt

Paul,

My comments on the other set of issues..

> Thanx for your responses.   My primary concern in all of this is to havea
> mechanism that allows for control plane only failover (with hitless 
> dataplane) while also allowing for a full failover (control and data plane) 
> aswell.   I'm not sure how to achieve the hitless data plane with a tunnelid 
> change.   It also seems that for the full failover, we basically haveto 
> change the tunnel id's to establish unique before and after data 
> sequencenumber spaces (or else carry an additional field in every data plane 
> packetto indicate the instance of the sequence number space).
Your point is very valid and the suggestions you make do have merit. My
response/concerns to that is inline..

> The construct provides a mechanism to authenticate (withtunnel password
> mechanism) that most of the implementationsalready have. IMO, the problem is 
> not with using SCCRQ/SCCRP/SCCN,rather using that as a mechanism to switch 
> over to a newtunnel.
> [pwh2] I agree that the problem is switching to a new tunnel.   Since 
> thefirst packet of the handshake arrives with an unexpected Ns doing the 
> normalacknowledgment process would foul things up if it was a spoof.   Thus 
> thefirst packet, at least, probably needs to be special cased in terms of 
> acknowledgement...itreally needs to be acknowledged by the 2nd packet (which 
> is sent only ifthe credentials in the 1st packet are valid).   The existing 
> messages alsocarry AVPs that aren't really necessary to the task of 
> recovering the sequencenumbers.   Having said that, it doesn't really matter 
> what we call these3 packets....I think the key here is that they be sent over

> the already establishedtunnel.
Usually the implementations, at least the ones I have seen, have the protocol
layer riding on top of a reliable layer. The reliable layer does litmus test
for an incoming packet based on the sequence numbers, if it matches then the
expected sequence numbers are updated and packet is delivered to the protocol
layer to parse the packet. Similarly, while sending Ns is updated and packet is
queued for transmission.
Therefore in order to ensure that transport layer notices the sequence number
miss, it should be able to quickly check (instead of going through all AVPs) to
know if it needs to hand over the message to protocol layer.
Fields that we could play around with are Ns and Nr fields. We can't possibly
fiddle around with other fields. However, if we choose known Ns, Nr (i.e. both
zero) then we are making it too predictable to know the sequence numbers during
failover. This is the same concern I had mentioned earlier, to solve that we
agreed to choose sequence numbers that were diametrically opposite.

>  Why not a ResetReq withNs(0), Nr(0) to signal the reset of the control plane
> (and optionally the data plane). This could be receivedon the extant tunnel 
> without, I think, any confusion withother control packets on the tunnel -
> receiver takes ResetReqas a command to flush transmit and receive control 
> queuesfor tunnel and reset sequence numbers.   Comes back withResetReply to 
> confirm.    The ResetReply could be ackedwith the normal ack mechanism.  Now 
> we have a boundarypacket in the control plane in both directions to resetthe 
> control plane sequence numbers.   Could you expand onwhy something along 
> these lines could not be structured toaddress your concerns?    

> Using one 'extant' tunnel to reset control planesfor various old tunnels 
> might void the idea of having differentsecrets for different tunnels. 

> [pwh2]  I don't think this is what I was proposing.   Rather I'm proposingthe

> handshake packets are sent on the existing tunnel's control plane usingthe 
> existing tunnel's ids.
I mentioned my concerns for reusing the existing tunnel to transmit new control
packets above. Given that, I'd be inclined to do something close to what Keyur
and Leo proposed to achieve hitless dataplane failover mechanism:
- Establish a new tunnel (let's call it Failover Tunnel) to reset Ns values
(and optionally the authentication information) on two endpoints for a given
tunnel. Please note that authentication carried for a tunnel is different from
the authentication used for 'Failover tunnel' itself. Once Ns, Nr values are
set, two endpoints can start exchanging the control packets on the old tunnel.
Sessions are recovered as mentioned in the mechanism today.

> Because UDP packets could take different paths (IP routes)to reach the failed

> node, even after reset you can not besure the traffic will not interfere the 
> new tunnel duringthe beginning. I don't think it either is a strong 
> argument,but still a possibility.Resetting Ns=0 and Nr=0 would be opening up 
> security holes.If someone blasts either of the endpoints with StopCCNswith 
> predictable (Nr would be in the initial range) sequencenumbers would result 
> in tunnel termination.
> [pwh2] I agree, but I think this is more a basic problem with StopCCN 
> thanwith the failover mechanism.
There is a little difference: I think in regular case chances of getting the
retransmitted packet with same sequence number is much higher. During failover
we would get a totally different packet acknowledging (or preceived as by the
receiving end) as one of the post failover packet. Only way to avoid is to use
distant Ns values when the old tunnel is revived. I think we agree on this.

>   It's not too hard to send a flood of S
> opCCNsto take down a tunnel even not knowing the sequence numbers.   Yes, a 
> resetto 0 makes it more easier.   Your suggestion below would help with this 
> (andwith the UDP re-ordering problem above).   Posit that each side choses 
> it'snew Ns in the 2nd and 3rd packets of the handshake.   Each side choses 
> anNs that is away from recent prior traffic.   This restores 
> upredictabilityfor the StopCCN scenario and addresses the UDP re-ordering.

> Well, to avoid that we'd have to mandate both endspick their own Ns values 
> and let the other end set their Nrbased on that.thanks,-- 

let me know what you think.

thanks,
-- vipin

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

headers

Internet-Drafts | 21 Oct 2003 22:35

I-D ACTION:draft-townsley-l2tpv3-mpls-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: MPLS over Layer 2 Tunneling Protocol (Version 3)
	Author(s)	: M. Townsley
	Filename	: draft-townsley-l2tpv3-mpls-00.txt
	Pages		: 9
	Date		: 2003-10-20
	
The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a
protocol for tunneling a variety of payload types over IP networks.
This document defines how to carry an MPLS label or label stack and
its payload over L2TPv3. This enables an application which
traditionally requires an MPLS-enabled core network to utilize an
L2TPv3 encapsulation over an IP network instead.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-townsley-l2tpv3-mpls-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-townsley-l2tpv3-mpls-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-townsley-l2tpv3-mpls-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Attachment: message/external-body, 140 bytes

Attachment (draft-townsley-l2tpv3-mpls-00.txt): message/external-body, 69 bytes

headers

W. Mark Townsley | 24 Oct 2003 00:58

L2TP Active Discovery Relay for PPPoE to Informational


To date, draft-dasilva-l2tp-relaysvc-07.txt has been a Standards Track document. 
The document passed WG and IETF last call, and IESG review for Proposed Standard 
with one exception. The exception is that this document contains a normative 
reference to an Informational document (PPPoE).

Thomas Narten and Randy Bush have been addressing this procedural issue within 
the IETF, recently producing draft-ymbk-downref-00.txt for discussion on the 
matter.

I spoke with Thomas the other day. His recommendation is to go ahead and advance 
PPPoE Relay to Informational RFC status now since it has been lingering on his 
plate for so long. Then, after the above mentioned process has been hammered 
out, we can respin the document to Standards Track if necessary and according to 
whatever new methods are defined.

Please let us know if anyone has a problem with this.

Thanks,

- Mark

headers

Internet-Drafts | 27 Oct 2003 23:10

I-D ACTION:draft-dasilva-l2tp-relaysvc-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Layer Two Tunneling Protocol Extensions Working Group of the IETF.

Title : L2TP Active Discovery Relay for PPPoE
Author(s) : M. Townsley, R. da Silva
Filename : draft-dasilva-l2tp-relaysvc-07.txt
Pages : 16
Date : 2003-10-24

The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
Layer Two Tunneling Protocol (L2TP) [2], facilitates the tunneling of
PPP packets across an intervening packet-switched network. And yet a
third protocol, PPP over Ethernet (PPPoE) [3] describes how to build
PPP sessions and to encapsulate PPP packets over Ethernet.
L2TP Active Discovery Relay for PPPoE describes a method to relay
Active Discovery and Service Selection functionality from PPPoE over
the reliable control channel within L2TP. Two new L2TP control
message types and associated PPPoE-specific Attribute Value Pairs
(AVPs) for L2TP are defined. This relay mechanism provides enhanced
integration of a specific feature in the PPPoE tunneling protocol
with L2TP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-dasilva-l2tp-relaysvc-07.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-dasilva-l2tp-relaysvc-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
mailserv <at> ietf.org.
In the body type:
"FILE /internet-drafts/draft-dasilva-l2tp-relaysvc-07.txt".

NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Attachment: message/external-body, 141 bytes

Attachment (draft-dasilva-l2tp-relaysvc-07.txt): message/external-body, 69 bytes

headers

Internet-Drafts | 27 Oct 2003 15:15

I-D ACTION:draft-dasilva-l2tp-relaysvc-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Layer Two Tunneling Protocol Extensions Working Group of the IETF.

Title : L2TP Active Discovery Relay for PPPoE
Author(s) : M. Townsley, R. da Silva
Filename : draft-dasilva-l2tp-relaysvc-07.txt
Pages : 16
Date : 2003-10-24

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-dasilva-l2tp-relaysvc-07.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
mailserv <at> ietf.org.
In the body type:
"FILE /internet-drafts/draft-dasilva-l2tp-relaysvc-07.txt".

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Attachment: message/external-body, 141 bytes

Attachment (draft-dasilva-l2tp-relaysvc-07.txt): message/external-body, 69 bytes

headers

Vipin Jain | 31 Oct 2003 21:25

Re: Questions about draft-ietf-l2tpext-failover-02.txt

Paul,

my comments inline..

> My comments inline [pwh3]

> Usually the implementations, at least the ones I have seen, have the 
> protocollayer riding on top of a reliable layer. The reliable layer does 
> litmus testfor an incoming packet based on the sequence numbers, if it 
> matches then theexpected sequence numbers are updated and packet is delivered

> to the protocollayer to parse the packet. Similarly, while sending Ns is 
> updated and packet isqueued for transmission.Therefore in order to ensure 
> that transport layer notices the sequence numbermiss, it should be able to 
> quickly check (instead of going through all AVPs) toknow if it needs to hand
> over the message to protocol layer.Fields that we could play around with are 
> Ns and Nr fields. We can't possiblyfiddle around with other fields. However, 
> if we choose known Ns, Nr (i.e. bothzero) then we are making it too 
> predictable to know the sequence numbers duringfailover. This is the same 
> concern I had mentioned earlier, to solve that weagreed to choose sequence 
> numbers that were diametrically opposite.
> [pwh3] I agree with the issues about separation of the reliable layer andthe 
> protocol layer.   You mention we can only play with Ns and Nr.   Whynot take 
> one of the reserved bits in the header to signal a UI frame (Ns= 0, Nr = 
> 0)?   The reliable layer would handle all UI frames - thus avoidingthe issue 
> of to pass up to the protocol layer or not.   The handshaking todo the 
> failover could thus be done with a sequence of UI frames.   The 
> authenticatedhandshaking with UI frames would include the new sequence 
> numbers to be usedthus avoiding predictability of the new Ns
Reserved Bits: I am in for that. Based on the discussions earlier Mark and
we agreed that if we can get it done by using a control plane message exchange
there is no need to make a L2TP-header change for this.
Using Ns=0, Nr=0 Scheme: This is flawed because it might naturally coincide
with the sequence numbers of a tunnel thereby confusing this as an
acknowledgement for a packet sent earlier.

> I mentioned my concerns for reusing the existing tunnel to transmit new 
> controlpackets above. Given that, I'd be inclined to do something close to 
> what Keyurand Leo proposed to achieve hitless dataplane failover mechanism:- 
> Establish a new tunnel (let's call it Failover Tunnel) to reset Ns values(and

> optionally the authentication information) on two endpoints for a 
> giventunnel. Please note that authentication carried for a tunnel is 
> different fromthe authentication used for 'Failover tunnel' itself. Once Ns, 
> Nr values areset, two endpoints can start exchanging the control packets on 
> the old tunnel.Sessions are recovered as mentioned in the mechanism today.
> [pwh3] What would be the packet exchange here?   I presume we would havethe 3

> way handshake to establish the failover tunnel and then packets todo the 
> reset?   Or would they be carried on the 3 way handshake.
packet exchange:
- establish a new tunnel (called 'Failover Tunnel')
- exchange the new sequence numbers of the old tunnels for control plane
- Both ends would reset their sequence numbers based on the values exchanged on
'Failover Tunnel'.
- The 'Failover Tunnel' is torn down after al tunenls are considered recovered
(i.e. when they have been exchanged and agreed upon by both peers. Remaining
tunnels are torn down assuming they do not need recovery by at least one of the
endpoints.

> One negativeto this approach is that it would require the systems to have the

> resourcesavailable to at least temporarily manage the additional tunnels - 
> this mightimply being able to temporarily peak at double the normally 
> supported numberof tunnels.   If the non-failed endpoint was at it's maximum 
> number of tunnels,how would it know to make an exception for the failover 
> tunnel setup?
And therefore we would RECOMMEND keeping space for at least tunnel for recovery
purposes. If it can't establish the tunnel, then it could retry 'x' times
before concluding the tunnel recovery mechanism failed. This is much better
than current proposal where we'd establish one new tunnel for every old tunnel.

> Howdoes the transition to the new sequence number occur? 
> I  presume we handoff the new sequence numbers to the reliable layer and
> it then purges it'sre-ordering rx queue, renumbers any outstanding,
> transmits and immediatelyre-transmits them?  Any stale receives get 
> automatically discarded as outof window.
- Renumbering outstanding transmits might create more unpredictability for no
benefit. Because control plane on the failed node would have lost the context
related to previous messages, it is better to flush everything off and start
with new sequence numbers.
The old tunnel becomes active only upon getting confirmation from its peer that
it has reset control plane sequence numbers. So this would have to be a three
way handshake as described below. For example, for an old tunnel:
- Failed node sends: "Reset Nr to 5665 for Old Local Tid = 9, Old Tid = 6".
- Non Failed node responds: "Nr for Old Tid = 9 reset to 5665, Reset Nr to 4435
for the same tunnel (i.e. Old Local Tid = 6, Old Tid = 9 from this node's
perspective)". Failed endpoint upon getting this message must first enqueue the
response of this message and then start sending control messages on the Old
tunnel.
- Failed node sends: "Nr for Old Tid = 9 reset to 4435". Non failed node upon
getting this can start sending control messages.

>  It's not too hard to send a flood of SopCCNsto take down a tunnel even not 
> knowing the sequence numbers.   Yes, a resetto 0 makes it more easier.   Your

> suggestion below would help with this (andwith the UDP re-ordering problem 
> above).   Posit that each side choses it'snew Ns in the 2nd and 3rd packets 
> of the handshake.   Each side choses anNs that is away from recent prior 
> traffic.   This restores upredictabilityfor the StopCCN scenario and 
> addresses the UDP re-ordering.    

> [pwh3] We might want the non-failed endpoint to provide a hint in the 
> 2ndpacket of the exchange to help the failed endpoint pick an Ns that is 
> farenough away.   Might be useful if the failed endpoint's mirroring of 
> it'sNs is relatively infrequent and there had been a lot of control traffic 
> onthe tunnel.
Sure, picking our own Ns and scheme described above would take care of this
security hole.  

thanks,
-- vipin

__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

7	December 2011
1	November 2011
1	October 2011
1	September 2011
2	August 2011
5	April 2011
1	March 2011
1	September 2010
5	July 2010
25	June 2010
1	September 2009
15	August 2009
5	July 2009
5	June 2009
1	May 2009
5	April 2009
7	March 2009
1	February 2009
1	December 2008
4	November 2008
2	October 2008
3	September 2008
10	August 2008
1	July 2008
1	June 2008
3	March 2008
1	February 2008
1	January 2008
1	December 2007
3	November 2007
1	October 2007
5	August 2007
6	July 2007
11	June 2007
1	May 2007
5	March 2007
3	February 2007
2	January 2007
7	December 2006
5	November 2006
5	October 2006
25	September 2006
8	August 2006
4	July 2006
9	June 2006
5	May 2006
4	April 2006
4	March 2006
6	February 2006
6	January 2006
12	December 2005
5	November 2005
10	October 2005
27	September 2005
10	August 2005
12	July 2005
13	June 2005
20	May 2005
9	April 2005
3	March 2005
2	February 2005
1	January 2005
5	December 2004
14	November 2004
9	October 2004
28	September 2004
6	August 2004
5	July 2004
7	June 2004
1	May 2004
1	April 2004
4	March 2004
1	February 2004
11	January 2004
5	December 2003
7	November 2003
11	October 2003
11	September 2003
5	August 2003
11	July 2003
9	June 2003
9	May 2003
10	April 2003
7	March 2003
7	February 2003
9	January 2003
6	December 2002
56	November 2002
5	October 2002
4	September 2002
27	August 2002
33	July 2002
16	June 2002
33	May 2002
17	April 2002
1	February 2001

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31