The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Me again:

1) The depth limit value in the downstream mapping TLV I don't think
provides sufficient information as the depth may be counted from the bottom
or the top of the stack. I'd suggest that positive values count from the
bottom, and negative values count from the top. Zero would remain as
unlimited or unspecified.

2) 4.2, "the source IP address is the routable address of the sender". Some
text to make it clearer that it is routable at the top level of the FEC
stack would be desirable. This also means that when the LSR terminates
multiple MPLS levels (e.g. a PW application), the response level must
correspond to the top level of the FEC stack.

3) Not clear why a downstream mapping TLV would appear in a request message
and there is no description as to what to do with it if you got one (a la
section 4.3).

4) Similarly with the PAD TLV, either you are going to get a fragmented ping
message or if you set DF another result. This needs to be described better
and an error code of MTU not supported added. e.g. a little more pspecified
that simply stating the "receiver SHOULD check that it was recevied in its
entirety". Similarly if you copy the PAD TLV to the reply it may get
fragmented in the reverse direction (presumably there should be a specific
"MUST NOT set DF bit in replies"). The other interesting situation is that
you may use PAD TLV with traceroute mode, and the insertion of downstream
mapping TLVs in the replies will alter the intended MTU of the message. I'm
a little unclear of the value of copy PAD to reply option so if a usage case
could be posted to the list that would be great.

more later
Dave