The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Latest MPLS Ping draft...
Please see followup comments inline below... Cheers, Brian Hassink --- bhassink@hatterasnetworks.com -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Monday, October 21, 2002 4:36 PM To: Brian Hassink Cc: mpls@UU.NET Subject: Re: Latest MPLS Ping draft... 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. [BH] Ok, I'll buy that. I think that if this "protocol" evolves to support other inband OAM functions, that a more granular error reporting mechanism will be required. However the "error" TLV ends up getting defined, there will likely be a result per TLV, or set of associated TLVs, and I figured allowing for a return code within the TLV may result in less correlation and processing overhead. > 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. [BH] I think that measuring delay/RTT is not necessarily something you want to combine with testing/validating connectivity. And again, if this "protocol" evolves to support other inband OAM functions, then it may become even less relevant to a given function. > 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. [BH] Seems like at pretty useful thing to be able to do. Static tunnels are used in networks and I would think the reasons for monitoring them would be the same as if they were signaled. 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. [BH] Fair enough. Kireeti. |
|