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

[Vishwas Manral <[e-mail]>]

Hi Stewart,

I read the draft and it looked considerably better than the other one
on the first skim of the draft.

I will send across comments on the new draft.

Thanks,
Vishwas

On Mon, Apr 5, 2010 at 10:09 AM, Stewart Bryant <[e-mail]> wrote:
> 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
>
>
>