The MPLS WG Archive

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

Hi Kireeti:

Some comments on the respun draft....

1) Removal of one-way mode. IMO has merit, and the protocol can then be
simplified as the sequence number can also be removed. I'd welcome other
comments on this.

2) Error code TLV, why define a TLV that is "currently not defined". I'm
sure IANA can cough up a TLV ID on the day one is required. Meanwhile it
looks somewhat strange there. 

3) If it's all the same to everyone else, I preferred my proposed processing
rule for section 4.3 as it outlined the actual verification of the FEC for
PHP vs. the change currently made. The document as written suggests that
where there are more FECs than labels, the FECs can simply be ignored via
"pop and continue processing" until such time as when you can match FECs to
labels which is not correct.

Stuff raised by other folks not yet addressed that I agree with.....

1) Adding the 'FEC 129' format of L2 circuits.

A suggestion....

1) If LSP-PING and LSR-SELF-TEST are both WG items using the same protocol
(LSP-PING variations) to achieve common goals (verification), why are they
separate drafts?

And previous comments not yet addressed or responded to....

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) 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.

4) Re-iterating the concept of using the FEC stack to infer what level the
addresses in the header refer to. I can envision  messy situations whereby I
was using a VRF loopback address in a packet that TTL exhausted at a P
router (or the ping originated at a CE in a CsC scenario). WOuld be nice to
see a bit more clarity on routing of replies. Glad to propose some text!

cheers
Dave