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

Thanks for addressing my DISCUSS point as well as my comments.

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?

Ron Bonica Performed the opsdir review.

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?

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?

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