Subject: RE: SLI from LNS to LAC ...

From: Keyur Parikh <[email-masked]>
Date: Tue, 15 May 2001 13:19:18 -0400

How about negotiated FCS (RFC 1570) from LNS to LAC.

-----Original Message-----
From: W. Mark Townsley [mailto:[email-masked]]
Sent: Tuesday, May 15, 2001 1:17 PM
To: Elwin Eliazer
Cc: [email-masked]
Subject: Re: SLI from LNS to LAC ...

WEN is currently the only "after session establishment" message defined
for receipt by an LNS. New messages are not difficult to create though.
What type of information would you like to signal?

- Mark

Elwin Eliazer wrote:
> 
> Hi,
> 
> Are there any standard way of changing the
> characteristics of a L2TP tunnel/session
> after the tunnel/session setup is complete?
> 
> SetLinkInfo (SLI) PDU defined in RFC 2661,
> section 6.4 can only be used by LNS to
> inform LAC. Are there any methods like that
> from LAC to LNS?
> 
> Your response would be appreciated.
> 
> regards,
> Elwin.
> 
> =====
> -------
> Elwin Stelzer Eliazer
> Corona Networks
> San Jose, CA
> 408-519-3832
> -------
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Auctions - buy the things you want at great prices
> http://auctions.yahoo.com/

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 15 May 2001 13:30:15 -0400

> How about negotiated FCS (RFC 1570) from LNS to LAC.

I believe alternate FCS was deprecated by pppext, but if you still need
this, please look at:

http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-link-01.txt

---

From: Bill Baumann <[email-masked]>
Date: Tue, 15 May 2001 12:14:35 -0700 (PDT)

I've thought that SLI was of questionable value.

Shouldn't the LAC be involved in the negotiation of the physical
parameters (ACCM, MRU, and Alternate FCS) rather than relying on the LNS
and client to decide values the LAC will use?

Wouldn't it work to have the LAC sit in the middle of the LCP
negotiations, intercepting and rejecting CONF REQ messages that are
unacceptable to it?  It would also monitor for CONF ACKs and use that
information instead of relying on SLI.

I'm curious what parameters might go the opposite direction.  I imagine a
more sophisticated LAC having such needs.

Bill

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 15 May 2001 15:42:01 -0400

Authentication type, which is determined at LCP negotiation time, is
typically more significant to the LNS. MRU is also more useful as it can
take into account the intervening tunneled network. Others do make more
sense at the LAC.

Also, LCP may be renegotiated on a link at anytime. So, unless
negotiation is allowed end-to-end, then the LAC has to sniff every
packet and intercept the negotiation. 

Sitting "in the middle" of PPP negotiation has been done before. Old
ISDN TAs used to do this with multilink ISDN B channels before sending
to a PC via an RS232 port (before PCs Operating Systems had Multilink
PPP built in). What we have is a compromise that seems to work well for
most environments today. I have only seen ACCM be an issue in a small
number of cases, usually where a PPP implentation is being very strict
in what it may receive.

- Mark

---

From: Bill Palter <[email-masked]>
Date: Tue, 15 May 2001 12:47:04 -0700

Look at the draft  draft-ietf-l2tpext-link-02.txt, in it Mark and 
I tryed to address these issues...

Bill

--
Bill Palter ([email-masked])