Subject: Re: [mpls] Working Group Last Call for draft-ietf-bfd-intervals (ending July 15)

From: Gregory Mirsky <[email-masked]>
Date: Mon, 14 Jul 2014 17:08:31 +0000

Hi Marc, Mahesh, et. al,
to the best of my knowledge, I've added MPLS WG to the discussion in case I have missed it, there's no explicit requirement to support 3.3 msec for the benefit of MPLS-TP. But as we consider MPLS-TP to be foundation for packet-switched transport and that there's explicit requirement to support sub-50 msec protection switchover, then we conclude that, like in TDM transport, 10 msec is budgeted to detect a defect. Hence CFM/Y.1731 require support of 3.3 msec. I think that support of 3.3 msec by a BFD implementation is a requirement if sub-50 msec protection to be provided in a network. (Note, that actual detection by CFM/Y.1731 and BFD will vary slightly.)

	Regards,
		Greg

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Marc Binderberger
Sent: Sunday, July 13, 2014 11:54 PM
To: Mahesh Jethanandani
Cc: [email-masked]
Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15)

Hello Mahesh,

> That is what happens when you have read the complete draft :-(

the full 8 pages, yes ;-)

> Question around the explanation provided in Appendix A. 
> 
> For 3.3ms: required by MPLS-TP -  is there a reference you can cite? 
> Also, is this a requirement only for MPLS-TP?

MPLS-TP was at least driving this requirement. I have to ask my MPLS colleagues if this has been written down explicitly meanwhile.

> The rational for 20ms applies to 10ms (with a multiplier of 3) and explains 
> the why. Better than saying general consensus and not explaining the why. 
> Would you agree?

Various people have expressed their strong interest to have 10msec in the set 
of intervals. For various reasons. The ability to detect/restore in 50-60msec 
is of course important but even more important was the fact that many vendors 
are about to implement or have already implemented 10msec. That's why I wrote 
"general consensus" instead of trying to rationalize the value.

Regards, Marc

> 
> On Jul 8, 2014, at 9:27 PM, Marc Binderberger wrote:
> 
>> Hello Mahesh,
>> 
>> appendix A of the draft is explaining the selection.
>> 
>> 
>> Best regards,
>> Marc
>> 
>> 
>> On Tue, 8 Jul 2014 17:42:41 -0700, Mahesh Jethanandani wrote:
>>> Jeff et. all,
>>> 
>>> Having just tried an interoperability BFD test between two vendor boxes, 
>>> I 
>>> can see why having the defined common intervals would be useful. So yes, 
>>> a 
>>> support for the draft.
>>> 
>>> Would it be helpful to have some rational for why the said intervals were 
>>> selected? Typical rationals that I have heard for the faster intervals 
>>> are 
>>> that operators want a 50ms protection switchover. For that 3.3ms and 10ms 
>>> meet the detection requirements. What goal is 20ms trying to achieve?
>>> 
>>> A 100ms and 1s intervals are helpful for applications that do not have 
>>> stringent requirements (e.g. protection of a voice stream) but can 
>>> benefit 
>>> from a quick detection. Examples include routing protocols that use BFD 
>>> as 
>>> a hello protocol.
>>> 
>>> 
>>> On Mon, Jul 7, 2014 at 11:49 AM, Pablo Frank <[email-masked]> wrote:
>>>> I'm working on a HW implementation that supports the proposed intervals 
>>>> and the draft was useful in that context.  I can see that the non-Y.1731 
>>>> standard intervals (i.e. 20ms, 50ms) could prove a challenge for some 
>>>> existing hardware implementations, but these rates should be within the 
>>>> capability of most software implementations.  Even for existing hardware 
>>>> implementations, since the new rates are a multiple of 10ms, it's 
>>>> usually 
>>>> not *that* challenging.  So yes/support.
>>>> 
>>>> regards,
>>>> Pablo
>>>> 
>>>> 
>>>> 
>>>> On Mon, Jul 7, 2014 at 12:12 PM, Vengada Prasad Govindan (venggovi) 
>>>> <[email-masked]> wrote:
>>>>> Hello Jeff,
>>>>>  From an implementer's perspective, I see this draft adds value by 
>>>>> steering implementations towards a point of convergence. I support this 
>>>>> draft for publication.
>>>>> Thanks
>>>>> Prasad
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Jeffrey 
>>>>> Haas
>>>>> Sent: Monday, July 07, 2014 4:21 AM
>>>>> To: [email-masked]
>>>>> Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals 
>>>>> (ending 
>>>>> July 15)
>>>>> 
>>>>> We are coming up on the second week of this WGLC and have thus far only 
>>>>> heard from one non-author. :-)  Please take a moment and review this 
>>>>> draft, especially if you are an implementor.
>>>>> 
>>>>> -- Jeff
>>>>> 
>>>>> On Mon, Jun 30, 2014 at 12:38:46PM -0400, Jeffrey Haas wrote:
>>>>>> Working Group,
>>>>>> 
>>>>>> We would like to initiate the start of Working Group Last Call for
>>>>>> Common Interval Support in BFD:
>>>>>> 
>>>>>> http://tools.ietf.org/html/draft-ietf-bfd-intervals-01
>>>>>> 
>>>>>> Note that the intended status of this document is INFORMATIONAL.
>>>>>> 
>>>>>> Please send your comments, including whether you think the draft is
>>>>>> ready for publication or not, to the list no later than July 15.
>>>>>> 
>>>>>> -- Jeff and Nobo
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Mahesh Jethanandani
>>> [email-masked]
> 
> Mahesh Jethanandani
> [email-masked]
> 
> 
>

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 15 Jul 2014 09:49:02 -0700

Hello Greg et al.,

indeed, I got a similar feedback from my colleagues working on MPLS-TP. Have 
to look into the particular documents (e.g. G.783) to see it with my own eyes 
but it seems the budget is 10msec detection + 50msec restoration. Always 
thought it's the other way around.

Then the 10msec detection time lead to 3 x 3.3msec, yes.

I will update our document with a sentence, especially as I haven't found any 
IETF reference (draft/RFC) with an explicit requirement for MPLS-TP. It's 
"borrowed" from Sonet/SDH specs.

Thanks for confirming!

Regards, Martc

On Mon, 14 Jul 2014 17:08:31 +0000, Gregory Mirsky wrote:
> Hi Marc, Mahesh, et. al,
> to the best of my knowledge, I've added MPLS WG to the discussion in case I 
> have missed it, there's no explicit requirement to support 3.3 msec for the 
> benefit of MPLS-TP. But as we consider MPLS-TP to be foundation for 
> packet-switched transport and that there's explicit requirement to support 
> sub-50 msec protection switchover, then we conclude that, like in TDM 
> transport, 10 msec is budgeted to detect a defect. Hence CFM/Y.1731 require 
> support of 3.3 msec. I think that support of 3.3 msec by a BFD 
> implementation is a requirement if sub-50 msec protection to be provided in 
> a network. (Note, that actual detection by CFM/Y.1731 and BFD will vary 
> slightly.)
> 
> 	Regards,
> 		Greg
> 
> MPLS-TP was at least driving this requirement. I have to ask my MPLS 
> colleagues if this has been written down explicitly meanwhile.
> 
>