Subject: RE: OAM labels (was: can egress know the ingress of a packet?)

From: Shahram Davari <[email-masked]>
Date: Mon, 5 Jun 2000 09:33:17 -0700

Peter,

Sometimes OAM packets may need to be processed by intermediate nodes as
well. By having the top label to be the forwarding label for OAM packets, we
are forced to processing them only at the egress node.

BTW, if the second label is OAM label, I don't think it will cause any
implementation problem. Because the egress node before popping the top
label, by looking at the S bit, knows that there is still another label.

Regards,
-Shahram

>-----Original Message-----
>From: Peter Willis [mailto:[email-masked]]
>Sent: Monday, June 05, 2000 12:27 PM
>To: Shahram Davari
>Cc: [email-masked]
>Subject: Re: OAM labels (was: can egress know the ingress of a 
>packet?) 
>
>
>Shahram,
>
> Wouldn't it be better to have the top label
>as the one that is used for forwarding the OAM & user data and 
>the second 
>label the one that identifies an OAM flow within a particular 
>LSP? This way 
>the OAM
>data gets treated exactly the same as the user data by the 
>non-edge LSRs.
>Obviously the problem with this approach is that the 
>terminating LSR does not
>know it has an OAM packet until it has popped the outer label; 
>this may cause
>implementation problems (Does it?).
>
>If the OAM data is treated differently from the user data then 
>any faults in
>the user data plane may not be detected correctly. The trouble with the
>Route Alert Label =1 type approach is that it is effectively 
>out-of-band;
>LSRs will treat this differently from user data which is not 
>what we want.
>
>Peter.
>
>> Peter,
>> 
>> But we can use two labels. The top label can be the reserved 
>one, and the
>> second label can be the actual label, which is used for 
>forwarding the OAM
>> packet. This is basically similar to the Router Alert Label = 1.
>> 
>> Regards,
>> -Shahram  
>> 
>> >-----Original Message-----
>> >From: Peter Willis [mailto:[email-masked]]
>> >Sent: Monday, June 05, 2000 11:37 AM
>> >To: [email-masked]
>> >Subject: RE: OAM labels (was: can egress know the ingress 
>of a packet?)
>> >
>> >
>> >
>> >An LSR will be terminating many LSPs so will be terminating 
>> >many OAM flows. 
>> >How do you correctly diagnose LSPs with merged or corrupted 
>> >labels if they all 
>> >arrive on the same reserved label? The label the OAM flow 
>> >arrives on has to 
>> >match exactly the label used for the data (user plane) flow in 
>> >order to be able
>> >to detect faults caused by LSRs using broken label swapping tables.
>> >
>> >So we need a bit somewhere in the MPLS header to identify an 
>> >OAM payload but 
>> >we need to keep the same label as used for the user plane data.
>> >
>> >Peter.
>> >
>> >
>
>

---

From: Peter Willis <[email-masked]>
Date: Mon, 05 Jun 2000 17:55:18 +0100

> are forced to processing them only at the egress node.

	OK can we do both? For most OAM functions I'm only interested in
	OAM processing at the edge. Besides which if we require intermediate
	LSRs to process all OAM then this will not scale. However I do
	admit in some circumstances I may like an intermediate node
	to do something e.g. a LSP traceroute function.

	Its just from experience I know that if the OAM/test tools available
	use packets that are not treated the same as the users data packets
	then the results are often doubtful (for example see the misleading
	results caused by using ping).
> label, by looking at the S bit, knows that there is still another label.

	I was more thinking along the lines of; pop the outer label,
	find its an OAM label, NOW I need to know the outer label to
	process the OAM packet correctly but I've already used it and
	lost it! 

	Setting the S bit could also cause a minor problem. Presumably
	the S bit in the user data label will be set but not in the
	OAM data outer label. Hence if we have an implementation bug to
	do with the operation of the S bit it would not be detected by
	the OAM.

Peter.