Subject: RE: A few thoughts on S-BFD drafts

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 22 Aug 2014 21:51:55 +0000

Hi Prasad,

Thanks for good comments. I hope you are ok with the list being cc'ed on this response.

> -----Original Message-----
> From: Vengada Prasad Govindan (venggovi)
> Sent: Friday, August 22, 2014 6:10 AM
> To: Nobo Akiya (nobo)
> Subject: A few thoughts on S-BFD drafts
> 
> Hello Nobo,
> 
> 1. Encapsulation for MPLS based: Do we always assume IP address based
> encapsulation?

Yes IP/UDP headers are required. When there's a need, a new document describing GAL/GACh based S-BFD is needed.

> 2. S-BFD echo:
>    a. For IP single-hop : No issues, however the SBFD initiator MUST NOT send
> echo packets when the reflector sets EchoMinRxInterval to 0. Sec 7.3.2 of
> the base requires that this field SHOULD be set to 0.  This may need to be
> reworded. Sec 10 also is not clear (in my understanding) on the usage of the
> EchoMinRxInterval field.

Right. Both Sections 7.2.2/7.3.2 states that "Required Min Echo RX Interval" SHOULD be zero. Section 10 further expands this by stating that "Required Min Echo RX Interval" MAY be set but explains why that's not useful. I don't believe Sections 7.2.2/7.3.2 needs to be changed, but let me see if Section 10 can be clarified a bit more.

>    b. For IP multi-hop: This is a difference from RFC 5882. How does an
> intermediate node (unaware of any S-BFD procedure) avoid U-turning the S-
> BFD echo packet? Would it be better to say that S-BFD echo MUST NOT be
> used if the Reflector is more than one hop away?

This topic should become clearer once we roll out the new revision of draft-akiya-bfd-seamless-sr, it's almost ready.

>    c. BFD for MPLS-TE LSPs: How is SBFDReflector supposed to work? Will the
> SBFDReflector always be at the tail of the tunnel?

Usually when using S-BFD on an RSVP-TE LSP, one would send in-band S-BFD packets with max TTL on the label. So the target node of S-BFD packets will be the egress of the RSVP-TE LSP. However, S-BFD packets could be terminated on transit LSR with careful TTL tweaking if that was ever required.

Section 5.2 of https://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/?include_text=1.

>    d. BFD for PW: Does SBFD apply here?

S-BFD best benefits monitoring of uni-directional paths. Personally I would not push S-BFD usage on the PW being bi-directional, but continue using the classical BFD. However, it is technically possible for the two end points to use S-BFD if that was desired.

> 3. Base draft should mention the relationship between S-BFD and P2MP BFD
> (if any).

The way the document is structured is that we have the base and the related data plane documents. P2MP is another data plane type, thus IMO, one should write a new P2MP S-BFD document when P2MP S-BFD is desired.

> 4. Names of packet types: Why not consider disambiguating S-BFD packets
> as S-BFD Async now that we have S-BFD Echo? For example, does Sec 5.1 of
> the base draft apply to S-BFD (Async) packets only or does it apply to S-BFD
> Echo as well?

Good point. I think that will improve the readability. Will incorporate this in the next revision.

> 5. Sec 7.3.2 of the base draft: Why should the desired MinTx  interval be
> copied from the received packet at the reflector? Can it not be set to 0 as
> the reflector does not originate packets. The Required Min Rx can be used
> to do the rate controlling as specified in the draft.

You are right, but a counter argument to what you are saying is that SBFDReflector is sending (or reflecting) S-BFD packets, so one can argue that zero(0) may not be an accurate reflection of the behavior. This is something we can go with whatever the WG wants (i.e. either way is likely reasonable).

Thanks!

-Nobo

> Regards
> Prasad

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Mon, 25 Aug 2014 11:12:47 +0000

Hello Nobo,
Many thanks to you for taking this thread to the list, please find responses to previous comments in-line with GVP1>. Additionally, please find a three more comments on draft-akiya-bfd-seamless-ip-05. 
 
Sec 2. S-BFD UDP port:
 A minor nit: Should this section be called S-BFD Control UDP port (if it achieves better clarity)

Sec 4:
 Reference to "classical BFD" may need to have a reference cited to RFC 5880?

Sec 7.2:
---snip---
   o  Implementations MUST provide filtering capability based on source
      IP addresses of received S-BFD control packets: [RFC2827].
---snip---
A few questions regarding the above text:
1. How will an implementation demonstrate its capability to support the above requirement? In other words should this be a mandatory requirement? I understand that the intent of the requirement is to achieve resource/ equipment protection against DoS attacks. 
2. Should the section refer to mechanisms like GTSM? 

Thanks
Prasad

-----Original Message-----
From: Nobo Akiya (nobo) 
Sent: Saturday, August 23, 2014 3:22 AM
To: Vengada Prasad Govindan (venggovi)
Cc: [email-masked]
Subject: RE: A few thoughts on S-BFD drafts

Hi Prasad,

Yes IP/UDP headers are required. When there's a need, a new document describing GAL/GACh based S-BFD is needed.
GVP1> Would you think that this understanding needs to be recorded in the document. Perhaps, somewhere in Sec 5. My suggestion is to make the opening sentence of Sec 5 a mandatory requirement. But I leave it to you to decide.

> 2. S-BFD echo:
>    a. For IP single-hop : No issues, however the SBFD initiator MUST 
> NOT send echo packets when the reflector sets EchoMinRxInterval to 0. 
> Sec 7.3.2 of the base requires that this field SHOULD be set to 0.  
> This may need to be reworded. Sec 10 also is not clear (in my 
> understanding) on the usage of the EchoMinRxInterval field.

>    b. For IP multi-hop: This is a difference from RFC 5882. How does 
> an intermediate node (unaware of any S-BFD procedure) avoid U-turning 
> the S- BFD echo packet? Would it be better to say that S-BFD echo MUST 
> NOT be used if the Reflector is more than one hop away?

This topic should become clearer once we roll out the new revision of draft-akiya-bfd-seamless-sr, it's almost ready.
GVP1> Just for further understanding, S-BFD echo procedures would work in single-hop for IPv4 and IPv6. S-BFD echo requires IPv6 or MPLS Segment Routing dataplanes to work. Is this correct? 

>    c. BFD for MPLS-TE LSPs: How is SBFDReflector supposed to work? 
> Will the SBFDReflector always be at the tail of the tunnel?

> 3. Base draft should mention the relationship between S-BFD and P2MP 
> BFD (if any).

The way the document is structured is that we have the base and the related data plane documents. P2MP is another data plane type, thus IMO, one should write a new P2MP S-BFD document when P2MP S-BFD is desired.
GVP1> Agreed, it may be help to add a clarifying statement mentioning that P2MP BFD is outside the scope of the current document.

> 4. Names of packet types: Why not consider disambiguating S-BFD 
> packets as S-BFD Async now that we have S-BFD Echo? For example, does 
> Sec 5.1 of the base draft apply to S-BFD (Async) packets only or does 
> it apply to S-BFD Echo as well?

> 5. Sec 7.3.2 of the base draft: Why should the desired MinTx  interval 
> be copied from the received packet at the reflector? Can it not be set 
> to 0 as the reflector does not originate packets. The Required Min Rx 
> can be used to do the rate controlling as specified in the draft.

You are right, but a counter argument to what you are saying is that SBFDReflector is sending (or reflecting) S-BFD packets, so one can argue that zero(0) may not be an accurate reflection of the behavior. This is something we can go with whatever the WG wants (i.e. either way is likely reasonable).
GVP1> Agreed. One could make it a non-zero value based on the packet rate that can be actually supported by the reflector (note that this can be a value less than or equal to the required minRx set by the initiator). This highlights one important (in my view at least) difference with respect to classical BFD. In classical BFD, while the packet rates in each direction can be asymmetric, the packet rates of S-BFD have to (eventually) be symmetric. In any case a copy may not be possible.

Thanks!

-Nobo

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 25 Aug 2014 15:33:07 +0000

Hi Prasad,

Thanks for further comments.
Snipping out the ones we converged.

Note that few minor tweaks are required to S-BFD IP document as result of your further comments below, but we will plan to incorporate them later when we need to re-spin the document. We will likely proceed with the WG adoption with S-BFD IP -05. Let us know if you have any concern with this.

>  A minor nit: Should this section be called S-BFD Control UDP port (if it

Sounds good. Will update IP/SR documents accordingly.

>  Reference to "classical BFD" may need to have a reference cited to RFC

The term is already defined in S-BFD base document.

o Classical BFD - BFD session types based on [RFC5880].

But let me update Introduction section slightly.

[OLD]
   The reader is expected to be familiar with the IP, MPLS BFD and S-BFD
   terminologies and protocol constructs.

[NEW]
   The reader is expected to be familiar with the IP, MPLS, BFD
   [RFC5880] and S-BFD [I-D.ietf-bfd-seamless-base] terminologies and
   protocol constructs.

> 1. How will an implementation demonstrate its capability to support the
> above requirement? In other words should this be a mandatory
> requirement? I understand that the intent of the requirement is to achieve
> resource/ equipment protection against DoS attacks.

I think it should be stated as mandatory in the document.

> 2. Should the section refer to mechanisms like GTSM?

GTSM is purposely not mentioned to allow for texts described in Section 5.2.

> Yes IP/UDP headers are required. When there's a need, a new document
> describing GAL/GACh based S-BFD is needed.
> GVP1> Would you think that this understanding needs to be recorded in the
> document. Perhaps, somewhere in Sec 5. My suggestion is to make the
> opening sentence of Sec 5 a mandatory requirement. But I leave it to you to
> decide.

Well, the first sentence of Section 5 is:

   S-BFD control packets are transmitted with IP header, UDP header and
   BFD control header ([RFC5880]).

My thought is that this is sufficient.

> This topic should become clearer once we roll out the new revision of draft-
> akiya-bfd-seamless-sr, it's almost ready.
> GVP1> Just for further understanding, S-BFD echo procedures would work in
> single-hop for IPv4 and IPv6. S-BFD echo requires IPv6 or MPLS Segment
> Routing dataplanes to work. Is this correct?

Segment Routing is the primary driver for the S-BFD echo function. For bi-directional single-hop continuity check, I don't see the need to migrate away from classical BFD sessions IMHO, it is working well.

> The way the document is structured is that we have the base and the
> related data plane documents. P2MP is another data plane type, thus IMO,
> one should write a new P2MP S-BFD document when P2MP S-BFD is desired.
> GVP1> Agreed, it may be help to add a clarifying statement mentioning that
> P2MP BFD is outside the scope of the current document.

Let's not even mention P2MP, i.e. take similar approach as RFC5881 (which also doesn't mention this).

> You are right, but a counter argument to what you are saying is that
> SBFDReflector is sending (or reflecting) S-BFD packets, so one can argue that
> zero(0) may not be an accurate reflection of the behavior. This is something
> we can go with whatever the WG wants (i.e. either way is likely reasonable).
> GVP1> Agreed. One could make it a non-zero value based on the packet rate
> that can be actually supported by the reflector (note that this can be a value
> less than or equal to the required minRx set by the initiator). This highlights
> one important (in my view at least) difference with respect to classical BFD.
> In classical BFD, while the packet rates in each direction can be asymmetric,
> the packet rates of S-BFD have to (eventually) be symmetric. In any case a
> copy may not be possible.

Some other BFD fields are copied by the SBFDReflector, but not "Required Min Echo RX Interval".

   o  "Required Min Echo RX Interval" SHOULD be set to zero.

Let us know if you have any concern with this.

Thanks!

-Nobo