The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] draft-ietf-mpls-in-ip-or-gre-04.txt
The IESG has reviewed draft-ietf-mpls-in-ip-or-gre-03.txt, and have made a number of comments. In response, I have issued draft-ietf-mpls-in-ip-or- gre-04.txt. I will briefly review the comments below and indicate the changes I've made in response. (The raw comments can be found in the i-d tracker.) I encourage all interested parties to review the document again before it is resubmitted to the IESG. 1. IPv6 compatiblity. It was pointed out that the draft was not very specific about IPv6, and was also very sloppy in its use (or lack thereof) of IPv6 terminology. The new version incorporates proper IPv6 terminology and procedures. 2. Differentiated Services The old version said only that the setting of the MPLS EXP bits could be considered when determining how to set the DS field in the IP encapsulation header, and vice versa. It was pointed out that this might be too much freedom, as there is existing work on MPLS Diffserv and on Diffserv in Tunnels that needs to be referenced. The new version clarifies the intention by using the more rigorous terminology from diffserv and referring to the necessary diffserv specifications for the details. 3. What one tunnel endpoint must know about the other Some text was added indicating that the tunnel head must know the IP address and tunnel capabilities of the tunnel tail, that this knowledge could be obtained by a variety of means which are outside the scope of this document, and that this means might depend on the application which is using the tunnel. This was added in response to an objection that we needed to say a bit more than just "tunnel setup is out of scope". 4. GRE optional fields. The draft had an absolute prohibition against the use of the GRE optional fields, but did not give any rationale for this. An objection was made that this absolute prohibition is not really appropriate. The draft now states that, by default, these optional fields are not used, but that they may be used if both endpoints agree. There is also some text saying why these optional fields are not generally useful. 5. Fragmentation and reassembly. The draft had an absolute prohibition against the tunnel head doing fragmentation. It was objected that this is too strong, that there might be situations in which fragmentation and reassembly at the tunnel endpoints would be advisable. The draft now states that by default, there is not to be any fragmentation, but that an implementation must be configurable to allow fragmentation. 6. Security The draft said that if the tunnels could, if desired, be secured by IPsec. This raised the usual objection that "it is not sufficient to say just use IPsec". The draft now goes into a bit more detail about how to use it to achieve various security goals.
|
|