Hi Reshad,

thank you for the great suggestion. Below is the proposed update to section 
4.3.1 New State Variables:


OLD TEXT

       This variable is only pertinent when bfd.SessionType is

       MultipointTail.

NEW TEXT

        This variable is only pertinent when bfd.SessionType is

         MultipointTail and SHOULD NOT be modified after the

         MultipointTail session has been created.













Greg Mirsky






Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D 
Institute/Wireline Product Operation Division









E: gregory.mir...@ztetx.com 
www.zte.com.cn






Original Mail



Sender: ReshadRahman(rrahman) <rrah...@cisco.com>
To: gregory mirsky10211915;rtg-bfd@ietf.org <rtg-bfd@ietf.org>
CC: gregimir...@gmail.com <gregimir...@gmail.com>
Date: 2018/02/08 11:22
Subject: Re: WGLC for BFD Multipoint documents (last round)




Hi Greg,


 


Regarding changing bfd.SilentTail on the fly, I think we should consider adding 
some text “… SHOULD not be modified after the MultipointTail session has been 
created.“. This is to prevent  false failure detections as you mentioned.


 


Regards,


Reshad.


 



From: "gregory.mir...@ztetx.com" <gregory.mir...@ztetx.com>
 Date: Sunday, February 4, 2018 at 8:18 PM
 To: "Reshad Rahman (rrahman)" <rrah...@cisco.com>, "rtg-bfd@ietf.org" 
<rtg-bfd@ietf.org>
 Cc: "gregimir...@gmail.com" <gregimir...@gmail.com>
 Subject: Re: WGLC for BFD Multipoint documents (last round)



 

Hi Reshad,

<have to switch my contact for a week>

You've said:

Hi Greg,   The question about whether we need a new variable wasn’t referring 
to MultipointClient state (I agree this is well explained). Since I mentioned 
“state variable” I realize the confusion…   The question was whether we need a 
new state variable (not for the MultipointClient state) to control the behavior 
explained in this paragraph, e.g the new state variable could be called 
bfd.TrackTails.      If the head wishes to know the identity of the tails, it 
sends    multipoint Polls as needed.  Previously known tails that don't    
respond to the Polls will be detected.   Regards, Reshad. I agree that an 
operator should have control over whether the head does tail discovery, tail 
monitoring. But I think that that may require whole suite  of parameters and 
some might need coordidation for the MultipointHead with MultipointTail, e.g. 
when the given MultipointTail has bfd.SilentTail changed from 0 to 1 or vice 
versa. Would that trigger false negative on the head? I think that there's lots 
of  open space ofr the innovation in the area of monitoring p2mp tails. I hope 
that someone will be interested to continue and produce more detailed 
specification than draft-ietf-bfd-multipoint-active-tail. For example, time 
interval between multicast Poll and  relationship to unicast BFD control 
packets to tail(s).

 

Best regards,


Greg Mirsky


 


Sr. Standardization Expert
 预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D 
Institute/Wireline Product Operation Division


 






 E: gregory.mir...@ztetx.com 
 www.zte.com.cn

Reply via email to