RE: draft-galtzur-l2tpext-gr-01.txt and draft-ietf-l2tpext-failov er-02.txt
Sasha Vainshtein <Sasha <at> AXERRA.com>
2004-01-27 15:49:55 GMT
Mark, Sharon, Paul and all,
Just one brief remark on the subject.
When it comes to L2TPv3- and RADIUS-based VPLS, I'd say that
a graceful restart mechanism that passes through exactly the same
authentication stages as "normal" restart" is preferable since
it leaves less possibilities for security breaches. At the same
time, the number of sessions to be recovered in case of VPLS
(which is equal to the number of VPLS instances present in
the failed PE) should not be expected anywhere in the
100,000 range mentioned by Paul.
Did I miss something?
With best regards,
Sasha Vainshtein
email: sasha <at> axerra.com <mailto:sasha <at> axerra.com>
tel: +972-3-7659993 (office)
+972-8-9254948 (res.)
+972-58-674833 (cell.)
> -----Original Message-----
> From: Sharon Galtzur
> Sent: Tuesday, January 27, 2004 5:18 PM
> To: 'W. Mark Townsley'; 'Paul W. Howard'; l2tpext <at> ietf.org
> Cc: Sasha Vainshtein; Gonen Zilber
> Subject: RE: draft-galtzur-l2tpext-gr-01.txt and
> draft-ietf-l2tpext-failover-02.txt
>
>
> Hello mark and all,
> Thank you for the summery.
>
> Our draft was indeed written primary for the L2tpV3 and
> disregarded the L2tpV2.
> As you mentioned the main difference between V2 and V3 is
> that the CC Id is part of the Session ID.
> This means that for V2 the CC Id need to be remembered (or
> recovered from the data plane).
> I think that a rather small modification might make our draft
> V2 compatible (i.e. enforce recovering of the CC Id).
> (See my reply to Paul W. Howard on the L2TP mailing list
> regarding CC Id).
>
> Regarding the "dynamic" vs. "static" - I don't quite
> understand what you refer to.
> If you refer to draft-ietf-l2vpn-l2tp-radius-vpls-00.txt, I
> don't understand why one approach is better
> then the other (other then the reconnection speed issues
> which is a valid concern for both normal and graceful restart).
> If you refer to something else, could you explain what did you mean ?
>
> Sharon Galtzur
>
> > -----Original Message-----
> > From: W. Mark Townsley [mailto:townsley <at> cisco.com]
> > Sent: Monday, January 26, 2004 10:27 PM
> > To: Sharon Galtzur; 'Paul W. Howard'; l2tpext <at> ietf.org
> > Subject: draft-galtzur-l2tpext-gr-01.txt and
> > draft-ietf-l2tpext-failover-02.txt
> >
> >
> >
> > I would like to try and offer a level set here for continuing
> > the discussion.
> >
> > I see that these two drafts are trying to solve similar
> > problems, though perhaps
> > optimized differently. Fundamentally, both intend to address
> > the restablishment
> > of control connection and session state for L2TP during a
> > failure scenario. That
> > may mean failover from an active to standby RP, or the
> > restart of an RP while
> > continuing to forward packets.
> >
> > For the most part, either mechanism could be made to work for
> > L2TPv3 or L2TPv2.
> > I think there are obvious benefits if we can have a single
> > mechanism for both.
> >
> > The only fundamental difference I see between the two
> > protocols themselves which
> > might affect the design of the associated restart method is
> > that in L2TPv3 the
> > Control Connection ID is *not* carried in the L2TP Data
> > Message Header, and in
> > L2TPv2 the analogous Tunnel ID *is* carried in the L2TP Data
> > Message Header.
> > Thus, v3 has the advantage over v2 in that it can restart
> > with a different
> > Control Connection ID without affecting the forwarding plane.
> > This difference is
> > tangible, but would hopefully not prohibit convergence on a
> > common mechanism.
> >
> > I believe the more fundamental reason we see two divergent
> > solutions is that
> > each is being targeted to different deployment environments.
> >
> > draft-galtzur-l2tpext-gr-01.txt is targeted at the current
> > L2TPv3 space, while
> > draft-ietf-l2tpext-failover-02.txt is targeted at the more
> > mature RFC2661 L2TPv2
> > space. As such,
> >
> > draft-galtzur-l2tpext-gr-01.txt is optimized for an
> > environment which is:
> >
> > - Provisioned in a relatively static manner
> > - Has a fairly small number of sessions per LCCE
> > - Largely addresses restart of a single RP while continuing
> > to forward traffic
> > on a separate dataplane
> >
> > draft-ietf-l2tpext-failover-02.txt is optimized for an
> > environment which is:
> >
> > - Provisioned in a largely dynamic manner
> > - Has a large number of sessions per LCCE
> > - Addresses restart of an RP, or failover to a secondary RP
> > or node, where some
> > amount of session and control connection state may be
> > checkpointed (e.g., beyond
> > that necessary for forwarding alone), and where traffic flow
> > may be interrupted
> > during failover.
> >
> > One might argue that, over time, the deployment environment
> > of L2TPv3 will look
> > more and more like that of L2TPv2. e.g., higher density,
> more dynamic
> > provisioning via auto-discovery or NMS systems, etc. Thus,
> > some of the scaling
> > benefits of draft-ietf-l2tpext-failover-02.txt could become
> > more relevant as well.
> >
> > That said, I don't believe the
> > draft-ietf-l2tpext-failover-02.txt has all the
> > kinks worked out in it. draft-galtzur-l2tpext-gr-01.txt has
> > the advantage of
> > being quite simple, is relatively complete, and requires very
> > little (if any)
> > state checkpointing beyond that which could be gleaned from
> > the still-active
> > forwarding plane which is assumed to be present. It's
> > perfectly adequate for
> > cases where you aren't concerned about how fast the sessions
> > recover (and if you
> > have a forwarding plane that is still passing packets for
> > fairly static
> > sessions, why should you care?).
> >
> > Authors, please let me know if I have not articulated the
> > situation accurately.
> >
> > Next step is to try and come up with a single method (or very
> > close to a single
> > method) that operates with both versions of L2TP.
> >
> > Thanks,
> >
> > - Mark
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
RSS Feed