RE: [mpls] Proposed reforming of LSP Ping TLV processing

Adrian,

  I am not 100% convinced on the need for TLV type
"Ignore the entire message if TLV is unrecognized".

I presume the intent was that we want the *newer* nodes to process the
msg as per the new TLV specifics and want others to ignore the msg. 

Let's say if we have a new tlv and we make it's tlv type as "mandatory".
In such a case, an *old* LSR would reply back with TLV unsupported (2).
This helps the sender of the echo request to know that some downstream
does not support a specific TLV (details of unsupported tlv are captured
in "error tlv" in echo-response). 

The advantage of this is that we now know that that the downstream node
is "alive", rather than assuming that the packet got dropped or
downstream is in error (useful in debugging). It is up to the sender on
how to react to "tlv unsupported" error. Sender does not necessarily
have to treat this as an error and can resend the msg without some of
the *newer* TLVs or ignore such downstreams.

With regards to 
  "Support for the TLV is mandatory at an egress LSR, but is
   optional at a transit LSR"; 

I am thinking *aloud* if we need a reverse type also (aka support is
mandatory on transit and optional on egress). It would just make things
more symmetrical. Maybe you can come up with a convincing case in the
P2MP trace case.

Thanks
Nitin

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: Monday, July 23, 2007 1:25 PM
> To: mpls@lists.ietf.org
> Subject: [mpls] Proposed reforming of LSP Ping TLV processing
> 
> Hi,
> 
> I should have introduced this sooner...
> 
> George and I have thrown together a draft that we have been talking
about
> for some time. "Future-Proof TLV Codepoint Space for LSP Ping"
> (http://www.ietf.org/internet-drafts/draft-farrel-mpls-lsp-ping-tlvs-
> 00.txt)
> is intended to allow LSP Ping extensions to be backward compatible by
> defining processing rules for TLVs based on the ranges from which the
Type
> value is allocated. Or, phrased a different way, to set aside two bits
> from
> the TLV Type to define the processing rules.
> 
> This first version of the draft is pretty rough, but we hope that the
> ideas
> will carry forward and gain working group consensus. If so, the main
> impact
> would be to update the IANA registry. New LSP Ping TLVs (and sub-TLVs)
> would
> then have to indicate the processing rules when the TLV is not
understood.

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls