Hi Carlos, On Mon, May 2, 2016 at 7:22 PM, Carlos Pignataro (cpignata) < [email protected]> wrote:
> Hi Alia, > > Thanks for the review and for these! Please see inline. > > > On May 2, 2016, at 6:26 PM, Alia Atlas <[email protected]> wrote: > > > > Alia Atlas 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: > > ---------------------------------------------------------------------- > > > > I think that these are both simple fast issues to resolve. > > > > 1) Sec 3: "This document defines only the UDP port value > > for the S-BFD Echo function. The source port and the procedures for > > the S-BFD Echo function are outside the scope of this document." > > Please add a reference to the S-BFD base document for defining where the > > procedures are found. > > > > Where, precisely, is the source port defined? It wasn't in the S-BFD > > base > > document. This seems like a hole. Can you please clarify? > > This is done exactly as in RFC 5881, purposefully. I can add a clarifying > sentence like: > > OLD: > This document defines only the UDP port value > for the S-BFD Echo function. The source port and the procedures for > the S-BFD Echo function are outside the scope of this document. > > NEW: > S-BFD echo follows the BFD echo definitions of [RFC 5881]. > Consequently, this document defines only the UDP port value > for the S-BFD Echo function; the source port and the procedures for > the S-BFD Echo function are outside the scope of this document. > How about a reference by the source port to [RFC 5881] and a reference for the procedures for the S-BFD Echo function [draft-ietf-bfd-seamless-base]? What wasn't clear to me - not having recently read RFC 5881 in detail - was that the UDP source port was defined in RFC 5881. I knew the procedures were in draft-ietf-bfd-seamless-base. > > > > 2) Sec 4: " 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. " > > > > I assume that you mean that UDP source port is used to look up the > > appropriate receiver. > > If that receiver handles BFD and S-BFD packets, then the "your > > discriminator" field is used > > to identify the BFD session. PLEASE clarify that because this reads as > > if BFD is the only > > application that uses UDP. > > > > Indeed, very much so. I suggest: > > OLD: > 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. If the located session is an > SBFDInitiator, then the destination IP address of the packet SHOULD > be validated to be for self. If the packet is a classical BFD > session, then the procedures from [RFC5880] apply. > > NEW: > 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. > > Would that work? > Sure - sounds good. Thanks, Alia > Thanks, > > — Carlos. > > > > > > > > >
