Greg, this is good.
Regards,
Reshad.
From: "gregory.mir...@ztetx.com" <gregory.mir...@ztetx.com>
Date: Wednesday, February 7, 2018 at 11:58 PM
To: "Reshad Rahman (rrahman)" <rrah...@cisco.com>
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "gregimir...@gmail.com"
<gregimir...@gmail.com>
Subject: Re: WGLC for BFD Multipoint documents (last round)
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
[cid:9ae3e214c17d49ed935d87c674ba3ee2]
[cid:24242e5637af428891c4db731e7765ad]
E: gregory.mir...@ztetx.com<mailto:gregory.mir...@ztetx.com>
www.zte.com.cn<http://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
[cid:9ae3e214c17d49ed935d87c674ba3ee2]
[cid:24242e5637af428891c4db731e7765ad]
E: gregory.mir...@ztetx.com<mailto:gregory.mir...@ztetx.com>
www.zte.com.cn<http://www.zte.com.cn/>
