Hi, Ben, Many thanks for this review and raising these issues, please see inline.
> On May 3, 2016, at 5:00 PM, Ben Campbell <[email protected]> wrote: > > Ben Campbell has entered the following ballot position for > draft-ietf-bfd-seamless-ip-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ip/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 4, 2nd paragraph: " If the port is not 7784, then the packet > MUST be looked up to locate > a corresponding SBFDInitiator session or classical BFD session based > on the value from the "your discriminator" field in the table > describing BFD discriminators. " > > Do I understand correctly that whether or not the destination port is > 7784 tells you if this is an "initial" packet vs a "reflected" packet? If > the destination port is not 7784, how do you know it’s not some competely > different protocol? Do you assume the receiver has no other UDP based > services? > Alia caught the same thing. The text is currently kinda broken as written in rev -04. We fixed this as follows based on Alia’s discuss, from our working copy: This procedure for an S-BFD packet is executed on both the initiator and the reflector. If the port is 7784 (i.e., S-BFD packet for S-BFDReflector), then the packet MUST be looked up to locate a corresponding SBFDReflector session based on the value from the "your discriminator" field in the table describing S-BFD discriminators. If the port is not 7784, but the packet is demultiplexed to be for an SBFDInitiator, then the packet MUST be looked up to locate a corresponding SBFDInitiator session based on the value from the "your discriminator" field in the table describing BFD discriminators. In that case, then the destination IP address of the packet SHOULD be validated to be for itself. If the packet demultiplexes to a classical BFD session, then the procedures from [RFC5880] apply. Which should clarify your point as well. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - 2: This doesn't seem to allow an administrator to configure different > listening ports by administrative action. Is that the intent? Also, why > does it matter if the source port is 7784? > That is correct, the intent is to not allow that port to be changed. The source port requirement is to have more differentiation between initiator and reflector. > - 6.1, first bullet: Does this imply that the initiator must listen for > reflected packets at its source port? Was that explicitly mentioned > somewhere that I missed? > Implied and you did not miss it. I will add it explicitly in Section 2 (last sentence). I also broke Section 2 in paragraphs for readability: 2. S-BFD UDP Port A new UDP port is defined for the use of the S-BFD on IPv4, IPv6 and MPLS environments: 7784. On S-BFD control packets from the SBFDInitiator to the SBFDReflector, the SBFDReflector session MUST listen for incoming S-BFD control packets on the port 7784. SBFDInitiator sessions MUST transmit S-BFD control packets with destination port 7784. The source port of the S-BFD control packets transmitted by SBFDInitiator sessions can be any but MUST NOT be 7784. The same UDP source port number MUST be used for all S-BFD control packets associated with a particular SBFDInitiator session. The source port number is unique among all SBFDInitiator sessions on the system. On S-BFD control packets from the SBFDReflecto to the SBFDInitiator, the SBFDInitiator MUST listen for reflected S-BFD control packets at its source port. > Editorial: > > -5.1.1, first paragraph: I had trouble parsing the last sentence in the > paragraph. > > Slightly wordsmithed as : address or the label stack. It is, however, possible for an SBFDInitiator to carefully set the "your discriminator" and TTL fields to perform a continuity test in the direction towards a target, but destined to a transit network node and not to the target itself. Hope this helps, — Carlos.
signature.asc
Description: Message signed with OpenPGP using GPGMail
