Re: [L2tpext] Comments on draft-ietf-l2tpext-tunnel-switching-03.txt

Thanks for the comments Mark. My response inline..
I snipped out plenty of text that you didn't comment on.

>
>      The figure above presents a typical tunnel switching scenario for
>      incoming calls. The user opens a layer2 (for example PPP) session
>
> WMT Are we going to mayke this RFC2661-specific or not? If so, I think we can
> go
> ahead and call this a "PPP" session vs. a "layer2" session. If we are going
> to
> make it L2TPv3 based, we probably need more nomenclature changes than just
> this.
> What we have here seems sort of in-between.
Yes, we'd like it to be generic because we think there is applicability
beyond PPP; Agree that it needs more nomenclature change (borrow most
of them from L2TPv3). It would allow tunnel switching to work with
L2TPv2 as well.

>      Tunnel switching enables higher administrative control on how layer2
>      sessions are engineered in L2TP deployments.
>
> WMT "higher administrative control," "layer2 sessions are engineered" - this
> is
> a little broad and encompassing. I think we should come down to earth a bit
> here.
sure, how about:
"Tunnel switching enables redirection of layer2 sessions based on
administrative policies as described below". 'below' would cover
the same text.

>      - Layer2 sessions wholesaling: L2TP tunnel switching allows using a
>      common L2TP control connection on the LAC for sessions that are
>      eventually destined to different LNSs (ISPs).  This enables the
>      wholesaler to bundle layer2 sessions belonging different ISPs on
>      to a single tunnel.
>
> WMT I am sometimes reading "control connection" and sometimes reading
> "tunnel"
> for what I think are the same things. I understand that in RFC2661 this can
> be
> ambiguous, but please try to be consistent in your new doc. At least in the
> same
> paragraph ;-)
agree; will take care of this. I think adopting 'tunnel' would be
appropriate term as reflected by the title "Tunnel Switching".

>
>      It would be administratively easier to manage
>      this flat configuration.
>
> WMT But if you go through a tunnel switch, it's not a flat configuration, its
>
> tiered. Some things may become easier to manage when you aggregate traffic at
>
> the TSA, but other things become more difficult. For example, debugging a
> single
> session problem may very well become more difficult as you have to trace a
> user
> with a problem through each TSA, rather than knowing immediately which LAC
> the
> user is connected to at the LNS.
May be our perspectives are different and I should't be using 'flat'.
Instead following explains it a bit more: 'It would be administratively
easier to manage the fixed set of LNSs for every new LAC that a
wholesaler adds to its network'

On things becoming difficult regarding tracing: I would agree to some
extent that it introduces another session mapping table on TSA. Debugging
session establishment is aided because 'Call Serial Number AVP' is
recommended to be RELAYED.

>      REGENERATED AVPs are the AVPs that are dropped on an inbound tunnel
>      and are regenerated as defined by [L2TP] for an outbound tunnel as
>      if there was no tunnel switching, possibly resulting in the same
>      value.
>
> WMT I wonder if we need a special set of AVPs that may be "stacked" as is
> done
> in the sessinfo for nas-port and hostname tracing. Note that I am not
> suggesting
> that we try and allow stacking of existing AVPs, just defining the mechanism
> for
> other drafts, such as sessinfo, to utilize.
Do you mean an encapsulation scheme that is agnostic to AVP contents?
Sounds good, but then sooner it is done better it is, because then
it could be used widely.

>         Physical Channel ID (ICRQ, OCRP) - MAY be RELAYED, REGENERATED,
>         or DROPPED.
>
> WMT What is the difference between MAY RELAY and MAY REGENERATE? Since
> "REGENERATION" includes the ability to use the same value received, RELAY
> seems
> to just be a subset of REGENERATION.
We wanted to emphasize the fact that the value could be left untouched.
IMHO, REGENERATION is an explicit mention that the value of an
AVP could change.  Where as RELAY implies that the value is
untouched. However, as you pointed out, even when an AVP is
REGENERATED it could finally assume the same value that came in.
The different meanings of two would allow better level of
clarifications on what could be tweaked vs what not.  I think
describing (situations/values/hints) each AVP that could be
REGENERATED would clarify a bit more.

> WMT Nice first shot at the list here, not an easy process. I see a lot of
> MAYs
> and SHOULDs right now. Perhaps we should enforce a base mode of operation,
> applying a "MUST" category to all AVPs that we possibly can. Then, in a
> separate
> section, AVPs with SHOULDs or MAYs that we are indecisive on. In general, the
>
> more MUSTs (and not "MUST NOT"s) we have, the better. Having them grouped
> would
> make it a little easier, at least for me, to try and grasp.
As you pointed out we used MUST/MUST-NOT very modestly. But then
we thought this would be a first shot and we'd get more feedback
and improve as we move further.

>         Initial Received LCP CONFREQ (ICCN) - MUST NOT be REGENERATED and
>         can only be RELAYED or DROPPED.  Proxy LCP AVPs (Initial Received
>         LCP CONFREQ, Last Sent LCP CONFREQ and Last Received LCP CONFREQ)
>         MUST be either all DROPPED or all RELAYED.
>
>         Last Sent LCP CONFREQ (ICCN) - MUST NOT be REGENERATED.
>
> WMT If you don't REGENERATE it, what do you do to it? RELAY? DROP? In
> general, I
> think it would be more clear to say what to _do_ vs. what not to do whenever
> possible.
Agree; To maintain the consistency it would be better to use _to do_
items very clearly and mention _not to do_ if necessary.

>         Last Received LCP CONFREQ (ICCN) - MUST NOT be REGENERATED.
>
> WMT Whenever we say "regenerate" we will have to be clear about what it is
> regenerated with. For example, I think this assumes that PPP is run again at
> each TSA, which may not be the case. PPP might operate over the tunnel
> switches
> end to end (if you base your new tunnel off information, say, in the ICRQ,
> control connection the ICRQ arrives on, etc. vs. PPP negotiation). We might
> have
> to identify this as two modes of operation, and account in the standard for
> each.
Agree; I will add more sections to clarify REGENERATION whereever applicable.
In the example that you took above: If an AVP is REGENERATED then it would
mean the PPP was renegotiated. Where as RELAYED conveys the idea that it
was passed along. That was the reason we wanted to keep REGENERATE seperate
verb from RELAY and one not being as superset/subset of another.

>         Proxy Authen Type (ICCN) - MUST NOT Be regenerated and can only be
>         RELAYED or DROPPED.
>
> WMT Why not REGENERATED? What if, at my first TSA, I allow PPP without any
> auth
> (say, so that the user is not prompted for a password) and then renegotiate
> LCP
> with CHAP at the next hop where the real policy enforcement is?
I think I missed that. And that's true for all Proxy LCP AVPs too; They
could be REGENERATED as well. But either all REGENERATED or all RELAYED.

> WMT I am thinking that in order to get into what MUST be done for some of
> these
> AVPs, we need to define very clearly the assumed mode of operation with
> regard
> to PPP negotiation, what information is used to setup a new session and when,
>
> etc. Not necessarily easy stuff to pin down, I know.
Let me give it a shot in next version and invite comments on the same.

>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         | SPN Length    | Service Profile Name ... (arbitrary length)   |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |                     Maximum  Capacity                         |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |                     Current Capacity                          |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> WMT If your Max and Current Capacity values are fixed, there is no need for
> an
> SPN length in this AVP. Further, I wonder why you wouldn't use separate AVPs
> here?
you mean length could be derived from the AVP length itself? Probably true..

>         The Current Capacity indicates the current capacity of the TSA.
>         Like Maximum Capacity AVP its value is also opaque to the TSA's
>         peer. The value of this AVP indicates the relatively (relative to
>         Maximum Capacity) how many more sessions the TSA could handle.
>
> WMT This sounds like something that could be moderately useful to any LAC,
> LNS
> or TSA. Why can't we just put this in its own "Load Balancing" or "Service
> Profile Capacity" draft?
Not a bad idea. It certainly would be helpful in some other situations too.
I can put in a miniature draft for comments.

>      4.2  TSA ID AVP (ICRQ, OCRQ)
>
> WMT This is broken through a NAT, with L2TP over ATM, L2TP over FR, and
> assumes
> that Hostname is unique for a given management domain of IP addresses. The
> latter may be untrue in cases where, for example, a number of LACs need to
> connect to a given LNS using a common Hostname AVP to obtain a common policy
> profile on that LNS. If any of those LACs are behind NATs, this doesn't work.
True; I guess using an IP address would make it applicable only over an IP
network (not FR and ATM) as well as it will break the operation over
NAT as you pointed out. It might also introduce some security issues.

I think the better solution would be allow configuration of a unique (within
an L2TP network) TSA ID Value that could be used as a unique identifier
for this purpose. In absence of a configuration HostName (which is broadly
unique) could serve the purpose.

>
>         The TSA ID AVP, Attribute Type TBD, could be used to detect if a
>         session is looping in an L2TP tunnel switched network. This AVP
>         would occur as many times as the number of TSAs in the network. It
>         is inserted by TSA while generating an ICRQ or OCRQ when it
>         switches a session. All incoming TSA ID AVPs MUST be copied
>         unaltered to the REGENERATED ICRQ or OCRQ.
>
>         The TSA SHOULD check to see if its own Hostname and IP Addresses
>         is present in one of the TSA ID AVP.
>
> WMT If the hostname and IP address in the TSA is checked only against "its
> own"
> Hostname and IP address as stated above, then loop detection only works if
> the
> loop traverses the starting point. Given that we are assuming one's topology
> may
> be so convoluted and broken that a loop is possible, then we would have to
> assume that the loop may actually start *after* the initial LAC. In fact,
> that
> is probably the case, considering the initial LAC would _probably_ not be
> configured as a TSA as well.
Every node in the path introduces one such TSA ID AVP; Hence comparing
all AVPs with its own would allow detecting if the session is passing through
the same node again.
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         | HN Length     |          HostName ... (arbitrary length)      |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |                        IP address                             |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> WMT Why do you need an HN Length? You know the length of the AVP, and last I
> checked IPv4 addresses were always 4 bytes ;-) As with the above new AVP, it
> would really make more sense in my code for these to be separate AVPs. Most
> other code I have seen it would be as well. Further, this way you could
> extend
> this to IPv6, FR, ATM, etc. without having to affect the Hostname value. In
> fact, you don't even need to copy the Hostname if you state that the existing
As I mentioned above, removing IP address would eliminate the confusion as
well as solve the problem.

> 7. Security Considerations
>
>      L2TP tunnel switching inherits all security issues from [L2TP] and
>      does not introduce any new security issues.
>
> WMT Sure it does. What about carrying the IP address and Hostname of the
> originating LAC around through multiple Hops and administrative domains? What
>
> about the ability to obtain "Maximum Capacity" profiles and using this to
> optimize DoS attacks? I know, "use IPsec," but in the absence of IPsec, these
>
> are additional security issues.
Agree.

>      [L2TP] recommends slow start and congestion avoidance techniques be
>      used on the control connection. That alone may not be sufficient to
>      deal with congestion problems in tunnel switched deployments.
>      Primarily because a TSA terminates the control connection and
>      initiates another one. For example, while switching incoming calls,
>      outbound tunnel might be more congested than inbound tunnel, in which
>      case even if two tunnels are implementing slow start and congestion
>      avoidance procedures, the effectiveness of end to end (first LAC to
>      last LNS in tunnel switched network) congestion control might not be
>      achieved.
>
> WMT The point of the congesting control, really, was to ensure that the
> intervening network is not overly utilized (like TCP). Yes, it also provides
> some congestion control of the peer for processing messages, which is
> probably
> the more useful effect in practice.
IMO TSA is nothing but a network component in tunnel switching environment.

>      In order to deal with the situation it is recommended that
>      a TSA utilize the congestion information from the outbound tunnel to
>      provide feedback information in following manner:
>
>      - It could stop accepting new ICRQs with the issue of the
>        appropriate cause code in ICCNs
>
> WMT Don't you mean in a CDN?
yes thanks.

> WMT Another way is to ZLB ack (or piggyback ack) and ICRQ, and wait before
> sending the ICRP. A drastic measure if life is really bad, is to simply drop
> incoming messages so that the peer backs off exponentially.
Dropping incoming message does sound drastic, an implementation should
have taken necessary steps to ensure that it doesn't happen
by implementing two of points mentioned above and another one
you pointed out.

>
>      - It could utilize a Tunnel Capacity AVP to indicate that TSA might
>        not have capacity to handle more sessions on the given incoming
>        tunnel.
>
>      This will ensure the TSA to be as transparent as possible to the
>      congestion in the network and provide end to end congestion control.
>
> WMT Well, I wouldn't call it end to end congestion control in the strict
> sense
> of the word. But, yes, these mechanisms could help bring the sessions up
> without
> thrashing. I think that we may need to be a little more specific here though.
I can put in some examples that would adequately justify the puspose.

thanks,
-- vipin

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
_______________________________________________
L2tpext mailing list
L2tpext@ietf.org
https://www1.ietf.org/mailman/listinfo/l2tpext