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.


> 
> 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?

Thanks,

— Carlos.

> 
> 
> 

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to