Subject: LCP Negotiation

From: Sumati Mittal <[email-masked]>
Date: Thu, 10 Aug 2000 11:46:00 -0400

Hi,

I have a question regarding LCP negotiation. These are the two
scenarios:

1. LAC does Proxy LCP with the remote system. LNS re-negotiates the
non-ACCM LCP parameters.
2. Only LNS negotiates LCP with the remote system.

Is there a way for LAC to know the negotiated LCP parameters except by
silent observation ?

I have tried to search for draft-ietf-l2tpext-link-00.txt hoping to find
answers there but cannot trace the draft.

Thanks in advance,
Sumati.

Sumati Mittal
GlobeSpan, Inc. 
Voice : (732) 345-6240
mailto:[email-masked]
Web: http://www.globespan.net

---

From: Bill Palter <[email-masked]>
Date: Thu, 10 Aug 2000 09:57:39 -0700

I'll resubmit the link draft...

Bill

--
Bill Palter ([email-masked])

---

From: Sumati Mittal <[email-masked]>
Date: Thu, 10 Aug 2000 15:37:32 -0400

Arthur,

Thanks for your reply. 

In both the methods you suggest, once LCP negotiation is done (whether
by LAC-remote system in method 1 or by LAC configuration in method 2),
it is not done again. However, in RFC 2661, the explanation of
Set-Link-Info section 6.14 says PPP options can change at any time
during the call, thus LAC must be able to update its internal call
information and behavior on an active PPP session.

Regards,
Sumati.

Arthur Mistler wrote:
> 
> I may be way off base here because I'm not familiar with the link extension
> draft you mentioned, however I see it exists because someone states they'll
> repost it.
> 
> But these are my impressions on your questions:
> 
> 1. The LNS does not renegotiate any LCP parameters, once LCP is completed
> between the client and LAC, it can't be re-opened, and keeping the session
> in the negotiation phase between initial LAC negotiation, tunnel opening,
> then letting the LNS go with the client may be too lengthy and therefore LCP
> on the client may time out.  So I completely establish the LCP session
> between the client and the LAC, and do a full proxy at the LNS, and if there
> is an LCP option that the LNS really can't agree to, then the session
> fails.  This means that either your LNS needs to be very flexible, or you
> should at least have matching LCP option negotiation requirements for both
> LAC and LNS.  I haven't found it to be too much of a problem doing it this
> way.
> 

> 2. This is what I call service routing, the first one which uses a proxy -
> most likely because you needed to authenticate, I call subscriber routing.
> Forgetting what I call them, though this second method I support by
> configuration.  In other words, my LAC has configuration settings per access
> resource, or per caller ID, stuff like that, where a tunnel is always opened
> for those certain class of calls, and then full negotiation of LCP is the
> responsibility of the LNS.  <I've found it useful to support both methods 1
> and 2.>
> 
> The only way the LAC can know of the negotiate LCP parameters is either to
> do method 1, where it is an active participant in the negotiation, or as you
> say, by silent observation.  But that implies you're using method 2, where
> all LCP negotiation is performed between the client and the LNS.  So in
> effect, the tunnel session is already open, so the only reason the LAC would
> want to know anything about the LCP negotiated parameters would be for
> informational purposes only, and it really doesn't seem to be worth the
> bother.
> 
> Hope this helps.
> 
> - RT
> ==============================
> Artie Mistler
> President
> Advanced Software Consultants, Inc.
> 12 Gale Road
> Sutton, MA  01590
> (508) 581-9815
> mailto:[email-masked]
> http://www.erols.com/amistler/ascihome.html
> ==============================
> 
> Sumati Mittal wrote:
> 
> > Hi,
> >

---

From: Motonori Shindo <[email-masked]>
Date: Fri, 11 Aug 2000 03:37:18 +0900 (JST)

Sumati,

From: Sumati Mittal <[email-masked]>
Subject: LCP Negotiation
Date: Thu, 10 Aug 2000 11:46:00 -0400

> answers there but cannot trace the draft.

L2TP protocol doesn't provide such a mechanism. However, it is
technically possible for a LAC to inspect (snoop) the PPP frames
exchanged between a remote system and an LNS to know how LCP (or even
IPCP and CCP) negotiation ended up. I don't know of any implementation
that does this type of snooping.

=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
 +----+----+     
 |.. .|    |     Motonori Shindo
 |_~__|    |     
 | .. |~~_~|     Sr. Systems Engineer
 | .  |    |     CoSine Communications Inc.
 +----+----+     
 C o S i n e     e-mail:  [email-masked] 
Communications
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 10 Aug 2000 15:48:06 -0400

Thanks, Bill. It seems that I issued last call on a couple of expired
drafts. I will reissue last call once the drafts are available.

Thanks,

- Mark

---

From: "Srikrishnan Subramanian" <[email-masked]>
Date: Thu, 10 Aug 2000 14:52:48 -0700

Sumathi,

  According to RFC 2661, its only ACCM option. So we can
  assume (!!) that other options should not change.

  Best way to do it is to configure the LAC profiles based
  on LNS requirements. (which I guess will most of the implementations
  will do)

  Only other option in PPP which may cause problem is MRU.
  ( I am not considering MLPPP) MRU is driver capability and if
   it got changed in LNS re-negotiation, then there could be problem.
  Which I assume implementations (LNS) should make sure that, it
  wont cross the previously agreed upon value ( Which was given to
  LNS in proxy LCP packet)

  Hope this helps

Regards
Srikrishnan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Sumati Mittal
Sent: Thursday, August 10, 2000 12:38 PM
To: Arthur Mistler
Cc: [email-masked]
Subject: Re: LCP Negotiation

Arthur,

Thanks for your reply.

Regards,
Sumati.