Subject: [RTG-DIR] RtgDir review: draft-ietf-bfd-on-lags-03

From: <[email-masked]>
Date: Mon, 2 Dec 2013 09:43:55 +0000

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.

---

From: <[email-masked]>
Date: Wed, 11 Dec 2013 17:01:03 +0000

Hi Marc,

2013-12-09, Marc Binderberger:
>
> There is one point which I explicitly do not want to follow: the
> appendix. We moved it's content a while ago from the main text into the
> appendix, realizing that it is more about operational experience from
> existing implementations and not necessary to make the feature running.
> I.e. it represents good practice for
> implementors wanting to make use of this feature but we don't want to
> constrain a particular implementation from doing something more clever.
> It's not intended to be a normative text, neither for the protocol nor
> the operations.
>
> Hope this is okay with you.

I think this point would deserve a bit of discussion.

First of all, let me point out that the appendix is using RFC2119 
language (e.g. "SHOULD NOT"). If in fact the text there is not meant to 
be constraining, then it probably should not use such language.

However, as a contributor working for an operator, I am particularly 
careful about documenting recommended approaches to make a deployment 
smooth. This is very useful and really deserves IMHO to appear in the 
document in a position that gives it a fair chance to be read by 
implementors.

I would encourage you to consider moving the text in the main section of 
the document. Perhaps not as specification text using RFC2119 language, 
but perhaps worded in terms to make it clear that there may be other 
ways to obtain a similar effect but that implementors should take care 
about such issues.

> For the L3 continuity (Mi.3), we kept the changes small, added to say
> "i.e. the ability for each member link to be able to forward L3
> packets." When implementing, this aspect is largely implicit as the BFD
> processing will use layer-3 code. Making more detailed statements or
> requirements is difficult as it is implementation specific.

Why not replace " and would be able to  verify L3 Continuity per member 
link; i.e. the ability for each  member link to be able to forward L3 
packets. " by "and would be able to verify the ability for each
  member link to be able to forward L3 packets".

Said otherwise, what does the term "L3 continuity" bring ?
(I see the drawback that it may bring, given that it's unclear to me 
what "continuity" means when we look at just one IP forwarding hop: BFD 
LAG does not verify the ability of the box to forward one IP packet from 
one interface to another, right ?)

> For the destination IP address (Mi.2) I only mention the two extremes,
> manual configuration and some - unspecified - out-of-band protocol to
> learn the address. For unnumbered links the destination IP in the BFD
> packets would be likely some "loopback" address. The draft words this as
>
>     Control packets use a destination IP address that is configured on
>     the peer system and can be reached via the LAG interface.
>
> FYI, manual configuration of the IP destination address is what the
> existing implementations use today.

Ok. The revised text seems good enough.

>
> For the other comments I followed your advice/suggestions.

I did not find text addressing Mi.1):

( 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. )

The added text does not seem to address the above.

Additionally, I find the following new sentence "scary" (if I may say):

     The	demultiplexing procedure described in this document will
     prevent any	BFD session to go into Up state.

That sounds like BFD will not work at all anymore... ;)

It sounds like there are some words missing, e.g. something like "any 
such unwanted BFD session"...?

Thanks,

-Thomas

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 11 Dec 2013 13:38:25 -0500

> be constraining, then it probably should not use such language.

Removing the 2119 capitalization is certainly easy to do.

> document in a position that gives it a fair chance to be read by 

Speaking as an implementor, if it's in the document, I read it as part of my
work.

> ways to obtain a similar effect but that implementors should take care 

The difficulty here is that the primary purpose of the draft is to describe
protocol operations.  The purpose of the appendix is to offer advice to
implementors of the feature for graceful integration of the feature.
However, that advice is not normative to the operation of the protocol.

Having worked as an implementor across a number of companies over the years,
I am extremely paranoid about placing such operational advice in the context
of a specification.  Doing such things tends to get interop labs/testsuites
pedantically testing the behavior and saying "you're not compliant", even if
the reason for the variance in the operational behavior is internally
justified.  

The other half of this is that if someone does some behavior that is
*better* than that covered in the document they may become non-compliant,
while the on-the-wire protocol is not impacted.

I would rather delete the appendix than make it take on the air of something
that is a normative portion of the protocol.  We were trying to be nice by
offering implementation wisdom rather than making the next implementor run
into the same issues we did in our implementations.

> one interface to another, right ?)

I suspect this language was influenced by the VCCV feature and the language
that was pushed upon BFD for that purpose.

I don't have a strong feeling about keeping "L3 continuity" and would be
fine accepting your text.  

Perhaps the other authors have some memory of why we went with that
particular terminology.

> That sounds like BFD will not work at all anymore... ;)

I tend to agree.  I didn't have better text to offer, but the implication
really is that the two instantiations of the BFD feature (BFD for IP/5881
and BFD over LAG) are really "ships in the night" features.  If an
implementation was somehow able to configure BFD port numbers such that the
features were crossed... things would fail in rather peculiar ways.

We do not have similar documentation covering other applications of BFD
where specific bootstrapping scenarios are required (e.g. VCCV).  I'm not
sure it's applicable here either.  In particular, a standard BFD session
misconfigured to use BFD over LAG *might* be able to bootstrap a single
link if it wasn't using the multicast discovery and the given implementation
of IP on the line card was able to progress BFD packet processing with
semi-resolved ARP addresses.  But as you see, there's a significant number
of "the following things would have to also be true".

> such unwanted BFD session"...?

Honestly, I would prefer to drop this last sentence.  The prior words seem
strong enough:
   The new UDP port removes the ambiguity of BFD over LAG packets from
   BFD over single-hop IP.  An example is configuring a LAG with micro
   BFD sessions on one side but using a [RFC5881] BFD session for the
   LAG (treated as a single interface) on the opposite side.  

What your comment was asking was "describe what happens if you misconfigure
the port numbers".  See my comments about about the number of additional
variables that may be present in the implementation.

-- Jeff

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 11 Dec 2013 14:25:17 -0800

Hello Thomas and Jeff,

I will remove the capitalization from the Appendix to avoid any 
impression this is normative. It's some practical experience we made, 
offered for free. Not a fit-for-all, it is influenced by some specific 
network operation procedures.

Can live with replacing "L3 continuity" with what Thomas proposes.

Mi.1 was addressed, at least from my view as an implementor. To some 
extend I dis-improved as the last sentence should have started with 

   For this example [The
   demultiplexing procedure described in this document will prevent any
   BFD session to go into Up state.]

But I'm also fine we avoid confusion and remove the sentence. The fact 
that the UDP port needs to be considered as part of the demultiplexing 
(for discriminator zero) is actually enough for a proper implementation.

> If an

True but this would not follow the RFC5881 standard when the UDP port 
is e.g. configurable. Our text ensures the ships in the night behaviour 
within the RFC standards for BFD.  I brought up this example as it is a 
true scenario (either by mistake or during reconfiguration) and a 
reason for introducing a new port. And it covered a "negative case" as 
proposed by Thomas :-)

Will update the document in parallel while the emails come in ... .

Regards, Marc

---

From: <[email-masked]>
Date: Thu, 12 Dec 2013 08:55:18 +0000

Hello Marc,

> network operation procedures.

Agreed. It's true that this part does not need to be normative.

However, oo give proper visibility to this section, I would suggest 
mentioning its existence in the introduction, with for instance the 
following text:

    Appendix A provides a description of how to implement these specs in
    a way that can help introduce BFD LAG in a running network and, in
    particular, ensure that the sequence of events - enabling/disabling
    the LAG and enabling/disabling BFD on the LAG - has no impact on the
    forwarding service. Although this text is non normative, it is
    recommended that an implementation addresses this type of issues.

> Can live with replacing "L3 continuity" with what Thomas proposes.

Ok.

>     BFD session to go into Up state.]

This new text is good.

(More in a reply to Jeff's email.)

Thanks,

-Thomas

---

From: <[email-masked]>
Date: Thu, 12 Dec 2013 09:07:08 +0000

Hi Jeff,

> Speaking as an implementor, if it's in the document, I read it as part of my

Your are certainly an example that implementor should follow.
Speaking as an operator, I find very often that text gets ignored even 
if in the main normative part of the document.  And I can easily guess 
that many people just don't read beyond the Acknowledgements section.

> into the same issues we did in our implementations.

Understood, and agreed.

> the port numbers".

(I wasn't asking this in fact -- I wasn't clear in what I asked)

> See my comments about about the number of additional

I understand your answer and Marc's.

Let me explain why in my views may comment was not yet addressed. I 
meant "explain what happens" as "explain that an implementation should 
be so that you cannot have 'streams crossing' between plain BFD and a 
micro BFD session", ie. qhat I had in mind was that the text 
could/should make it explicit that the procedures for plain-BFD must not 
be applied for session on the micro BFD port, and vice-versa.

You are correct that the above text, with the UDP port as the 
discriminator, achieves the same purpose implicitly, but if negative 
side effects are feared, then making it fully explicit with "MUST NOT"s 
would be a good way to insist on it.

Thanks,

-Thomas

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 13 Dec 2013 15:30:47 +0000

Thomas,

Stepping back for a second ‹ and hence top-posting ‹ one question: if the
micro BFD session uses a different UDP port (6784) from the ³regular²
(3784) BFD session, what is exactly the fear with Œstreams crossing¹?

Is the same concern of BFD single-hop and BFD multi hop (4784) Œstreams
crossing¹?

Thanks,

‹ Carlos.

On 12/12/13, 4:07 AM, "[email-masked]" <[email-masked]>
wrote:

>__________________________________________________________________________
>_______________________________________________
>
>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,
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;

---

From: <[email-masked]>
Date: Fri, 13 Dec 2013 16:43:30 +0000

Hi Carlos,

Given the precision added in paragraph 3 of section 2.2 in -04-beta, I 
don't see risks if people actually follow the specs. However there may 
be a risk if implementors miss out this particularly important part, 
hence my suggestion that insisting on it will be an improvement to the text.

So let me reduce my comment to a simple suggestion of text to add (eg. 
after the text explaining the use of a distinct UDP port):

   The procedures in this document MUST be used for BFD messages
   addressed to port 6784 and MUST NOT be used for others ports
   assigned in RFCs described other BFD modes.

Thank you,

-Thomas

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 13 Dec 2013 11:45:41 -0500

Thomas,

>    assigned in RFCs described other BFD modes.

Which precludes the procedures from being used at some point in the future
by a spec based on this one.  Perhaps BFD for LAGs over switched ports. :-)

-- Jeff

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 13 Dec 2013 22:39:58 -0000

Jeff,

(What a lot of recipients! Welcome to our spamfest.) 

Saying "MUST NOT" in this document does not preclude future documents describing
new applications. It precludes new applications without documentation.

That is, a new document can update this one to change the "MUST NOT" under
specific conditions.

What *this* document does is describe the behavior of implementations of *this*
document.

I think that put the answer somewhere between you and Thomas. This document
cannot influence what implementations of something else do (although it can give
advice and dire warnings). What it can do is be very clear about what
implementations of this document do.

A

> -----Original Message-----
> From: rtg-dir [mailto:[email-masked]] On Behalf Of Jeffrey Haas
> Sent: 13 December 2013 16:46
> To: [email-masked]
> Cc: Carlos Pignataro (cpignata); Bhatia, Manav (Manav); [email-masked]; Marc
> Binderberger; Mach Chen; Sami Boutros (sboutros); [email-masked];
> Nobo Akiya (nobo); [email-masked]; Jeffrey Haas; Henderickx, Wim
> (Wim); Marc Binderberger (mbinderb); [email-masked]
> Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-bfd-on-lags-03
> 
> Thomas,
>