Subject: I-D Action: draft-ietf-bfd-seamless-base-02.txt

From: [email-masked]
Date: Fri, 01 Aug 2014 16:40:41 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF.

        Title           : Seamless Bidirectional Forwarding Detection (S-BFD)
        Authors         : Nobo Akiya
                          Carlos Pignataro
                          Dave Ward
                          Manav Bhatia
                          Juniper Networks
	Filename        : draft-ietf-bfd-seamless-base-02.txt
	Pages           : 18
	Date            : 2014-08-01

Abstract:
   This document defines a simplified mechanism to use Bidirectional
   Forwarding Detection (BFD) with large portions of negotiation aspects
   eliminated, thus providing benefits such as quick provisioning as
   well as improved control and flexibility to network nodes initiating
   the path monitoring.

   This document updates RFC5880.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-bfd-seamless-base-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-seamless-base-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 20 Aug 2014 17:49:58 -0700

Hello BFD experts,

thanks for the restructuring of the document. The downside of the document 
improvement is that certain aspects become more prominent now and I would 
like to comment these ;-)

C1: What came to my mind is how much is written about the Discriminator 
pools. As an implementation proposal it's a great read but from a protocol 
perspective I think we don't need this. What actually stays as a hard 
requirement is

(1) S-BFD Discriminator Uniqueness as you want to detect to end up on the 
wrong target.

(2) the receiver must know from the lower-layer (e.g. UDP port) that the 
packet is a S-BFD packet.

If another pool is used and what it is used for should be left to the 
implementor. E.g. if the my_discr on the Initiator side comes from the 
"normal" pool or from the S-BFD pool - well, using the S-BFD pool for both 
would make sense to avoid any interference with an existing BFD 
implementation. Point (2) above allows the implementor to know if the packet 
is related to S-BFD. Otherwise the Initiator discriminator has a local 
meaning only.

Long story short, section 4.1 IMHO should be a note to the implementor, that 
collisions are a topic not faced before and a new pool may help; the protocol 
is designed to provide the information from the lower layer, if needed.

C2: section 6.1.  New State Variables: the variable bfd.SessionType can have 
only two values, Initiator and Reflector. As an implementor I would take the 
liberty to add a state "not-SBFD" as you add this state variable to the base 
specification ... nitpick, I agree :-)

C3: the demand bit. The logic you describe is to avoid a loop attack. I 
wonder if this can be replaced or at least be reduced as we don't use the 
same UDP port anymore on Initiator and Reflector ?
Open question, I think I stumbled over section 7.7 "If the SBFDInitiator 
receives an S-BFD packet with Demand (D) bit set, the packet MUST be 
discarded.", which doesn't make much sense to me anymore.

Regards, Marc

On Fri, 01 Aug 2014 16:40:41 -0700, [email-masked] wrote:
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: "MALLIK MUDIGONDA (mmudigon)" <[email-masked]>
Date: Thu, 21 Aug 2014 05:37:13 +0000

Hi Marc,

Please find my response inline

Thanks

Regards
Mallik

From: Marc Binderberger <[email-masked]<mailto:[email-masked]>>
Date: Thursday 21 August 2014 6:19 AM
To: "Nobo Akiya (nobo)" <[email-masked]<mailto:[email-masked]>>, Manav Bhatia <[email-masked]<mailto:[email-masked]>>, Santosh P K <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: I-D Action: draft-ietf-bfd-seamless-base-02.txt

Hello BFD experts,

Mallik>> You are suggesting that based on the Source or Destination UDP port which can be well known UDP port, we can decide whether a packet can be reflected. E.g., If Source UDP is a well known port, then the packet is coming from reflector and should not be reflected back.
I agree. If there is some way of identifying this case then it should be ok. Anyway we can wait for others to comment on this.

Regards, Marc

On Fri, 01 Aug 2014 16:40:41 -0700, [email-masked]<mailto:[email-masked]> wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
  This draft is a work item of the Bidirectional Forwarding Detection
Working Group of the IETF.
         Title           : Seamless Bidirectional Forwarding Detection
(S-BFD)
         Authors         : Nobo Akiya
                           Carlos Pignataro
                           Dave Ward
                           Manav Bhatia
                           Juniper Networks
Filename        : draft-ietf-bfd-seamless-base-02.txt
Pages           : 18
Date            : 2014-08-01
Abstract:
    This document defines a simplified mechanism to use Bidirectional
    Forwarding Detection (BFD) with large portions of negotiation aspects
    eliminated, thus providing benefits such as quick provisioning as
    well as improved control and flexibility to network nodes initiating
    the path monitoring.
    This document updates RFC5880.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-bfd-seamless-base-02
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-seamless-base-02
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
I-D-Announce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 22 Aug 2014 21:51:10 +0000

Hi Marc, Mallik, et al,

Please see in-line for [NOBO].

> -----Original Message-----
> From: MALLIK MUDIGONDA (mmudigon)
> Sent: Thursday, August 21, 2014 1:37 AM
> To: Marc Binderberger; Nobo Akiya (nobo); Manav Bhatia; Santosh P K
> Cc: [email-masked]
> From: Marc Binderberger <[email-masked]>
> To: "Nobo Akiya (nobo)" <[email-masked]>, Manav Bhatia
> <[email-masked]>, Santosh P K <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>

I see your point, but do also note that the entire Section 4 grew over time as more and more clarifications were requested. So I think it's worth preserving most of the texts in this section. With that said, I do have an idea on how we can address your concern.

Section 4.2 will be moved before section 4.1, and pre-text will be added in the "Discriminator Pools" section.

New Section 4 will look like:

---- snip ----
4.  S-BFD Discriminators

4.1.  S-BFD Discriminator Uniqueness

   <keep current texts>

4.2.  Discriminator Pools

   This subsection describes a discriminator pool implementation
   technique to minimize S-BFD discriminator collisions.  The result
   will allow an implementation to better satisfy the S-BFD
   discriminator uniqueness requirement defined in Section 4.1.

   o  SBFDInitiator is to allocate a discriminator from the BFD
      discriminator pool.  If the system also supports classical BFD
      that runs on [RFC5880], then the BFD discriminator pool SHOULD be
      shared by SBFDInitiator sessions and classical BFD sessions.

   <rest will be existing texts>
---- snip ----

What do you think?

> specification ... nitpick, I agree :-)

Ah yes, that should be clarified. We will change the text to:

   o  bfd.SessionType: This is a variable introduced by
      [I-D.ietf-bfd-multipoint] and describes the type of this session.
      Allowable values for S-BFD sessions are:

> Mallik>> You are suggesting that based on the Source or Destination UDP
> port which can be well known UDP port, we can decide whether a packet
> can be reflected. E.g., If Source UDP is a well known port, then the packet is
> coming from reflector and should not be reflected back.
> I agree. If there is some way of identifying this case then it should be ok.
> Anyway we can wait for others to comment on this.

I think it is ok (or I would even go to the extent of saying it is desirable) to keep the (D)emand based loop prevention. This way:
- We have a loop prevention in the base.
- Data plane procedures can have an additional loop prevention if possible (which is the case for IP based S-BFD with UDP ports as you indicated).

Thanks!

-Nobo