RtgDir review: draft-ietf-bfd-on-lags-03

[<[e-mail]>]

Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review, and 
sometimes on special request. The purpose of the review is to provide 
assistance to the Routing ADs. For more information about the Routing 
Directorate, please seehttp://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-ietf-bfd-on-lags-03
Reviewer: Thomas Morin
Review Date: December 1st, 2013
IETF LC End Date: December 2nd, 2013
Intended Status: Proposed Standard

Summary:

   The document is concise, well written, and raises no major issue.
   However, bringing clarifications to a few areas should be considered 
prior to publication.

Major Issues:

   None.


Minor Issues:

- Mi.1) The document mentions the use of a specific UDP port for the 
micro-BFD sessions (6784). It should probably explain what is the 
behavior if BFD messages from a micro-BFD sessions are received on the 
normal BFD port (3784), and vice-versa what is the behavior for BFD 
messages from a non-BFD sessions is received on the micro-BFD UDP port.

- Mi.2) The document indicates in section 2.2 that "The details of how 
[the destination IP address of the BFD peer] is learned are outside the 
scope of this document.".  First, an example of a common practice would 
be great to provide an illustration.  Second, I would find it worth 
documenting how this can be done in practice on an unnumbered link

- Mi.3) The notion of "L3 continuity" is used in the introduction, but 
it is not explained what this means; it would deserve being explained as 
the idea of "continuity" may not be obvious to interpret in a contect 
where a single L3 hop is being tested.

- Mi.4) Section 4 mentions "LMM" and "some Interface management module" 
without providing any definition nor explaining the role of such modules.

- Mi.5) The behavior described in the Appendix looks very important for 
smooth activation of the feature in a real network and is actually 
specification text. I'm thus surprised to find it in an Appendix -- 
where it could be missed by implementors.  I would suggest considering 
moving this text among the rest of technical specifications sections.


** Editorial comments:

- Ed.1) I would suggest removing the mention of the use of a specific 
UDP port from the Abstract, which would then be more concise -- the 
motivation for using a specific UDP port so could be provided in section 
2.2.

- Ed.2) Section 2.3: "For the following BFD packets with Up state the 
MAC address from the received BFD packets for the session MAY be used 
instead of the dedicated MAC. "

    => "the _source_ MAC address from the received BFD packets" ? 
(adding "source" would remove any risk of ambiguous interpretation)

- Ed.3) Section 5: "MAY remove the member link from the load balance 
table only that matches the address family of the failing BFD session"

   I had issues parsing this sentence; what about: "MAY remove the 
member link from only the load balance table that matches..."

   Furthermore, it would be nice to add a colon at the end of the 
sentence to indicate that what follows is an illustration of what precedes.

   Last, I think it would be worth indicating explicitly that "The 
member link MAY also be removed from both the L4 and L6 load balancing 
table".

- Ed.4) I believe you need to update contact information for Nitin Bahadur.



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.