RE: [PWE3] ATM Forum liaison

[Claude Kawa]

Title: RE: [PWE3] ATM Forum liaison





A number of people who are on the PWE3 list (I am not one of them) attended the last ITU-T SG 13 meeting held in February. They can provide their input.

To my knowledge nobody was mandated and no liaison statement was approved for communication to the IETF and PWE3 WG about the outcome of ATM/MPLS meeting results. 

claude


-Original Message-
From: Lloyd Wood [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 11, 2002 3:11 PM
To: Chip Sharp
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [PWE3] ATM Forum liaison



On Mon, 11 Mar 2002, Chip Sharp wrote:


> Date: Mon, 11 Mar 2002 14:21:21 -0500
> From: Chip Sharp <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PWE3] ATM Forum liaison
>
> At 11:39 AM 3/11/2002, [EMAIL PROTECTED] wrote:
>
> >Since the IETF has no official liaison process, I want to make sure that
> >PWE3 members are aware of the most recent communication from the ATM Forum.
> > Below is a liaison that was sent to your Chairs and Area Directors.
> >
> >The ATM Forum has added an optional sequence number and length field to our
> >frame format, effectively aligning it with the Fischer draft being
> >considered within PWE3. I would urge members who value a single industry
> >standard to promote Fischer as the most practical way to achieve this.  I
> >also understand that a frame format compatible with Fischer (but not
> >Brayley) is in the current draft document being considered by ITU.
>
> Actually there are two frame formats with *equal status* (Under
> Investigation) under consideration by ITU Study Group 13 Question 5.
> I believe one is compatible with Fischer (contained in what is
> called a draft document) and one is compatible with Brayley (in the
> living list).
>
> Therefore, it looks like the ATM Forum may be the only standards
> group not considering both frame formats.


It's all in the delicate phrasing, isn't it? nicely worded, Jim.
thanks, Chip.


In the light of recent discussion of ITU-T and misrepresentation,
unintentional or otherwise, of the work of standards bodies (the
recent 'Re: Last Call: IETF and ITU-T Collaboration Guidelines to
Informational' thread on [EMAIL PROTECTED]) I have to ask:


is anyone here an official ITU-T representative for ITU SG-13 who can
provide an accurate precis endorsed by the ITU?



On 5 March, Scott Bradner said in that thread:


$ the reason behind this at all is that we have had cases of people
$ representing to IETF WGs that they know what is going on in an ITU-T
$ SG but it turned out that in some cases they did not know and thus
$ mislead the listeners about what was going on in the ITU-T - this
$ was meant as a way for the ITU-T management to say, in effect "he
$ knows what is going on" - this was not intended to mean that any
$ such designated person carries any more weight in IETF WG
$ deliberations than does any other individual  - but as Pete points
$ out, it can be useful to actually know what another group is or is not doing.


...as input to decisions based on pure technical merit?


In the interim, I would urge you to ignore Jim's urgings.


L.


is not in the ATM Forum, having read through the directory that includes
http://www.atmforum.com/pages/advantages/self_declaration.html



> Chip
>
> >Jim Harford
> >ATM Forum AIC Chair
> >
> >>  -Original Message-
> >> From:   Townsend, Richard L, JR (Rick)
> >> Sent:   Tuesday, February 12, 2002 4:49 PM
> >> To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]';
> >> '[EMAIL PROTECTED]'
> >> Subject: Liaison to IETF PWE# from the ATM Forum
> >>
> >> Liaison to IETF
> >>
> >> To: Danny McPherson, Co-chair of PWE3 WG    [EMAIL PROTECTED]
> >>    Luca Martini, Co-chair of PWE3 WG  [EMAIL PROTECTED]
> >>    Scott Bradner, Area Director  [EMAIL PROTECTED]
> >>    Allison Mankin, Area Director [EMAIL PROTECTED]
> >>
> >> For:  IETF PWE3 WG
> >> Subject:  ATM-MPLS Interworking
> >>
> >> The ATM Forum has recently started work on version 2 of our ATM-MPLS-ATM
> >> Network Interworking specification.  Please note that the initial version
> >> of this specification, af-aic-0178.000, is publicly available at the ATM
> >> Forum's web site at .
> >>
> >> In version 2, we have added a length and sequence number field to our
> >> frame format, effectively aligning our frame format with
> >> draft-fischer-pwe3-atm-service-02 that you are considering within PWE3.
> >>
> >> Any comments you have will be welcome.
> >>
> >> The next meeting of the ATM Forum is April 21-26 in Prague, Czech
> >> Republic.
> >>
> >>    Rick Townsend
> >>    Chair of the Technical Committee, ATM Forum
> >>    [EMAIL PROTECTED]
> ___
> pwe3 mailing list
> [EMAIL PROTECTED]
> https://www1.ietf.org/mailman/listinfo/pwe3


<[EMAIL PROTECTED]>PGP



__

Re: PPP

[W. Mark Townsley]

Brian Lloyd wrote:
> 
> At 11:59 PM 3/6/2002, you wrote:
> > >  It has been many years since I argued this with Karl Fox back when
> > > he chaired the L2TP WG.
> >
> >Karl chaired only the pppext WG.
> 
> Then at the time L2TP or the precursor discussions were done within the
> PPPEXT WG because the discussion was with Karl.
> 
> > > At that time he agreed but also said that there
> > > was too much water under the bridge to fix L2TP at that time so it was
> > > going to go forward in its subtlely-broken form.  I haven't looked at it
> > > since then.  I don't even remember the lexicon so I will undoubtedly sound
> > > uninformed.
> > >
> > > The LCP negotiation should take place with the L2TP equivalent of the
> > > NAS.  That is independent of anything else that happens and nothing
> > > associated with that needs to be communicated to the edge device at the
> > > target network.  The authentication phase then takes place so you can do
> > > authorization and configuration.
> >
> >That would have been nice, but, the requirements were that it be possible for
> >user authorization be completed at the LNS (the edge device at the target
> >network), and at the LAC (NAS).
> 
> Thank you for reminding me.  LNS and LAC were the terms I was looking for.
> 
> WRT authentication, there is no reason not to do it in both places.  Let
> the protocol carry the information.
> 
> >In addition, we could not require the user to
> >enter a username and password twice. You simply had to be able to drop in
> >L2TP, and everything look the same as it did before to the end user.
> 
> I agree that is the more desirable scenario.
> 
> > > Once that is complete you can do the
> > > MLPPP and NCP negotiation(s) because then and only then do you know what
> > > the end system is authorized to do.
> >
> >Yup, that would have been nicer.
> 
> Yes, it would.
> 
> > > "But MLPPP is negotiated during LCP," you say!  Right.  That is broken and
> > > I helped make it broken and, in retrospect, I am *really* sorry I did.
> >
> >That's OK, we'll forgive you ;-)
> 
> Thank you.  It may seem silly but that has really bugged me for a number of
> years.  I hate the thought of having done flawed work.
> 
> >Barring redesign of PPP, getting around the wrong things being located in
> >the LCP negotiation would have been made a little easier if we had been
> >allowed to go through LCP negotiation twice. So, you could have LCP
> >negotiated at the LAC,
> 
> But you wouldn't have needed to do LCP negotiation twice.  The LAC
> negotiates LCP because that is the terminus of the link. 

Not just that, the LAC may also need to get authentication information from the
user so that it can know which LNS to forward to. 

> The LAC
> communicates the options negotiated back to the LNS.  

That's what we do now. Please read section 4.4.5 of RFC2661.

> Remember, the LCP
> options negotiate only indicate what the client is willing to accept
> therefore it doesn't really matter what it negotiates.  It is just there to
> prevent its peer from sending something it can't handle.

But, if the LNS, say, want's to do some different authentication... Say, PAP
with an OTP but the LAC negotiated CHAP, then, well... We have to start over PPP
LCP, which should be OK except that it used to break a lot of PPP clients.

> 
> >forward any necessary link parameters to the LNS so that it could set them
> >correctly during "LCP round 2", and then renegotiate LCP at the LNS to get
> >things like MLPPP and perhaps authentication type which should have been
> >designed into the negotiation process later.
> 
> Right.  That is the crux of the problem.
> 
> >But -- and here is the point about broken PPP stacks -- at the time there
> >were a lot of PPP stacks which would simply roll over and die if you tried
> >to reneogtiate LCP after you had already begun (yes, in great violation to
> >what it says in RFC 1661). This wasn't discovered until L2TP came along
> >because before that, you really didn't see LCP renegotiation occur very much.
> 
>  But we did know.  The argument was that it took too long to
> negotiate PPP as it was so anything we did to speed it up was necessary.  I
> have kicked myself for caving in to that argument for many years now.

Then let me give you a collective kick from all of the l2tp developers out there
;-)

I thought it was just a bug. I remember telling Robert Webster about this little
problem at a pacbell bakeoff many years ago. His jaw dropped, and he went back
and made an on-the-fly bugfix for it and afterwards it worked great. Note that
Robert worked at Shiva then, and maintained code for the PPP stack that for a
while was the original code base for much of the dialup client industry (e.g.
Windows, OS/2, and probably some others...).

> 
> >But, it was way too late as there were so many clients in the field with
> >this bug. So, we ended up with Proxy LCP and Proxy Authentication like you
> >see them today.
> 
> I know: add more ugliness in order to