Re: [mpls-tp] draft-boutros-mpls-tp-performance

[Stewart Bryant <[e-mail]>]

Tom

Remember its 
http://tools.ietf.org/html/draft-frost-mpls-tp-loss-delay-00 not 
draft-boutros-mpls-tp-performance that you need to look at

Why not RFC4656

1) We did not think that we could get 4656 efficiently implemented in h/w

2) We assumed that we would not have TCP available as the control 
channel, so we would have needed to create new control channel

3) We need both one way and two way, including two way without GPS 
clocks at the remote

- Stewart



Thomas D. Nadeau wrote:
>     Stewart,
>
>     Why have you guys decided to invent a new protocol for performance
> measurements versus using what is defined in RFC4656 (IPPM) and perhaps
> re-encapsulating it for MPLS-TP purposes?
>
>     --Tom
>
>
>
> On 4/5/10 5:08 AM, "Stewart Bryant" <[e-mail]> wrote:
>
>   
>> Vishwas
>>
>> Thank you for reviewing draft-boutros-mpls-tp-performance
>>
>>  http://tools.ietf.org/html/draft-frost-mpls-tp-loss-delay-00 is a more
>> robust protocol for measuring loss/delay and is the draft that I would
>> prefer to move forward with.
>>
>> - Stewart
>>
>>
>> Vishwas Manral wrote:
>>     
>>> Hi,
>>>
>>> I noticed some interesting things in the performance monitoring draft.
>>> The most interesting thing is point 4 I have noted.
>>>
>>> 1. The draft may be trying to measure packet loss but it assumes the
>>> performance messages cannot be lost. This seems like a very
>>> interesting assmption.
>>>
>>> 2. On the same lines if we assume the above not true, we may need to
>>> define retransmits from senders and no/ ACK NACK retransmits.
>>>
>>> 3. We also need to define how to identify duplicate messages and how
>>> duplicate packets are to be treated.
>>>
>>> 4. I also notice to measure packet loss we use the sequence number in
>>> the packets themselves:
>>>
>>> To measure packet loss I guess the receiver looks at the gaps in the
>>> sequence numbers. However there are basic issues with this.
>>>
>>> Sender sends packet 1 to 100. Receiver receives packet 1 to 80.
>>> Receiver does not know 100 packets are going to be sent, so it says
>>> packet loss is 0 even though there are 20 packets that are lost.
>>>
>>> 5. I assume it would be good to state that the sequence number of the
>>> first packet is 1. Also if there are wrap arounds what needs to be
>>> done. In my view we should use 64 bit values for sequence numbers, it
>>> is like a packet counter.
>>>
>>> Thanks,
>>> Vishwas
>>>
>>>   
>>>       
>
>
>
>
>   


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html