The MPLS WG Archive

[Kireeti Kompella <kireeti@juniper.net>]

Hi Dave,

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.

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

It doesn't bother me :-)

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

You were having an interesting discussion with George -- did you two
converge?

> 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 (verification), 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.

> 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?

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

Okay.

> 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 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!

Please propose text.

Kireeti.
-------