Hi Martin,
I have not ignored that comment but missed to ack its acceptance. Two
other outstanding questions:
* the text, that I've misinterpreted earlier, is in the Overview
section:
Although this document describes a single head and a
set of tails
spanned by a single multipoint path, the protocol is
capable of
supporting (and discriminating between) more than one
multipoint
path
at both heads and tails.
There is no text to describe how one could achieve that.
Wouldn't it
be worth adding some?
GIM>> The question of applicability of this specification to
mp2mp scenario came up at BIER WG meeting in London. Perhaps we
can say the these questions are ouside the scope of this
document and discuss whether there are interested to work on
mp2mp case as a separete document?
I don't read this part of the document as talking about mp2mp but
rather as talking about multiple p2mp trees.
Sections 4.7 and 4.13.2 provides details on demultiplexing BFD
control packets at a MultipointTail. Would the reference to these
sections be sufficient?
* yes, moved the reference to Point-to-Point session to section 4.4.1
Attached please find the diff between -14 and the working version of the
draft. Please let me know if the changes address your comments. Will upload
the new version promptly.
Regards,
Greg
On Tue, Apr 17, 2018 at 9:49 AM, Martin Vigoureux
<[email protected] <mailto:[email protected]>> wrote:
Greg,
thanks. please see in-line.
once I see the update published I will request IETF LC.
-m
Le 2018-04-17 à 18:34, Greg Mirsky a écrit :
Hi Martin,
thank you for your thorough review, thoughtful comments and kind
words.
Please find my answers to your questions in-line and tagged GIM>>.
Regards,
Greg
On Tue, Apr 17, 2018 at 8:06 AM, Martin Vigoureux
<[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> wrote:
[resend, wrong bfd wg address in first attempt ...]
Authors, WG,
thank you for this document. It is clear and well written.
I didn't find any technical comment to make so I've been
nit picking :-)
Please find those comments below.
regards,
martin
---
Please check and address the nits:
https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-bfd-multipoint-14.txt
<https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-bfd-multipoint-14.txt>
<https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-bfd-multipoint-14.txt
<https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-bfd-multipoint-14.txt>>
On that aspect, does this document really update 7880 as
the header
says? The Introduction only refers to 5880 and it is not
clear in
the body of the Document what effectively impacts 7880. The
only
thing I saw is the addition of new session types but that
does not
require an update in my opinion. Could you clarify?
GIM>> Yes, you'correct, the only connection to RFC 7880 are
the new
values of bfd.sessionType. The proposal to list RFC 7880 as
updated
by this specification was inteded to address Errata to RFC
7880
<https://www.rfc-editor.org/errata_search.php?rfc=7880
<https://www.rfc-editor.org/errata_search.php?rfc=7880>>.
I am not sure how this document relates to or addresses the errata.
So I still think it does not update 7880.
i.e. existence of a path between the sender and the
receiver.
do you mean "forwarding path"?
GIM>> Yes. Updated to
i.e. existence of a forwarding path between the sender and
the receiver
thx
Section 2. and Section 3. seem a bit redundant. They both
state the
same thing but from a different angle. Not critical.
Although this document describes a single head and a
set of tails
spanned by a single multipoint path, the protocol is
capable of
supporting (and discriminating between) more than one
multipoint
path
at both heads and tails.
There is no text to describe how one could achieve that.
Wouldn't it
be worth adding some?
GIM>> The question of applicability of this specification to
mp2mp scenario came up at BIER WG meeting in London. Perhaps we
can say the these questions are ouside the scope of this
document and discuss whether there are interested to work on
mp2mp case as a separete document?
I don't read this part of the document as talking about mp2mp but
rather as talking about multiple p2mp trees.
Point-to-point sessions, as described in [RFC5880], are
of type
PointToPoint.
Does this really fit in Section 4.2 which looks to be about
the
mpBFD session model.
GIM>> I think that this short reminder is helpful to explain why
this document adds value PointToPoint, section 4.4.1, to the
defined in RFC 7880 bfd.sessionType variable.
Well, I would move the text to 4.4.1 then, but not critical.
Sessions of type MultipointHead MUST NOT send BFD
control packets
with the State field being set to INIT, and MUST be
ignored on
receipt.
English is not my native language but I wonder if this
really says
what you want. It seems that "Sessions" is the subject of
"MUST be
ignored" while I think it's the packets which are the
intended
subject. So I'd write:
and those packets MUST be ignored on receipt.
You chose to ignore that one or simply missed it?
Because there is no three-way handshake in Multipoint
BFD, a newly
started head (that does not have any previous state
information
available) SHOULD start with bfd.SessionState set to
Down and with
bfd.RequiredMinRxInterval set to zero in the
MultipointHead session.
To shut down a multipoint session a head MUST
administratively set
bfd.SessionState in the MultipointHead session to
either Down or
AdminDown and SHOULD set bfd.RequiredMinRxInterval to
zero. The
In both these paragraphs one could read that the head
"SHOULD set
bfd.RequiredMinRxInterval to zero" while 4.4.2 says MUST.
Clarification needed?
GIM>> Section 4.4.2 mandates initialization of
bfd.RequiredMinRxInterval and, I think, applies to the first
paragraph you've pointed. Would the following be clear and
consistent:
Because there is no three-way handshake in Multipoint BFD,
a newly
started head (that does not have any previous state
information
available) SHOULD start with bfd.SessionState set to Down and
bfd.RequiredMinRxInterval _MUST be_ set to zero in the
MultipointHead session.
The second paragraph describes manipulation with the value of
bfd.RequiredMinRxInterval which process, as noted in section
4.10, "is outside the scope of this document". That may be
reason to use SHOULD and not MUST.
Yes, i'd live with that. But then you might also want to clarify in
4.4.2. <http://4.4.2.>:
OLD:
This variable MUST be set to 0 for session type
MultipointHead.
NEW:
This variable MUST be initialized to 0 for session type
MultipointHead.
s/M, P bit/M and P bits/
GIM>> Thanks, done.
---
