Subject: Latest MPLS Ping draft...

From: "Brian Hassink" <[email-masked]>
Date: Tue, 15 Oct 2002 14:45:28 -0400

Hello,

A few thoughts/suggestions/questions on the latest MPLS Ping draft...

I'm wondering if it wouldn't be better to move the return code from the main header to the TLV header, or add a return code to the TLV header? I think there may be a couple of good reasons for doing this...

o As more message types and TLV types are defined, more return codes will be required, possibly leading to overloaded meanings and a loss of scope.
o If multiple TLVs are bundled in a request, a single return code may not be sufficient to return the full results of the request.

I think the return code in the main header could be used for more general results, such as "no error", "unsupported version", "malformed request", "reply too big", etc, and the return code in the TLV header could be used for results specific to that TLV.

Also, couldn't a (optional) "timestamp" TLV be defined rather than having this information as mandatory fields in the main header?

Lastly, it's not clear to me which FEC applies to a tunnel that has been setup manually (i.e. static tunnels)?

Cheers,
Brian
---
[email-masked]

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 21 Oct 2002 13:36:22 -0700 (PDT)

On Tue, 15 Oct 2002, Brian Hassink wrote:

> I'm wondering if it wouldn't be better to move the return code from the
> main header to the TLV header, or add a return code to the TLV header? I
> think there may be a couple of good reasons for doing this...

Read section 3.4, and the documentation for value 0 for the return code.

> Also, couldn't a (optional) "timestamp" TLV be defined rather than
> having this information as mandatory fields in the main header?

Any particular reason?  One could make TLVs of all fields, not just the
timestamp fields.

> Lastly, it's not clear to me which FEC applies to a tunnel that has
> been setup manually (i.e. static tunnels)?

There isn't one at present.  One could add one, if it is deemed useful.

As for checksums, UDP does have a checksum; most underlying transport
does as well.  If some new reply mode is introduced which doesn't have
a native checksum, a checksum TLV can be added -- however, I would wait
until a concrete reason is given, so that the figh ... um, discussions
about which particular checksum methodology be used can have a concrete
basis.

Kireeti.