Subject: Re: I-D Action: draft-akiya-bfd-seamless-ip-04.txt

From: Marc Binderberger <[email-masked]>
Date: Tue, 12 Aug 2014 22:55:51 -0700

Hello Nobo and BFD experts,

looking at your latest version of S-BFD IP - btw, thanks for splitting off 
the IP/MPLS specifics from the base draft into this draft! - I have a few 
comments and questions:

(1) you mention several times "local IP address" in the draft. Is this enough 
for IPv6 to be clear regarding routable vs. link-local addresses?  Or do you 
want to allow link-local addresses at all? (most S-BFD is likely multihop?)

(2) the UDP destination port for packets from the Reflector to the Initiator 
... your draft defines this port to be the copied value of the UDP source 
port from the Initiator-to-Reflector packet and forces the port to be in the 
range [49152, 65535]. I hesitate to see this port range as suitable for a 
relevant service. It's typically "open" for traceroute, DNS replies and such, 
which means is can be "wide open" with respect to the source IP of incoming 
packets.

If you don't want to define a specific UDP port to receive S-BFD packets on 
the Initiator then maybe allowing any source port (except from other 
well-known BFD ports :-) for outgoing Initiator-to-Reflector packets would 
help the network administrator to write access lists better tailored for 
S-BFD.

(3) In section 7 security considerations you write

      Implementations MUST ensure that response S-BFD packets generated
      to the initiator by the SBFDReflector have a reachable target (ex:
      destination IP address).

What does this mean? :-)
Seriously, how shall the Reflector know if the destination IP is reachable?  
Routing table is enough?  (even a default route? ;-)

(4) New UDP port for S-BFD echo. Sure, can be done but why not simply using 
3785/udp for this?  I fail to see what is the difference between S-BFD echo 
and an ordinary echo, considering that both leave many details to the 
implementor.

(5) Nitpicks in the References: bfd-seamless-base is meanwhile version 02. 
And the author list "Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J. 
Networks" has somehow dropped P.K. Santosh ;-)

Regards, Marc

On Fri, 01 Aug 2014 16:41:53 -0700, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
>         Title           : Seamless Bidirectional Forwarding Detection 
> (S-BFD) for IPv4, IPv6 and MPLS
>         Authors         : Nobo Akiya
>                           Carlos Pignataro
>                           Dave Ward
> 	Filename        : draft-akiya-bfd-seamless-ip-04.txt
> 	Pages           : 7
> 	Date            : 2014-08-01
> 
> Abstract:
>    This document defines procedures to use Seamless Bidirectional
>    Forwarding Detection (S-BFD) for IPv4, IPv6 and MPLS environments.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-akiya-bfd-seamless-ip-04
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-akiya-bfd-seamless-ip-04
> 
> 
> 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]
> 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: Wed, 13 Aug 2014 14:08:38 +0000

Hi Marc,

> looking at your latest version of S-BFD IP - btw, thanks for splitting off the
> IP/MPLS specifics from the base draft into this draft! - I have a few
> comments and questions:

Good to hear a comment implying that document restructure effort was worth the effort :)

And thanks again for further review!

> want to allow link-local addresses at all? (most S-BFD is likely multihop?)

Good point. It would be a good idea to add some texts to clarify what "local IP address" is. My immediate thought is that we add some texts stating that "local IP address" MUST be a routable address by the remote target. We probably should not get into what "type" of IPv6 address SBFDInitiator uses and when. Does that sound reasonable?
 
> (2) the UDP destination port for packets from the Reflector to the Initiator ...
> your draft defines this port to be the copied value of the UDP source port
> from the Initiator-to-Reflector packet and forces the port to be in the range
> [49152, 65535]. I hesitate to see this port range as suitable for a relevant
> service. It's typically "open" for traceroute, DNS replies and such, which
> means is can be "wide open" with respect to the source IP of incoming
> packets.
> 
> the Initiator then maybe allowing any source port (except from other well-
> known BFD ports :-) for outgoing Initiator-to-Reflector packets would help
> the network administrator to write access lists better tailored for S-BFD.

Interesting comment. Let me first say that it's probably a good idea to relax the port range as you said. Now whether we keep the port range [49152, 65535] or relax it, I would see identification of S-BFD packets on the initiator side to be:

- well-known source udp port MUST be matched
- initiator assigned destination port MAY matched

So the tailoring of access lists won't change.

In terms of relaxing the port range, I'm thinking something along the line of:

Initiator can use any UDP port but the port MUST NOT be the well-known S-BFD port (TBD1).

What do you think?

> Routing table is enough?  (even a default route? ;-)

It says exactly what you said, but details of how to implement such check is up to implementations.

> (4) New UDP port for S-BFD echo. Sure, can be done but why not simply
> using 3785/udp for this?  I fail to see what is the difference between S-BFD
> echo and an ordinary echo, considering that both leave many details to the
> implementor.

I understand where you are coming from. However there may be implementations out there which detects BFD echo packets to take them through special path in forwarding. We don't automatically want S-BFD echo packets to get same treatments applied. Hence authors decided that it's best to make sure the BFD/S-BFD echo ports are separate. Authors are working through S-BFD-SR document that describes how to use multi-hop S-BFD echo, we should be able to roll out the document within next few weeks.

> Networks" has somehow dropped P.K. Santosh ;-)

Right, we roll out the two documents same time, thus xml2rfc picked up the base-01 version (it takes a while for the just submitted document to be translated xml2rfc). Heh, Name="J. Networks" is a bit funny. Let me see if I can work with Santosh to clean this up.

Thanks!

-Nobo

---

From: Marc Binderberger <[email-masked]>
Date: Sun, 17 Aug 2014 13:57:31 -0700

Hello Nobo,

> Good to hear a comment implying that document restructure effort was worth 

sorry for the extra effort but I strongly believe it helps to focus on the 
"base" and "ip" aspects :-)

> Good point. It would be a good idea to add some texts to clarify what 
> "local IP address" is. My immediate thought is that we add some texts 
> stating that "local IP address" MUST be a routable address by the remote 
> target. We probably should not get into what "type" of IPv6 address 
> SBFDInitiator uses and when. Does that sound reasonable?

sounds good to me.

> Interesting comment. Let me first say that it's probably a good idea to 
> relax the port range as you said. Now whether we keep the port range 
> [49152, 65535] or relax it, I would see identification of S-BFD packets on 
> the initiator side to be:
> 

For most implementations you are right. But I like to use the basic BSD 
socket as a test because anything else is not standardized (de-facto or 
official).

So the Initiator opens a socket with a source UDP port S, sends out a UDP 
packet to the Reflector with destination UDP port TBD1 and receives the reply 
back to port S. For the Initiator the port S is what is matched on receiving 
the packet.

Thus my idea to relax it so an implementor can move S into a range where it 
suites best. While I assume that most ACL implementations do allow for a 
source port check I think it's still convenient to follow "destination port 
defines the service".

> Initiator can use any UDP port but the port MUST NOT be the well-known 

Yes please!

> I understand where you are coming from. However there may be 
> implementations out there which detects BFD echo packets to take them 
> through special path in forwarding. We don't automatically want S-BFD echo 
> packets to get same treatments applied.

oh, you are right. Not that I ever liked this "smart behaviour" but it's 
reality, so okay with a clean sheet approach.

> Heh, Name="J. Networks" is a bit funny. Let me see if 
> I can work with Santosh to clean this up.

:-)

Regards, Marc

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 19 Aug 2014 00:19:32 +0000

Hi Marc,

ACK on all the points. Will revise the s-bfd-ip document to address your comments and publish soon (aiming this week).

Thanks!

-Nobo

> -----Original Message-----
> From: Marc Binderberger [mailto:[email-masked]]
> Sent: Sunday, August 17, 2014 4:58 PM
> To: Nobo Akiya (nobo)
> Cc: [email-masked]
> Subject: RE: I-D Action: draft-akiya-bfd-seamless-ip-04.txt
> 
> Hello Nobo,
> 
>