Subject: RE: I-D ACTION:draft-dasilva-l2tp-relaysvc-00.txt - Comments

From: "Reinaldo Penno" <[email-masked]>
Date: Mon, 13 Aug 2001 08:55:32 -0700

> >
> > 
> > The problem is how to do this. Look below.
> > 
> >       "A Relay-Session-Id TAG MUST NOT be added if the 
> discovery packet
> >       already contains one.  In that case the intermediate 
> agent SHOULD
> >       use the existing Relay-Session-Id TAG"
> 
> That is instruction for a pure PPPoE Host or AC. We are a 
> relay agent for PPPoE
> over L2TP, and can define what it is to be such an agent 
> however necessary.
> 
> > 

I disagree Mark. This is for any intermediate device. If we change the
protocol so we break previous implementations we are going to get in
trouble. You told me that (;-)

thanks,

Reinaldo

---

From: "W. Mark Townsley" <[email-masked]>
Date: Mon, 13 Aug 2001 18:15:22 +0200

> Reinaldo Penno wrote:
> protocol so we break previous implementations we are going to get in trouble.
> You told me that (;-)

For reference, here is the entire description of what a PPPoE Relay agent should
do, as defined in Appendix A of RFC2516.

0x0110 Relay-Session-Id

      This TAG MAY be added to any discovery packet by an intermediate
      agent that is relaying traffic.  The TAG_VALUE is opaque to both
      the Host and the Access Concentrator.  If either the Host or
      Access Concentrator receives this TAG they MUST include it
      unmodified in any discovery packet they send as a response.  All
      PADI packets MUST guarantee sufficient room for the addition of a
      Relay-Session-Id TAG with a TAG_VALUE length of 12 octets.

      A Relay-Session-Id TAG MUST NOT be added if the discovery packet
      already contains one.  In that case the intermediate agent SHOULD
      use the existing Relay-Session-Id TAG.  If it can not use the
      existing TAG or there is insufficient room to add a Relay-
      Session-Id TAG, then it SHOULD return a Generic-Error TAG to the
      sender.

To this I say first, it is less than clear how a relay agent should operate. 

It seems to me that the essence of this is that any coversation between the
following two entities will echo the message.

a) Host and AC
b) Host and Relay
c) AC and Relay

Specifically, a Host or AC MUST use this value in any message sent as a
*RESPONSE* to another message. Thus, if I am forwarding a PADI to other PPPoE
ACs, I may legally choose whatever value I want (this is not a response, it is
the first packet sent in a PPPoE Discovery exchange). The only statment that
*could* suggest otherwise is "the intermediate agent SHOULD use the existing
Relay-Session-Id TAG" --- I suppose the very loosely defined "use" here could
mean "use" in a response to another PAD packet, or "use" in any packet it ever
sends. I am arguing that it should be the former. At any rate, it is a SHOULD
not a MUST so we have some leeway as long as we don't break anything... and I
don't think assuming that the ID is relevant only between two entities (as
opposed to three or more) will break anything.

- Mark

---

From: Ron da Silva <[email-masked]>
Date: Mon, 13 Aug 2001 12:38:39 -0400

Does the Relay-Session-Id TAG really need to be changed when forwarded
from the LNS to the local PPPoE AC?  The LNS could use the AC-Cookie TAG
to uniquely identify the different PADOs from the LAN.

-ron

---

From: "W. Mark Townsley" <[email-masked]>
Date: Mon, 13 Aug 2001 19:12:37 +0200

You need something in the PADI to link the PADO as well. The Cookie is only
defined as present in the PADO and PADR.

So, as long as you are not forwarding to another PPPoE AC then, yes, I think the
Cookie is sufficient, and probably better, than the relay session ID. 

- Mark