Subject: Re: New draft notification: draft-dz-bfd-extensions-for-vl-packets-00

From: Dave Katz <[email-masked]>
Date: Tue, 2 Mar 2010 16:21:26 -0800

I'll have to examine the proposal carefully, but my first reaction is  
that you can do most of this today without changing the protocol, by  
simply padding the packets in which BFD is carried, without changing  
the BFD header (or the receiving implementation) at all, since the  
spec only requires that the BFD packet fit inside of whatever it is  
being carried within (UDP, typically).  For that matter, the spec  
would allow the BFD packet itself to be padded (since only the lower  
bound of packet length is supposed to be checked) but that would be  
more likely to run afoul of out-of-spec implementations.

It wouldn't be fancy or negotiated, but it would work today without  
changing existing implementations.

A clever implementor might match the packet length of received packets  
in order to drive the extension in both directions, though that scheme  
would be asymmetric (one side has to decide to raise its packet size,  
and the other to reflect it).

The proposal seems like overkill for the purpose, but I'd be  
interested to see what others have to say.

--Dave

On Feb 28, 2010, at 7:46 PM, [email-masked] wrote:

>
> Hi all,
>
> I have submitted a new draft on BFD extensions, the draft's link is: http://tools.ietf.org/id/draft-dz-bfd-extensions-for-vl-packets-00.txt
>
> This document extends BFD mechanism to support detection function  
> for  packets with variable lengths.  Through dynamically changing  
> the length of BFD packets,
> it can detect both traditional faults such as link failure or route  
> fault, as well as non-forwarding problem for packets with a length  
> in a special range,
> which maybe caused by equipment's internal defects.
>
> Any comments and suggestions are welcomed!
>
> Regards
> Dai
>
>
>
> Best Regards.
> ===========================================
> 祝您新春愉快，工作顺利，身体健康，阖家欢乐！

---

From: [email-masked]
Date: Thu, 11 Mar 2010 10:10:40 +0800

Hi Dave,

     Thanks for your quick response, and you are right. But the exsiting 
BFD can't meet our requirements to resolve such non-forwarding problem, 
since BFD's  flexibility is not so good.

so we make some changes in BFD header to support negotiation for 
variable-length detection parameters. Through this negotiation, asymmetric 
condition that you mentioned can be avoided， 

in addition,  we can obtain the length interval during which the fault 
occured more accurately.

Wish further comments from you and all others.

BR.

Xuehui

Best Regards.

Dave Katz <[email-masked]> 
2010-03-03 08:21

收件人
<[email-masked]>
抄送
[email-masked]
主题
Re: New draft notification: draft-dz-bfd-extensions-for-vl-packets-00

I'll have to examine the proposal carefully, but my first reaction is that 
you can do most of this today without changing the protocol, by simply 
padding the packets in which BFD is carried, without changing the BFD 
header (or the receiving implementation) at all, since the spec only 
requires that the BFD packet fit inside of whatever it is being carried 
within (UDP, typically).  For that matter, the spec would allow the BFD 
packet itself to be padded (since only the lower bound of packet length is 
supposed to be checked) but that would be more likely to run afoul of 
out-of-spec implementations.

A clever implementor might match the packet length of received packets in 
order to drive the extension in both directions, though that scheme would 
be asymmetric (one side has to decide to raise its packet size, and the 
other to reflect it).

The proposal seems like overkill for the purpose, but I'd be interested to 
see what others have to say.

--Dave

Hi all, 

I have submitted a new draft on BFD extensions, the draft's link is: 
http://tools.ietf.org/id/draft-dz-bfd-extensions-for-vl-packets-00.txt

This document extends BFD mechanism to support detection function for 
packets with variable lengths.  Through dynamically changing the length of 
BFD packets, 
it can detect both traditional faults such as link failure or route fault, 
as well as non-forwarding problem for packets with a length in a special 
range, 
which maybe caused by equipment's internal defects.

Regards 
Dai 

Best Regards.

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 15 Mar 2010 18:52:32 -0700

Hi Dai,

I have skimmed through the draft but have the following comments:

1. Isn't the padding functionality more a part of CV and not a CC mechanism
like BFD? Though errors could happen at run time, these would generallty be
there at startup time.

2. Having a different version number may be a bit hard to fly. There are
other ways to add padding by overloading the A bit and the auth_field. So
the first bit of the authtype filed could be used to signal padding and
respective data.

This would mean that all older implementations would still work without
change in version number and implementations supporting this requirement
could interoperate.

So the authtype filed could be split into

u_int32_t padding: 1
u_int32_t auth_type:7;
u_int32_t total_len:24;
u_int32_t auth_len:16;
u_char data[];
u_char pad_info;

Thanks,
Vishwas

2010/3/10 <[email-masked]>

>   *Dave Katz <[email-masked]>*
>
> 2010-03-03 08:21
>    收件人
>  <[email-masked]>
>  抄送
> [email-masked]
> 主题
> padding the packets in which BFD is carried, without changing the BFD header
> (or the receiving implementation) at all, since the spec only requires that
> the BFD packet fit inside of whatever it is being carried within (UDP,
> typically).  For that matter, the spec would allow the BFD packet itself to
> be padded (since only the lower bound of packet length is supposed to be
> checked) but that would be more likely to run afoul of out-of-spec
> implementations.
>
> order to drive the extension in both directions, though that scheme would be
> asymmetric (one side has to decide to raise its packet size, and the other
> to reflect it).
>
> On Feb 28, 2010, at 7:46 PM, [email-masked]*<[email-masked]>wrote:
>
>
> Hi all,
>
> I have submitted a new draft on BFD extensions, the draft's link is: *
> http://tools.ietf.org/id/draft-dz-bfd-extensions-for-vl-packets-00.txt*<http://tools.ietf.org/id/draft-dz-bfd-extensions-for-vl-packets-00.txt>
>

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 15 Mar 2010 18:55:16 -0700

Hi Dai,

One more interesting thing is how many packets we need to send for each
type. I think it should depend on the detect multiplier of the neighbor,
otherwise if we send a packet of different size and we have issues at a
particular size the hold timer will not time out and the error will not be
detected.

Thanks,
Vishwas

2010/3/15 Vishwas Manral <[email-masked]>