Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS
draft-ietf-bfd-seamless-ip-06

Note: This ballot was opened for revision 03 and is now closed.

(Alia Atlas) (was Discuss) Yes

Comment (2016-05-04 for -04)
No email
send info
Thank you for addressing my discuss concerns.
I look forward to the updated draft.

Alvaro Retana Yes

(Jari Arkko) No Objection

Comment (2016-05-04 for -05)
No email
send info
Elwyn Davies raised a question about why it is reasonable to require special-case TTL expiry treatment. Carlos Pignataro had a response relating to existing practice with similar treatment. Could that explanation/response and the logic why this is reasonable be added as a note to the document?

Deborah Brungard No Objection

(Ben Campbell) (was Discuss) No Objection

Comment (2016-05-03 for -04)
No email
send info
Thanks for addressing my DISCUSS point as well as my comments.

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

Comment (2016-05-03 for -04)
No email
send info
Just a couple of small things.

I'm pretty sure I know why 

      *  UDP destination port MUST be set to a well-known UDP
         destination port assigned for S-BFD: 7784.

      *  UDP source port MUST NOT be set to 7784.
      
the UDP source port has this restriction, but it might be helpful to people who can't guess, if you could add a phrase explaining why. We were all new protocol designers once.
      
It's a small thing, but 

       BFD Chairs <bfd-chairs@tools.ietf.org>
       
we're phasing out @tools.ietf.org in favor of @ietf.org, aren't we?

(Stephen Farrell) No Objection

(Joel Jaeggli) No Objection

Comment (2016-05-04 for -05)
No email
send info
Ron Bonica Performed the opsdir review.

Suresh Krishnan No Objection

Comment (2016-05-04 for -05)
No email
send info
Section 5.1, 6.1:

The IPv4-mapped IPv6 prefix for the IPv4 loopback range 127.0.0.0/8 is incorrect.

It is currently written as 0:0:0:0:0:FFFF:7F00/104. It should instead be 0:0:0:0:0:FFFF:7F00:0/104.

Sections 5.1, 6.1:

The document just talks about the TTL field being set to 255. It does not talk about the Hop Limit field for IPv6. I would assume you want to do the same for IPv6 packets as for the IPv4 packets. Can you include the Hop Limit as well if you want the same behavior for IPv6. I have two suggested forms of changes. Pick whatever works better for you.

OLD:

TTL field of the IP header SHOULD be set to 255

NEW:

The TTL/Hop Limit field of the IP header SHOULD be set to 255

(or) 

The TTL field of the IPv4 header or the Hop Limit field of the IPv6 header SHOULD be set to 255

Mirja K├╝hlewind No Objection

Comment (2016-05-03 for -04)
No email
send info
This part is unclear to me:
"It is, however, possible for an
   SBFDInitiator to carefully set "your discriminator" and TTL fields to
   perform a continuity test towards a target, but to a transit network
   node and not to the target itself. [...] 
   This also requires S-BFD control packets not be dropped by the
   responder node due to TTL expiry.  Thus implementations on the
   responder MUST allow received S-BFD control packets taking TTL expiry
   exception path to reach corresponding reflector BFD session."

You basically perform a traceroute with (S-)BFD, right? Why do you need the last sentence? Wouldn't it be okay, if the packet get dropped by the responder, to simply re-send with a higher TTL?

(Terry Manderson) No Objection

Alexey Melnikov No Objection

(Kathleen Moriarty) No Objection