Subject: Re: [Mpls-interop] [Jwt] RE: Overview v10 and meeting notes uploaded

From: Thomas Nadeau <[email-masked]>
Date: Thu, 10 Apr 2008 09:08:36 -0400

There is no inherent reason why you need to mark the packets in the
header in any special way.  This has already been done in practice for years
with things like Cisco's SAA/IPSLA as well as IPFIX.  I suggest we not
complicate the packet format because it is unnecessary.

    --Tom

> Stewart,
> 
> One of the OAM features is the ability to determine packet loss and detect
> as such a Signal Degrade condition. This OAM function requires that every
> packet can be identified uniquely to be part of the monitored connection and
> be part of a specific priority within that connection. This identification
> is included in the label stack entry header, i.e. in the label field and in
> the EXP field. Removing this label stack entry header from the packet
> removes the necessary identifier information from the packets. Adding
> replacement identifier information to only the OAM packet is not sufficient;
> such information must then also be added to the non-OAM packets. It is in my
> opinion much simpler to just keep the label stack entry header attached to
> the packets.
> 
> Regards,
> Maarten
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stewart Bryant
> Sent: 09 April 2008 13:08
> To: Malcolm Betts
> Cc: Nurit Sprecher; ext Loa Andersson; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Jwt] RE: [Mpls-interop] Overview v10 and meeting notes
> uploaded
> 
> Malcolm Betts wrote:
>> The problem is not confined to the OAM flow, that is easy to fix by
>> including the source identifier in the OAM frame.
>>  
>> The more difficult problem is demultiplexing the connections at the
>> receive end. In the diagram below how can the box on the far right
>> demultiplex the frames from the "blue" and "orange" connections.
>> Clearly if the client is an IP router it does not need to rely on the
>> server layer to distinguish the source (since it is in the IP header).
>> However for an arbitrary client it is necessary for the server layer
>> to distinguish between the client connection that it is supporting.
>>  
> The original context was PHP, in which case the context passed must be
> sufficient to identify the next processing operation.
> 
> In the case of IP then the IP address does that.
> 
> In the case of MPLS the top label (for example the PW label) does that.
> 
> In the case of OAM we are suggesting that an identifier in the OAM payload
> would be sufficient, and in the case of certain network faults would
> probably be better than implying the source from the destination label.
> 
> Stewart
> 
> 
> 
> 
> 
> _______________________________________________
> Jwt mailing list
> [email-masked]
> http://mail.testbed.se/mailman/listinfo/jwt

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

---

From: "Italo Busi" <[email-masked]>
Date: Fri, 11 Apr 2008 12:27:20 +0200

Tom,

I agree with you.

I think that switching off PHP is the best approach to solve the issue Maarten
has identified without complicating the packet format.

Italo 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Thomas Nadeau
> Sent: Thursday, April 10, 2008 3:09 PM
> To: Maarten Vissers; Stewart Bryant; 'Malcolm Betts'
> Cc: [email-masked]; 'Nurit Sprecher'; [email-masked]; 
> [email-masked]
> Subject: Re: [Mpls-interop] [Jwt] RE: Overview v10 and 
> meeting notes uploaded
> 
> 
> 
>