Subject: [L2tpext] FWD: re: IETF last call on draft-dasilva-l2tp-relaysvc-05.txt

From: Thomas Narten <[email-masked]>
Date: Fri, 21 Feb 2003 12:18:51 -0500

Some latish LC comments. BTW, you guys were supposed to check ID nits
per my previous review, but apparently missed the reference split
cited below...

Thomas
------- Forwarded Message

From: Erik Guttman <[email-masked]>
To: [email-masked]
cc: Erik Guttman <[email-masked]>
Date: Fri, 14 Feb 2003 14:01:48 +0100 (CET)
Subject: re: IETF last call on draft-dasilva-l2tp-relaysvc-05.txt
Reply-To: Erik Guttman <[email-masked]>

I realize the last call is over but I looked at this document and have a
few comments.

- normative/informative split needed for references

- what is the content of the <attribute type> transmitted
  in the PPPoE Service Relay Response Capability AVP and
  PPPoE Service Relay Forward Capability AVP?

- what is the recommended speed at which a host should retry
  sending PADRs to establish a session?  When should it give
  up after not getting a PADS?  In general - what happens
  if there are failures and delays?  I believe this could
  cause congestion problems on the network and resource
  consumption issues on the LNS's (who do not know if the 
  PADS has been sucessfully delivered, right?)

  RFC 2516 addresses this for PADI and PADO messages:

  section 8
  When a host does not receive a PADO packet within a specified amount
   of time, it SHOULD resend it's PADI packet and double the waiting
   period. This is repeated as many times as desired.  If the Host is
   waiting to receive a PADS packet, a similar timeout mechanism SHOULD
   be used, with the Host re-sending the PADR.  After a specified number
   of retries, the Host SHOULD then resend a PADI packet.

  but I do not see the equivalent here.

- it looks to me like from RFC 2516 as if the PADO contains
  a human readable string. 

   section 5.2
      The PADO packet MUST contain one AC-Name TAG containing the Access
   Concentrator's name, a Service-Name TAG identical to the one in the
   PADI, and any number of other Service-Name TAGs indicating other
   services that the Access Concentrator offers. 

   section 8
   UTF-8 [5] is used throughout this document instead of ASCII.  UTF-8
   supports the entire ASCII character set while allowing for
   international character sets as well.  See [5] for more details.

   Are service names protocol identifiers or human readable strings?
   If they are protocol ids, where are they documented?  If they are
   human readable, what language are they written in?  I believe a
   language tag must be present in this case.  [RFC 2277, section 4.2]

- as this is a discovery protocol, a full example of what the
  client requests and gets would help.

- how does the receiver of the SRRQ alert the sender if it is invalid?
  Should the receiver throw the request away or send back some form
  of error message?

Best regards,

Erik

------- End of Forwarded Message
_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext

---

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 28 Feb 2003 16:15:54 +0100

Thomas, Erik,

Ron and I looked over these comments. Answers inline.

Thanks!

> - normative/informative split needed for references

Sorry, we have identified them and made the changes.

>   PPPoE Service Relay Forward Capability AVP?

This is an L2TP AVP Attribute, a 16 bit number, to be assigned by IANA.

Please see IANA Considerations, section 6.0.

 >   but I do not see the equivalent here.

All PPPoE PAD control messages are being delivered between the LAC and LNS 
embedded within an L2TP Control Message. As an L2TP Control Message, the 
embedded PAD message will undergo all of the properties of normal L2TP Control 
Message delivery, including retransmission backoff and acknowledgement as 
defined in RFC2661.

>    language tag must be present in this case.  [RFC 2277, section 4.2]

As far as L2TP is concerned, these values are defined by and contain the same 
properties as in the PPPoE specification. L2TP does not interpret the values 
except to differentiate duplicate PPPoE messages (which, technically, would more 
be considered a function of the PPPoE software residing on the LAC or LNS than 
L2TP), and to copy the values, byte-by-byte, into an L2TP control message for 
transporting to a PPPoE Server or Client.

>   client requests and gets would help.

PPPoE is a discovery protocol, L2TP is not, nor is PPPoE/L2TP relay. L2TP is 
simply picking up the PPPoE Client messages, transporting them to the designated 
PPPoE server residing on the other side of the L2TP connection, and back.

>   Should the receiver throw the request away or send back some form

The SRRQ itself is reliably delivered by the L2TP mechanisms defined in RFC2661 
between the PPPoE Client and Server. There really is no such thing as an 
"invalid" SRRQ, as L2TP is not operating on the contents other than to pass them 
to the PPPoE server for it to respond.

If the embedded PPPoE message itself is invalid, an error message will only be 
returned as a PPPoE message embedded within another L2TP control message and 
forwarded to the client. L2TP will be completely unaware that there was an 
invalid message exchange between the PPPoE endpoints.

If there is something invalid in the L2TP message itself (such as a malformation 
of the contents) there are some general recommendations on how to recover in RFC 
2661, possibly resulting in a teardown of the Control Connection. This is all 
pretty drastic though, and if you are malforming your control messages, well, 
you really don't know what you can and cannot recover from as it depends on what 
part of the message was malformed and whether or not there is robustness for 
receipt of that type of malformation.

> Best regards,

Thanks for your comments, Erik. I hope I have answered your questions 
satisfactorily. Ron is making changes (Clarification of what "Attribute Type" is 
and References split) and we will post the result by the deadline on Monday if 
we don't hear otherwise before.

Thanks,

- Mark & Ron

---

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 28 Feb 2003 16:15:54 +0100

Thomas, Erik,

Thanks!

Thanks,

- Mark & Ron