RE: Comments on LSP Ping 05
David Allan <dallan <at> nortelnetworks.com>
2004-06-02 15:04:52 GMT
> On Tue, 17 Feb 2004, David Allan wrote:
> > 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.
> Sequence numbers are useful for both the one-way and two-way
> modes, so removing the one-way mode won't remove the
> requirement for sequence numbers, nor significantly simplify
> the protocol. However, if there is consensus, I am okay with
> removing the one-way mode.
Works for me....
> > 2) Error code TLV, why define a TLV that is "currently not
> > I'm sure IANA can cough up a TLV ID on the day one is required.
> > Meanwhile it looks somewhat strange there.
> It doesn't bother me
Well if the intent is to block off a code point as someone is looking to do
proprietary extensions, I suppose that is useful but hardly in the spirit of
what an interoperable OAM tool should do...
> > 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
> > 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.
> You were having an interesting discussion with George -- did
> you two converge?
I'll take it up with George, last Feb was a long time ago in a galaxy
> > Stuff raised by other folks not yet addressed that I agree with.....
> > 1) Adding the 'FEC 129' format of L2 circuits.
> I'm game.
> > 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
> > why are they separate drafts?
> The same reason there is RSVP, RSVP-TE, GMPLS RSVP-TE, and more on the
> way: a base document, and extensions.
Yes, but if they are all ultimately coming through at the same time, why not
> > 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.
> Again, you and George were discussing this. I thought George
> had addressed this -- are you cool with that?
I don't think this one came up in our discussions, cannot find it in my
(admittedly spotty) archives either...
> > 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.
> Ron, care to chime in?
> > 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
> > 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!
> Please propose text.
OK, suggest inserting para after 4th in section 4.3
If there are more labels than entries in the FEC stack, then it is assumed
that additional labels were pushed onto the stack subsequent to the
insertion of the echo request and use of uniform TTL mode has resulted in a
TTL exhaust with a label stack of depth greater than one.
But this also has implications for steps 1 and 4 of 4.3.
Label can be valid and PING source address not routable. Hence the MUST
requires a caveat...So I'd suggest....
1. Check if there is a FEC corresponding to the current-
depth. If there is, go to step 2. If not, check if the source
address in the ping request is routable, if not silently discard
the packet. If it is, check if the label is
valid on interface I. If the label is valid, continue with step 4.
X MUST send an MPLS echo reply with a Return Code 11, "No label
entry at stack-depth" and a Return Subcode set to current- stack-