Comments: Key and Sequence Number Extensions to GRE to Proposed Standard

[Randy Bush <randy@psg.com>]

------- start of forwarded message -------
From: "pcalhoun@eng.sun.com" <Pat.Calhoun@eng.sun.com>
To: iesg@ietf.org
Cc: pcalhoun@eng.sun.com
Subject: Comments: Key and Sequence Number Extensions to GRE to Proposed Standard
Date: Fri, 28 Apr 2000 12:37:08 -0700 (PDT)
Message-ID: <Roam.SIMC.2.0.6.956950628.6133.pcalhoun@nasnfs.eng>

Here are my comments on the above draft:

1. "Network Working Group" in the header. Perhaps this is appropriate, but I am unaware of such a WG.

2. Section 1.0 states:

	"The  Key field is  used to create separate sub-tunnels within  a GRE 	
	 Tunnel."

and section 3.1 states:

	"Key field is intended to be used for  creating separate sub-tunnels 
	 within a  GRE Tunnel and the Key field identifies the sub-tunnel. 

The concept of a sub-tunnel is new to me (and to RFC1701), and is not described anywhere. What are the properties of a sub-tunnel? How are they managed? How are they different from GRE tunnels? I believe that the concept of a sub-tunnel needs to be well defined.

I don't really know how to implement sub-tunnels in my implementation.

3. Section 2.2 contains some bad paragraph alignment (nit-pick)

4. Section 2.2 describes the sequence number, and how it is used to deliver packets in-order to the above layer. The document also mentions that packets may be buffered when received out of order. The issue I have with this is how does a node know that a packet was lost, and will not be received? If some buffering is done, and the GRE stack expects n+1, which was lost, what does it do with packets n+1+x? I believe that if the draft will discuss the buffering of packets, some guidelines are required in describing what needs to be done when the next in-order packet is never received.

This is especially important since GRE is unreliable (and it should be).

5. The References are inconsistent. A single format would be nice.

6. Stan Hanks' name is misspelled in [1].

7. Having the following at the end of an Internet-Draft is highly irregular:
	
	Thank You.
	Regards,
	Gopal
	

	Gopal Dommety
	408 525 1404 
	gdommety@cisco.com
	Cisco Systems, San Jose, CA, 95051

8. The very fact that a Key is present in the GRE header, begs the question as whether this draft has any Security Considerations, whose section is suspiciously absent.

9. Since some bits were allocated from the GRE header, is an IANA considerations section required?

Thanks,

PatC

------- end of forwarded message -------