Re: Alia Atlas' Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS and COMMENT)

Tue, 03 May 2016 09:56:15 -0700

Hi, Alia,

Thanks for the response!

We are on the exact same page regarding items #1 and #2.

For item #3, we really want to modularize the specs and not tie the -base to the transports. Note that we mention “UDP” but also “associated channel type”.

For #3, here’s the change I implemented:

    S-BFD packet MUST be demultiplexed with lower layer information
-   (e.g., dedicated destination UDP port, associated channel type).
-   Following procedure SHOULD be executed on both initiator and
-   reflector.
+   (e.g., dedicated destination UDP port [I-D.ietf-bfd-seamless-ip],
+   associated channel type [I-D.ietf-pals-seamless-vccv]).  Following
+   procedure SHOULD be executed on both initiator and reflector.

And please find attached full diffs addressing all the Discuss points.

Thanks!

— Carlos.

Index: draft-ietf-bfd-seamless-base-10.txt
===================================================================
--- draft-ietf-bfd-seamless-base-10.txt (revision 3541)
+++ draft-ietf-bfd-seamless-base-10.txt (working copy)
@@ -92,7 +92,7 @@
        7.2.2.  Transmission of S-BFD Control Packet by SBFDReflector  10
        7.2.3.  Additional SBFDReflector Behaviors  . . . . . . . . .  11
      7.3.  Initiator Procedures  . . . . . . . . . . . . . . . . . .  12
-       7.3.1.  SBFDInitiator State Machine . . . . . . . . . . . . .  13
+       7.3.1.  SBFDInitiator State Machine . . . . . . . . . . . . .  12
        7.3.2.  Transmission of S-BFD Control Packet by SBFDInitiator  13
        7.3.3.  Additional SBFDInitiator Behaviors  . . . . . . . . .  14
      7.4.  Diagnostic Values . . . . . . . . . . . . . . . . . . . .  14
@@ -117,7 +117,7 @@
    15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
      15.1.  Normative References . . . . . . . . . . . . . . . . . .  18
      15.2.  Informative References . . . . . . . . . . . . . . . . .  18
-   Appendix A.  Loop Problem . . . . . . . . . . . . . . . . . . . .  19
+   Appendix A.  Loop Problem and Solution  . . . . . . . . . . . . .  19
    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20
 
 1.  Introduction
@@ -457,7 +457,7 @@
 
    o  bfd.DemandMode: This variable MUST be initialized to 1 for session
       type SBFDInitiator, and MUST be initialized to 0 for session type
-      SBFDReflector.
+      SBFDReflector.  This is done to prevent loops (see Appendix A).
 
 7.  S-BFD Procedures
 
@@ -464,9 +464,9 @@
 7.1.  Demultiplexing of S-BFD Control Packet
 
    S-BFD packet MUST be demultiplexed with lower layer information
-   (e.g., dedicated destination UDP port, associated channel type).
-   Following procedure SHOULD be executed on both initiator and
-   reflector.
+   (e.g., dedicated destination UDP port [I-D.ietf-bfd-seamless-ip],
+   associated channel type [I-D.ietf-pals-seamless-vccv]).  Following
+   procedure SHOULD be executed on both initiator and reflector.
 
       If S-BFD packet
 
@@ -518,8 +518,7 @@
 
 7.2.1.  Responder Demultiplexing
 
-   S-BFD packet MUST be demultiplexed with lower layer information
-   (e.g., dedicated destination UDP port, associated channel type).
+   S-BFD packet MUST be demultiplexed with lower layer information.
    Following procedure SHOULD be executed by responder:
 
       If "your discriminator" not one of the entry allocated for local
@@ -552,7 +551,8 @@
 
       Demand (D)
 
-         Set to 0.
+         Set to 0, to identify the S-BFD packet is sent by the
+         SBFDReflector.
 
 
 
@@ -618,20 +618,15 @@
 Internet-Draft              Seamless BFD Base                   May 2016
 
 
-   o  If the SBFDReflector wishes to communicate to some or all
-      SBFDInitiators that monitored local entity is "temporarily out of
-      service", then S-BFD control packets with "state" set to ADMINDOWN
-      are sent to those SBFDInitiators.  The SBFDInitiators, upon
-      reception of such packets, MUST NOT conclude loss of reachability
-      to corresponding remote entity, and MUST back off packet
-      transmission interval for the remote entity to an interval no
-      faster than 1 second.  If the SBFDReflector is generating a
-      response S-BFD control packet for a local entity that is in
-      service, then "state" in response BFD control packets MUST be set
-      to UP.
+   o  When the SBFDReflector receives an S-BFD control packet from an
+      SBFDInitiator, then the SBFDReflector needs to determine what
+      "state" to send in the response S-BFD control packet.  If the
+      monitored local entity is in service, then the "state" MUST be set
+      to UP.  If the monitored local entity is "temporarily out of
+      service", then the "state" SHOULD be set to ADMINDOWN.
 
    o  If an SBFDReflector receives an S-BFD control packet with Demand
-      (D) bit cleared, the packet MUST be discarded.
+      (D) bit cleared, the packet MUST be discarded (see Appendix A).
 
 7.3.  Initiator Procedures
 
@@ -665,7 +660,12 @@
 
              Figure 3: S-BFD Continuity Test
 
+7.3.1.  SBFDInitiator State Machine
 
+   An SBFDInitiator may be a persistent session on the initiator with a
+   timer for S-BFD control packet transmissions (stateful
+   SBFDInitiator).  An SBFDInitiator may also be a module, a script or a
+   tool on the initiator that transmits one or more S-BFD control
 
 
 
@@ -674,12 +674,6 @@
 Internet-Draft              Seamless BFD Base                   May 2016
 
 
-7.3.1.  SBFDInitiator State Machine
-
-   An SBFDInitiator may be a persistent session on the initiator with a
-   timer for S-BFD control packet transmissions (stateful
-   SBFDInitiator).  An SBFDInitiator may also be a module, a script or a
-   tool on the initiator that transmits one or more S-BFD control
    packets "when needed" (stateless SBFDInitiator).  For stateless
    SBFDInitiators, a complete BFD state machine may not be applicable.
    For stateful SBFDInitiators, the states and the state machine
@@ -722,20 +716,20 @@
          D bit is used to identify S-BFD packet originated from
          SBFDInitiator and is always set to 1.
 
+      Your Discriminator
 
+         Set to bfd.RemoteDiscr. bfd.RemoteDiscr is set to discriminator
+         value of remote entity.  It MAY be learnt from routing
+         protocols or configured locally.
 
 
+
+
 Akiya, et al.           Expires November 3, 2016               [Page 13]
 
 Internet-Draft              Seamless BFD Base                   May 2016
 
 
-      Your Discriminator
-
-         Set to bfd.RemoteDiscr. bfd.RemoteDiscr is set to discriminator
-         value of remote entity.  It MAY be learnt from routing
-         protocols or configured locally.
-
       Required Min RX Interval
 
          Set to 0.
@@ -751,6 +745,12 @@
       then the SBFDInitiator SHOULD conclude that S-BFD control packet
       reached the intended remote entity.
 
+   o  When an SBFDInitiator receives a response S-BFD control packet, if
+      the state specified is ADMINDOWN, the SBFDInitiator MUST NOT
+      conclude loss of reachability to the corresponding remote entity,
+      and MUST back off packet transmission interval for the remote
+      entity to an interval no faster than 1 second.
+
    o  When a sufficient number of S-BFD packets have not arrived as they
       should, the SBFDInitiator SHOULD declare loss of reachability to
       the remote entity.  The criteria for declaring loss of
@@ -766,7 +766,7 @@
       responder back to initiator.
 
    o  If the SBFDInitiator receives an S-BFD control packet with Demand
-      (D) bit set, the packet MUST be discarded.
+      (D) bit set, the packet MUST be discarded (see Appendix A).
 
 7.4.  Diagnostic Values
 
@@ -1022,6 +1022,11 @@
               Cases", draft-ietf-bfd-seamless-use-case-06 (work in
               progress), April 2016.
 
+   [I-D.ietf-pals-seamless-vccv]
+              Govindan, V. and C. Pignataro, "Seamless BFD for VCCV",
+              draft-ietf-pals-seamless-vccv-03 (work in progress), April
+              2016.
+
    [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
               DOI 10.17487/RFC0791, September 1981,
               <http://www.rfc-editor.org/info/rfc791>.
@@ -1035,7 +1040,7 @@
               DOI 10.17487/RFC3031, January 2001,
               <http://www.rfc-editor.org/info/rfc3031>.
 
-Appendix A.  Loop Problem
+Appendix A.  Loop Problem and Solution
 
    Consider a scenario where we have two nodes and both are S-BFD
    capable.
@@ -1053,11 +1058,6 @@
 
    Suppose MiM sends a spoofed packet with MyDisc = 0x01010101, YourDisc
    = 0x02020202, source IP as 2001:db8::1 and dest IP as 2001:db8::2.
-   When this packet reaches Node B, the reflector session on Node B will
-   swap the discriminators and IP addresses of the received packet and
-   reflect it back, since YourDisc of the received packet matched with
-   reserved discriminator of Node B.  The reflected packet that reached
-   Node A will have MyDdisc=0x02020202 and YourDisc=0x01010101.  Since
 
 
 
@@ -1066,6 +1066,11 @@
 Internet-Draft              Seamless BFD Base                   May 2016
 
 
+   When this packet reaches Node B, the reflector session on Node B will
+   swap the discriminators and IP addresses of the received packet and
+   reflect it back, since YourDisc of the received packet matched with
+   reserved discriminator of Node B.  The reflected packet that reached
+   Node A will have MyDdisc=0x02020202 and YourDisc=0x01010101.  Since
    YourDisc of the received packet matched the reserved discriminator of
    Node A, Node A will swap the discriminators and reflects the packet
    back to Node B.  Since reflectors must set the TTL of the reflected
@@ -1072,31 +1077,11 @@
    packets to 255, the above scenario will result in an infinite loop
    with just one malicious packet injected from MiM.
 
-   FYI: Packet fields do not carry any direction information, i.e., if
-   this is Ping packet or reply packet.
+   The solution to avoid the loop problem uses the "D" bit (Demand mode
+   bit).  The Initiator always sets the 'D' bit and the reflector always
+   clears it.  This way we can identify if a received packet was a
+   reflected packet and avoid reflecting it back.
 
-   Solutions
-
-   The current proposals to avoid the loop problem are:
-
-   o  Overload "D" bit (Demand mode bit): Initiator always sets the 'D'
-      bit and reflector clears it.  This way we can identify if a
-      received packet was a reflected packet and avoid reflecting it
-      back.  However this changes the interpretation of 'D' bit.
-
-   o  Use of State field in the BFD control packets: Initiator will
-      always send packets with State set to DOWN and reflector will send
-      back packets with state field set to UP.  Reflectors will never
-      reflect any received packets with state as UP.  However the only
-      issue is the use of state field differently i.e., state in the
-      S-BFD control packet from initiator does not reflect the local
-      state which is anyway not significant at reflector.
-
-   o  Use of local discriminator as My Disc at reflector: Reflector will
-      always fill in My Discriminator with a locally allocated
-      discriminator value (not reserved discriminators) and will not
-      copy it from the received packet.
-
 Authors' Addresses
 
    Nobo Akiya
@@ -1111,17 +1096,6 @@
    Email: [email protected]
 
 
-
-
-
-
-
-
-Akiya, et al.           Expires November 3, 2016               [Page 20]
-
-Internet-Draft              Seamless BFD Base                   May 2016
-
-
    Dave Ward
    Cisco Systems, Inc.
 
@@ -1143,34 +1117,4 @@
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Akiya, et al.           Expires November 3, 2016               [Page 21]
+Akiya, et al.           Expires November 3, 2016               [Page 20]

On May 3, 2016, at 10:53 AM, Alia Atlas <[email protected]> wrote:

Hi Carlos,

On Mon, May 2, 2016 at 6:34 PM, Carlos Pignataro (cpignata) <[email protected]> wrote:
Hi, Alia,

Thanks for your review and for bringing up these issues — please see inline.

> On May 2, 2016, at 5:24 PM, Alia Atlas <[email protected]> wrote:
>
> Alia Atlas has entered the following ballot position for
> draft-ietf-bfd-seamless-base-09: 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-base/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> a) In Sec 7.2.3:  "If the SBFDReflector is generating a response S-BFD
> control packet for a local entity that is in
>      service, then "state" in response BFD control packets MUST be set
> to UP."
>    So far, it looked like the SBFDReflector only sends BFD control
> packets in response to receiving such packets
>    from SBFDInitiators.   This paragraph (not just copied) does not
> clearly describe the desired behavior.  If the
>   monitored local entity is "temporarily out of service", does the
> SBFDReflector respond back to the SBFDInitiator
>   with 2 BFD control packets - one indicating UP (as a MUST) and then
> the next indicating ADMINDOWN?  Is the
>   SBFDReflector expected to store a list of active SBFDInitiators and
> proactively send BFD control packets indicating
>   ADMINDOWN?   Please clarify in non-trivial detail.

The way in which that particular bullet in that subsection is written can be a bit confusing.

First, you are right that the SBFDReflector only sends packets in response to S-BFD control packets from the SBFDInitiators. This is clearly spelled out in Section 5, and in other places that explain how the reflector is stateless.

The SBFDReflector only response and does not stores a list of SBFDInitiators to proactively send S-BFD packets (see Section 5). Further, it does not respond with two packets. (UP and ADMINDOWN).

I think this can be rewritten to better explain what happens, as follows:

OLD:
   o  If the SBFDReflector wishes to communicate to some or all
      SBFDInitiators that monitored local entity is "temporarily out of
      service", then S-BFD control packets with "state" set to ADMINDOWN
      are sent to those SBFDInitiators.  The SBFDInitiators, upon
      reception of such packets, MUST NOT conclude loss of reachability
      to corresponding remote entity, and MUST back off packet
      transmission interval for the remote entity to an interval no
      faster than 1 second.  If the SBFDReflector is generating a
      response S-BFD control packet for a local entity that is in
      service, then "state" in response BFD control packets MUST be set
      to UP.

NEW:
   o  If the SBFDReflector, upon receiving an S-BFD control packet from
      an SBFDInitiators, wishes to communicate to those
      SBFDInitiators that a monitored local entity is "temporarily out of
      service", then an S-BFD control packet with "state" set to ADMINDOWN
      is sent in response to those SBFDInitiators.  The SBFDInitiators, upon
      reception of such packets, MUST NOT conclude loss of reachability
      to corresponding remote entity, and MUST back off packet
      transmission interval for the remote entity to an interval no
      faster than 1 second.  If, on the other hand, the SBFDReflector is generating a
      response S-BFD control packet for a local entity that is in
      service, then "state" in response BFD control packets MUST be set
      to UP.

Is that more clear?

Slightly - but what about:

"When the SBFDReflector receives an S-BFD control packet from an SBFDInitiator,
then the SBFDReflector needs to determine what state to send in the response S-BFD
control packet.  If the monitored local entity is in service, then the "state" MUST be
set to UP.  However, if the monitored local entity is "temporarily out of service" for
rapidly processing S-BFD packets, for instance due to an overload, then the "state" 
SHOULD be set to ADMINDOWN.  The SBFDReflector SHOULD send a response
S-BFD control packet.  

When an SBFDInitiator receives a response S-BFD control packet, if the state specified
is ADMINDOWN, the SBFDInitiator MUST NOT conclude loss of  reachability
to corresponding remote entity, and MUST back off packet transmission interval for the 
remote entity to an interval no faster than 1 second. "

Either wording or a mixture is just fine.   

>
> b) Appendix A:  The looping problem is nicely defined but the text still
> discusses three potential solutions; clearly the
> use of the D bit has been chosen.   It would be much nicer to have the
> justification in line, but for this discuss - the
> unselected alternatives don't belong.
>

Sorry I’m not sure I understand fully your point. Are you suggesting we mention in the actual reason for the D-bit procedures outside the Appendix (although the procedures for the D bit are explained in Section 6.2, 7.2.2, 7.2.3, 7.3.2, and 7.2.2), while still leave the Appendix as-is?

If so we can do that, but want to confirm.

I'm suggesting that you mention the reason for the D-bit procedures outside the Appendix and remove the Appendix.  Alternately, keep the Appendix but remove discussion of the other ways the problem could have been solved and add a reference from the D-bit procedures to the Appendix.
 
Once this is an RFC, it doesn't matter what the other possible and unselected design choices were.

> c) Sec 7.2.1: "   S-BFD packet MUST be demultiplexed with lower layer
> information
>   (e.g., dedicated destination UDP port, associated channel type)."
>  Where precisely is this defined or described?  Is there an allocation
> for a dedicated UDP
> port for S-BFD?  I don't see any normative reference to such.  In
> particular, since the format
> for an S-BFD control packet is exactly the same as for BFD and since only
> this demultiplexing
> with lower layer information is used to tell the difference between S-BFD
> and BFD packets,
> this document requires more specifics.
>

This is similar to RFC 5880 and RFC 5881. The actual S-BFD applications specify this. For example, bfd-seamless-ip defines the UDP port. We purposely do not want to have the specification (either explicitly or normatively pointed to) from this document, as this is just the base specification.

Why?  Unlike RFC 5880, this document mentions UDP ports as an example of a demultiplexer.
While I do understand that BFD can run with different transports, it is useful to clearly articulate
one use transport that has enough information to be actually implemented.   In this case, that's
just a normative reference to another document progressing at the same time.

I can't get too worked up about normative vs. informative references in general - the guideline I
use is whether an implementor would need to read the reference to properly implement the
functionality.

If you feel extremely strongly that the reference must be informative, I'm not going to dig in my
heels - but PLEASE put a reference by the mention of the UDP port.
 
 
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 1) In the last paragraph of Sec 4.2: "  Even when following the separate
> discriminator pool approach,
>   collision is still possible between one S-BFD application to another
>   S-BFD application, that may be using different values and algorithms
>   to derive S-BFD discriminator values.  If the two applications are
>   using S-BFD for a same purpose (e.g., network reachability), then the
>   colliding S-BFD discriminator value can be shared.  If the two
>   applications are using S-BFD for a different purpose, then the
>   collision must be addressed.  How such collisions are addressed is
>   outside the scope of this document."
>
>  Sec 4.1 talks about the need for the S-BFD Discriminator to be unique
> within an Administrative Domain.
>  I don't see any details of that addressed here.   What is addressed
> here seems to be the case for multiple
>  S-BFD discriminators applying to the same node - which is specifically
> discouraged at the end of Sec 3.
>  Rather than simply describing the issue as "outside the scope of this
> document", please either describe it
>  as "future work and multiple S-BFD discriminators is discouraged" or
> add a reference.
>

Good point, will do.

> 2) In Sec 6.1: "bfd.SessionType:" is defined but the only possible values
> are for SBFD.   Is it possible for a BFD
> session to still use the same bfd structure?  I don't see a value for
> SessionType there; I'd expect to see at least
> a value for the original BFD session and possible an undefined or
> unspecified value for future proofing.
>
>

Traditional BFD does not use this state variable. That’s why we don’t need to define a value for BFD. However, future specs can when it is relevant (e.g, using BFD for various types as opposed to S-BFD), as for example bfd-multipoint.

Right - I understand that.  I'm thinking a bit from the implementation perspective.  If I have the same data-structures and similar logic for BFD and S-BFD, then there'll be a bfd.SessionType even for BFD sessions that don't need it.  Clarifying a value of "Unused" or "Classical BFD" gives clarity that one 
of the S-BFD options doesn't need to be chosen.

This is just a comment.  It's up to your best judgement.

Thanks,
Alia 


Please let us know your thoughts on the responses above, and we can send out diffs.

Thanks!

— Carlos.




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

Reply via email to