Subject: AD Review of draft-ietf-bfd-seamless-ip

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 25 Sep 2015 16:49:35 +0000

Hi!

This is a nice and short document.  In fact it is so short that I wonder why it isn’t just part of draft-ietf-bfd-seamless-base.  Besides indicating specific addresses/port numbers to use, there is no significant transport-protocol-specific contribution beyond what is already in the base document.

Please consider merging this document into draft-ietf-bfd-seamless-base.  I will keep this document in AD Evaluation (and not return it to the WG) at least until a decision has been made.

Thanks!

Alvaro.

Major:

  1.  Nowhere in this document (or draft-ietf-bfd-seamless-base) is congestion mentioned.  There is very little in rfc5881 (and nothing in rfc5884) that adds to what rfc5880 covers, which makes me think that a generic approach might be better (i.e. in  draft-ietf-bfd-seamless-base).  Are there new congestion-related transport-protocol-specific considerations that arise when using S-BFD?  Please include some text indicating any congestion issues — or at least explaining why there aren’t any new ones.

Minor:

  1.  Section 4. (S-BFD Control Packet Demultiplexing).  The process described here doesn’t match what is specified in Section 7.1. (Demultiplexing of S-BFD Control Packet) of draft-ietf-bfd-seamless-base.
  2.  I think that Section 5.2. (Target vs. Remote Entity (S-BFD Discriminator)) needs to be clarified.
     *   “…to perform a continuity test towards a target but to a transit network node.”  I think there might be a “not” left out somewhere, maybe you meant “…to not perform a continuity test towards a remote entity but to a transit network node”. ??
     *   What is the "TTL expiry exception path”?  Is that an implementation-specific construct?
     *   “…MUST allow received S-BFD control…”  This is a change from rfc5880, so we should mark this document as updating it.
  3.  Section 6.1. (Details of S-BFD Control Packet Sent by SBFDReflector)
     *   "Source IP address…MUST be set to a local IP address…”  Any address?  Why isn’t this copied from the received packet?
     *   "TTL field of the IP header SHOULD be set to 255.”  From Section 5.2 I understand why “SHOULD” is used for the Initiator, but why is this not a “MUST” for the SBFDReflector?

Nits:

  1.  Missing references
     *   Introduction: "The reader is expected to be familiar with the IP, MPLS BFD and S-BFD terminologies and protocol constructs.”
     *   Security Considerations: "Martian addresses"
  2.  Section 2. (S-BFD UDP Port)
     *   s/can be of any/can be any
     *   "The source port number MAY be unique among all SBFDInitiator sessions on the system.”  I don’t think we need the “MAY” there.
  3.  Section 5.1. (Details of S-BFD Control Packet Sent by SBFDInitiator)
     *   s/UDP source port MUST be set to a value that is not 7784/UDP source port MUST NOT be set to 7784
     *   "The destination IP address MUST be chosen from…”  Please add a reference to where the blocks came from.
  4.  Section 5.2. (Target vs. Remote Entity (S-BFD Discriminator)) may be better off as 5.1.1.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 27 Sep 2015 20:54:31 +0000

Hi, Alvaro,

> On Sep 25, 2015, at 12:49 PM, Alvaro Retana (aretana) <[email-masked]> wrote:
> 
> Please consider merging this document into draft-ietf-bfd-seamless-base.

Where have I heard this before? :-)

In addition to my perspective on your review of the -base document, one additional datapoint: there is useful symmetry pf S-BFD with the existing set of BFD documents. You might have noticed how you were referencing only RFC 5880 about -base. That is a clean demarc.

draft-ietf-bfd-seamless-ip is *exactly* as long and detailed as RFC 5881.

> I will keep this document in AD Evaluation (and not return it to the WG) at least until a decision has been made.
> 

Sounds good — please let us know what’s next about this to reach that decision.
> Nowhere in this document (or draft-ietf-bfd-seamless-base) is congestion mentioned.  There is very little in rfc5881 (and nothing in rfc5884) that adds to what rfc5880 covers, which makes me think that a generic approach might be better (i.e. in  draft-ietf-bfd-seamless-base).
I think there are and agree with you, a generic approach (-base) would be better.

Thanks,

— Carlos.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Sun, 27 Sep 2015 23:16:49 +0000

On 9/27/15, 4:54 PM, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>> wrote:

Carlos:

Hi!

That is a WG decision, so I expect the Chairs to let me know when they think consensus has been reached.

Note that I don’t expect a formal consensus call or a new WGLC (based on a potential merge) — unless the Chairs think it is needed.  Given that the documents already have WG consensus, I would expect my suggestion to be resolved quickly.

BTW, I read your justification for not merging in the thread about draft-ietf-bfd-seamless-base.  Thanks for that!

Alvaro.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 28 Sep 2015 00:33:48 +0000

Alvaro,

Thanks again — Closing the loop, please see inline.

> On Sep 27, 2015, at 7:16 PM, Alvaro Retana (aretana) <[email-masked]> wrote:
> 
> On 9/27/15, 4:54 PM, "Carlos Pignataro (cpignata)" <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Carlos:
> 
> Hi!

I would assume that, since both documents were adopted simultaneously, WG consensus was that two documents (and not a merged one) is what made sense. We can see if there is any WG indication otherwise.

Jeff?

> BTW, I read your justification for not merging in the thread about draft-ietf-bfd-seamless-base.  Thanks for that!

Thank you for reading it!

— Carlos.

---

From: Marc Binderberger <[email-masked]>
Date: Sun, 27 Sep 2015 19:13:11 -0700

Hello everyone,

not a chair of the VFD WG but I remember we made the conscious decision to 
_split_ the fundamentals/principles ("base") from some nitty-gritty details 
like the transport mechanism.

> I would assume that, since both documents were adopted simultaneously, WG 
> consensus was that two documents (and not a merged one) is what made sense. 

I agree on this view.

Regards, Marc

On Mon, 28 Sep 2015 00:33:48 +0000, Carlos Pignataro (cpignata) wrote:
> Alvaro,
> 
> Thanks again ― Closing the loop, please see inline.
> 
>> On 9/27/15, 4:54 PM, "Carlos Pignataro (cpignata)" <[email-masked]> 
>> wrote:
>> 
>> Carlos:
>> 
>> Hi!
>>> Sounds good ― please let us know what’s next about this to reach that 
>>> decision.
>> 
> I would assume that, since both documents were adopted simultaneously, WG 
> consensus was that two documents (and not a merged one) is what made sense. 
> We can see if there is any WG indication otherwise.
> 
> Jeff?
> 
>> 
>> Note that I don’t expect a formal consensus call or a new WGLC (based on 
>> a potential merge) ― unless the Chairs think it is needed.  Given that 
>> the documents already have WG consensus, I would expect my suggestion to 
>> be resolved quickly.  
>> 
>> BTW, I read your justification for not merging in the thread about 
>> draft-ietf-bfd-seamless-base.  Thanks for that!
> 
> ― Carlos.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 29 Sep 2015 11:36:11 -0400

[wearing my WG chair hat]

> > consensus was that two documents (and not a merged one) is what made sense. 

This was the WG consensus.  This consensus covered:
- A similar split of core/base functionality for BFD in RFC 5880 vs.
  individual transport mappings with their own quirks.
- Putting the -IP case in the -base document tends to imply that you MUST
  implement the -ip feature if you're doing S-BFD.  Sure, you might not need
  to, but I suspect a number of us have been at the wrong end of RFPs which
  ask about "compliance with RFC XXXX".

We should leave this split.  We're not exactly concerned with running out of
RFC numbers. :-)

-- Jeff

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 29 Sep 2015 16:01:42 +0000

On 9/29/15, 10:36 AM, "Jeffrey Haas" <[email-masked]> wrote:

Hi!

>...
>We should leave this split.

That¹s fine.  As I said in the review, all I wanted was for the WG to
consider it.

Thanks!

Alvaro.