Ron Bonica wrote:
> Folks,
>
> An updated version of draft-bonica-internet-icmp is attached. I
> apologize for not getting it out sooner.
>
> I believe that this version addresses the issues that Joe raised on the
> mailing list earlier.
>
> Ron
Due to some spectacular scheduling of WG meetings for Dallas, I will not
be able to attend the INT area meeting
There are two drafts for which I had wanted to participate in
discussion, so I'll post my notes here in advance of the meeting. I hope
I am not preempting any of the discussion that might occur in the room,
but this seems more productive than commenting post-facto. I'll be glad
to discuss this further on the mailing list (except in realtime during
the WG meeting). I may try to be on Jabber, but it's unlikely I will be
able to participate substantively there.
This note addresses draft-bonica-internet-icmp-02 (the recently posted
update).
I had reviewed a previous (00 and 01) versions of this document and
provided feedback to Ron. My general impression:
- this document makes a change to ICMP processing that is NOT backward
compatible with the current standard; as a result, this document must
end up in the standards track or experimental with substantial warnings
(I'm not sure if that hum will come up)
- I generally agree with the changes being proposed, which allow a much
more flexible use of ICMP for the future
There are exceptions. For example, I consider it inappropriate
to issue either a std-track or even experimental change that
endorses non-standard behavior, as per sec 4.5
- it might be useful to consider that the motivation for this document
is to find a way to attach MPLS headers with the corresponding IP
packets; while I again agree with the general notion of extensibility in
ICMP, I do NOT consider it appropriate to modify an Internet protocol
primarily to support a sub-IP layer. I would prefer it ICMP developed
its own signalling rather than to co-opt IP's.
I consider it especially NOT appropriate to design a modification to be
backward compatible with a non-std-compliant variant (as per sec 4.5).
These two last points are relevant if we NEED a motivation to extend
ICMP. Since ICMP is a core Internet protocol, I would hope we do. So
here's what I would suggest:
- this document should be adopted as an INTarea WG document to be
developed as an EXPERIMENTAL RFC
- support for non-std-compliant variants be removed
in fact, the whole point ought to be to bring everyone
into compliance, even if with the experimental version only
If someone can suggest an IP-layer motivation for extending ICMP this
way, then I would favor this as INTarea WG document for standards-track.
Such a motivation would exclude MPLS considerations, as I don't consider
them relevant to this decision at all, as per above.
More specific feedback has been posted to the author, with notable
excerpts only below. I hope this helps.
Joe
----
4.3 - this is the largest current problem area. it's bad enough to
extend ICMP in a non- standards-backward-compatible way, but it is NOT
appropriate to **limit** this design to accommodate backward
compatibility with non-standards-compliant mods. This REALLY makes the
case that MPLS versions should have their own message protocol, or at
least have their own ICMP message types.
I.e., THIS SECTION PROHIBITS USE OF THIS EXTENSION FOR DEST-UNREACHABLE
WITH MORE THAN 128-BYTE PAYLOADS. This is NOT a minor issue - this KILLS
THE UTILITY OF THIS MOD for new versions. Traceroute is a major issue -
and it may be the case that some future protocols will require full,
i.e., signed packets to be returned; this PREVENTS THIS POSSIBILITY -
even if the sender designed the packets to fit in the ICMP payload limit.
IMO, this section needs to be changed to require existing MPLS
traceroutes to play by the rules, rather than ignore them. If that's not
feasible, then - IMO - MPLS should get out of the ICMP pool ;-)
*****
4.5 end - The last sentence is not acceptable, as per above. It's a very
bad idea to endorse noncompliant operation without redefining it as
compliant, which is not what I get out of either this or sec 4.3 - esp.
since this limits other uses of ICMP traceroutes with longer payloads.
5 - explain the purpose of the checksum (to indicate the presence of the
option!). IMO, the checksum should be exactly the signal that the option
is there or not.
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
