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

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 23 Jul 2007 19:24:59 +0100

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.

If you have any questions then please send mail, or corner me or George 
during the week.

Thanks,
Adrian 

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 23 Jul 2007 13:38:15 -0500

It looks like your Security Considerations section is
a little light. *)

	--Tom

> 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.
>
> If you have any questions then please send mail, or corner me or  
> George during the week.
>
> Thanks,
> Adrian
>
>
>

---

From: "Nitin Bahadur" <[email-masked]>
Date: Tue, 24 Jul 2007 07:47:56 -0700

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:[email-masked]]
> Sent: Monday, July 23, 2007 1:25 PM
> To: [email-masked]
> Subject: [mpls] Proposed reforming of LSP Ping TLV processing
> 
> Hi,
> 
about

---

From: <[email-masked]>
Date: Sat, 28 Jul 2007 09:54:02 +0100

Adrian/guys,

Just an observation of what the real architectural problem is here
(though I hasten to add we can do nothing about this now...too late):

When one designs a layer network (any mode/technology) one MUST ensure
that the characteristic information (CI - which is a term from func arch
that has a very specific meaning, but I can't really get into detail of
what this means here) that is created/removed at trail/flow termination
points is ALWAYS consistent (and a key corollary of this is that the CI
MUST be client independent).  One rather important observation here is
that the OAM of a layer network is injected/extracted at trail/flow
termination points and thus forms an intrinsic part of the CI of a layer
network.

MPLS does not have consistent CI for a whole raft of reasons, eg the
label field can take on different semantics depending on what
protocol/use-case generated it....I can list at least 4 different
semantics here.

What this means practically is that under misconnectivity defects the
true intended meaning of a functional field in a traffic unit can be
misunderstood by whichever node terminates the offending misconnected
traffic units.....which also includes the OAM pkts.  So yes, Tom is
right to point out that there are potential security implications
here.....but just be aware that this is a symptom/consequence of not
having consistent CI in the 1st place, and its a bigger problem than
just the one being discussed.

Don't want start a debate on this as there is nothing much we can do
about it...because as I already noted it's too late.....but I did want
to point out what the underlying architectural issue is here.

regards, Neil

> From: Thomas D. Nadeau [mailto:[email-masked]] 
> Sent: 23 July 2007 19:38
> To: Adrian Farrel
> Cc: [email-masked]
> Subject: Re: [mpls] Proposed reforming of LSP Ping TLV processing
> 
> 
> 
> > [email-masked] https://www1.ietf.org/mailman/listinfo/mpls
> 
>