Subject: draft-ietf-bfd-seamless-base

From: Gregory Mirsky <[email-masked]>
Date: Wed, 9 Jul 2014 20:40:02 +0000

Dear Authors, et. al,
this is great progress, my congratulations to all! Please find my notes and editorial nits below:

*         Introduction, second para refers to connectivity testing. I believe that BFD been used and defined primarily as continuity checking tool though there's at least one example of building connectivity verification based on it. I think that changing from "connectivity test" to "continuity test", throughout the document, would make it more accurate.

*         s/state changes from DOWN to UP is/state changes from DOWN to UP are | state change from DOWN to UP is/;

*         Section 4 suggests that both S-BFD Initiator and Responder send S-BFD control packets to the same well-known UDP port;

*         Section 5, not clear why S-BFD discriminator appears to have different uniqueness requirement depending of its use (discriminator collision). I think that there should be consistency. There seems to be disagreement between the first paragraph and the second that requires AS uniqueness of S-BFD discriminators. Or "discriminator collision" is not the same as "uniqueness"?

*         Section 5, second para discusses mis-connectivity case. True, it easier to detect with IP data plane then with MPLS, whether IP or ACH encapsulation (where PHP is not the only problem but label merge as well). If S-BFD to be used as true Connectivity Verification tool, then in all encapsulations source must be clearly identifiable. For MPLS data plane it could be done with help of Source MEP-ID TLV as in RFC 6428. Would note that even with strong requirement of AS/AD scope of S-BFD discriminator there must be mechanism to detect and act upon, e.g. drop or enter mis-connectivity error state, "re-use" of discriminators as that likely to pose security threat (DDoS).

*         Section 8.1 suggests, when distinct pools of BFD and S-BFD discriminators used, that "My discriminator" must be always allocated from BFD pool. Would note that unless BFD and S-BFD pools made explicitly separated there's no, IMO, way to determine from which pool particular discriminator been allocated from. Thus node's own S-BFD discriminators must be punched out in BFD pool to prevent accidentally being allocated as My Discriminator. That seems to complicate things and relationship between BFD and S-BFD.

*         And to add to the issue of My Discriminator, I don't see anything that prevents R2 receiving pings from R1 and R2 in the same md, i.e. R1 and R4 allocating the same discriminator from BFD pool to be used as My discriminator. Where the pong will go then? In light of this, I'm more in favor of nodes advertising discriminator(s) through IGP extensions (or being centrally allocated) explicitly as their My Discriminator

*         And last but not least, it appears that document assumes that S-BFD capable node would always have BFD functionality supported. I think that not necessarily the case and S-BFD only node must be considered in the document. Thus, my question, if there's no BFD and BFD pool of discriminators, where from My Discriminator would be allocated for S-BFD?

*         Section 8.1.1 may benefit from introduction of terms of "stateful initiator" and "stateless initiator" when characterizing different behavior of SBFDInitiator.

Regards,
        Greg

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 11 Jul 2014 22:08:30 +0000

Hi Greg,

Many thanks for thoughtful comments!
And my apologies for the delay in response.

Please see in-line.

> -----Original Message-----
> From: Gregory Mirsky [mailto:[email-masked]]
> Sent: Wednesday, July 09, 2014 4:40 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: draft-ietf-bfd-seamless-base
> 
> Dear Authors, et. al,
> this is great progress, my congratulations to all! 

The authors certainly placed good effort to roll out this -01, but that was possible largely due to many great comments on/off the list. So thanks and congratulations to all!

> Please find my notes and
> editorial nits below:
> . Introduction, second para refers to connectivity testing. I believe that BFD
> been used and defined primarily as continuity checking tool though there's
> at least one example of building connectivity verification based on it. I think
> that changing from "connectivity test" to "continuity test", throughout the
> document, would make it more accurate.

True, scanning the document we can do s/connectivity/continuity/ in most places, and do s/connectivity/reachability/ in couple of places. ACK, in todo list for the next revision.

> . s/state changes from DOWN to UP is/state changes from DOWN to UP are |
> state change from DOWN to UP is/;

Good catch. Will take the first suggested.

> . Section 4 suggests that both S-BFD Initiator and Responder send S-BFD
> control packets to the same well-known UDP port;

Oops, let's fix that. Will also update procedures in 8.1.2 and 8.2.1.

Specifically:
- SBFDInitiator is to set destination port to TBD1.
- SBFDReflector is to swap source/destination ports when copying from ping to pong.

Agree?

> . Section 5, not clear why S-BFD discriminator appears to have different
> uniqueness requirement depending of its use (discriminator collision). I
> think that there should be consistency. There seems to be disagreement
> between the first paragraph and the second that requires AS uniqueness of
> S-BFD discriminators. Or "discriminator collision" is not the same as
> "uniqueness"?

Right, "internal discriminator collision" is different than "S-BFD discriminator uniqueness within an administrative domain".

We need to break up this section into 2 subsections.

5.  S-BFD Discriminators

5.1.  Discriminator Pools

5.2.  S-BFD Discriminator Uniqueness

And re-thinking about the discriminator pool rules (along with your 2nd from last comment below), they should be described as:

   o  SBFDInitiator is to allocate a discriminator from the BFD
      discriminator pool.  If the system also supports classical BFD
      that runs on [RFC5880], then the BFD discriminator pool MUST be
      shared by SBFDInitiators and classical BFD sessions.

   o  SBFDReflector is to allocate a discriminator from the S-BFD
      discriminator pool.  The S-BFD discriminator pool SHOULD be a
      separate pool than the BFD discriminator pool.

> . Section 5, second para discusses mis-connectivity case. True, it easier to
> detect with IP data plane then with MPLS, whether IP or ACH encapsulation
> (where PHP is not the only problem but label merge as well). If S-BFD to be
> used as true Connectivity Verification tool, then in all encapsulations source
> must be clearly identifiable. For MPLS data plane it could be done with help
> of Source MEP-ID TLV as in RFC 6428. Would note that even with strong
> requirement of AS/AD scope of S-BFD discriminator there must be
> mechanism to detect and act upon, e.g. drop or enter mis-connectivity error
> state, "re-use" of discriminators as that likely to pose security threat (DDoS).

A lot depends on how much we (i.e. BFD WG) want to do with S-BFD, and I'd like us to discuss a bit more on the topics of advertisements/s-bfd-uniqueness aspects. Rather this is the one of the last few strings holding down the S-BFD before it can really start flying :)

> . Section 8.1 suggests, when distinct pools of BFD and S-BFD discriminators
> used, that "My discriminator" must be always allocated from BFD pool.
> Would note that unless BFD and S-BFD pools made explicitly separated
> there's no, IMO, way to determine from which pool particular discriminator
> been allocated from. Thus node's own S-BFD discriminators must be
> punched out in BFD pool to prevent accidentally being allocated as My
> Discriminator. That seems to complicate things and relationship between
> BFD and S-BFD.

This was a very thoughtful question. This paragraph (second paragraph of section 8.1) requires a complete rewrite. Because of the S-BFD UDP port (or S-BFD Ach if we ever define one), there is no need to punch out local S-BFD discriminators in the BFD discriminator pool. That also means, if a classical BFD session or an SBFDInitiator happen to use a same discriminator value as locally allocated S-BFD discriminators, there is problem. In other words, as long as received BFD control packets are first demux'ed into SBFDReflector or (SBFDInitiator or classical BFD), then it's ok.

The second paragraph of section 8.1 will be replaced with:

   Every SBFDInitiator MUST have a locally unique "my discriminator"
   allocated from the BFD discriminator pool.

> . And to add to the issue of My Discriminator, I don't see anything that
> prevents R2 receiving pings from R1 and R2 in the same md, i.e. R1 and R4
> allocating the same discriminator from BFD pool to be used as My
> discriminator. Where the pong will go then? In light of this, I'm more in
> favor of nodes advertising discriminator(s) through IGP extensions (or being
> centrally allocated) explicitly as their My Discriminator

I'm not fully convinced that we need to go that length. Today (at least today), pong is IP routed, thus it can be demux'ed with destination of the packet (ex: IP address). If you agree, then I can add some texts for this.

> . And last but not least, it appears that document assumes that S-BFD
> capable node would always have BFD functionality supported. I think that
> not necessarily the case and S-BFD only node must be considered in the
> document. Thus, my question, if there's no BFD and BFD pool of
> discriminators, where from My Discriminator would be allocated for S-BFD?

Agree, this is addressed as part of 4th comment.

> . Section 8.1.1 may benefit from introduction of terms of "stateful initiator"
> and "stateless initiator" when characterizing different behavior of
> SBFDInitiator.

Good suggestion, will make the changes to this section using that terminology (and thanks for coming up with good terminology!).

Thanks!

-Nobo

P.S. Hopefully I can get to your other comments (s-bfd-ip) soon.

---

From: Gregory Mirsky <[email-masked]>
Date: Sun, 13 Jul 2014 05:00:18 +0000

Hi Nobo,
many thanks for taking time in such busy period before the meeting and your kind consideration of my notes.
I've clipped topics we've agreed on.
Couple more notes in-lined and tagged by GIM>>.  And on some I need extra time to think :)

	Best regards,
		Greg

-----Original Message-----
From: Nobo Akiya (nobo) [mailto:[email-masked]] 
Sent: Friday, July 11, 2014 3:08 PM
To: Gregory Mirsky; [email-masked]
Cc: [email-masked]
Subject: RE: draft-ietf-bfd-seamless-base 

Hi Greg,

Please see in-line.

[...]

> . Section 4 suggests that both S-BFD Initiator and Responder send 
> S-BFD control packets to the same well-known UDP port;

Specifically:

Agree?
GIM>> By the reference to RFC 5881 Initiator would use dynamic port number as its Source port. How would that scale? As you probably expected, I'd propose to use another well-known UDP port for pong. And the SBFDReflector then will follow RFC 5881 procedure in setting its UDP source port number.

> . Section 5, not clear why S-BFD discriminator appears to have 
> different uniqueness requirement depending of its use (discriminator 
> collision). I think that there should be consistency. There seems to 
> be disagreement between the first paragraph and the second that 
> requires AS uniqueness of S-BFD discriminators. Or "discriminator 
> collision" is not the same as "uniqueness"?

5.  S-BFD Discriminators

5.1.  Discriminator Pools

GIM>> Good plan and I like the tight text.

> . Section 5, second para discusses mis-connectivity case. True, it 
> easier to detect with IP data plane then with MPLS, whether IP or ACH 
> encapsulation (where PHP is not the only problem but label merge as 
> well). If S-BFD to be used as true Connectivity Verification tool, 
> then in all encapsulations source must be clearly identifiable. For 
> MPLS data plane it could be done with help of Source MEP-ID TLV as in 
> RFC 6428. Would note that even with strong requirement of AS/AD scope 
> of S-BFD discriminator there must be mechanism to detect and act upon, 
> e.g. drop or enter mis-connectivity error state, "re-use" of discriminators as that likely to pose security threat (DDoS).

> . Section 8.1 suggests, when distinct pools of BFD and S-BFD 
> discriminators used, that "My discriminator" must be always allocated from BFD pool.
> there's no, IMO, way to determine from which pool particular 
> discriminator been allocated from. Thus node's own S-BFD 
> discriminators must be punched out in BFD pool to prevent accidentally 
> being allocated as My Discriminator. That seems to complicate things 
> and relationship between BFD and S-BFD.

> . And to add to the issue of My Discriminator, I don't see anything 
> that prevents R2 receiving pings from R1 and R2 in the same md, i.e. 
> R1 and R4 allocating the same discriminator from BFD pool to be used 
> as My discriminator. Where the pong will go then? In light of this, 
> I'm more in favor of nodes advertising discriminator(s) through IGP 
> extensions (or being centrally allocated) explicitly as their My 
> Discriminator

> capable node would always have BFD functionality supported. I think 
> that not necessarily the case and S-BFD only node must be considered 
> in the document. Thus, my question, if there's no BFD and BFD pool of 

Thanks!

-Nobo

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sun, 13 Jul 2014 14:55:33 +0000

Hi Greg,

> Sent: Sunday, July 13, 2014 1:00 AM
> To: Nobo Akiya (nobo); [email-masked]
> Cc: [email-masked]

Likewise! And thanks for flushing out many quirks from the document!

> Couple more notes in-lined and tagged by GIM>>.  And on some I need extra

I'm preserving just the UDP source topic to progress discussion on that.

> GIM>> By the reference to RFC 5881 Initiator would use dynamic port
> number as its Source port. How would that scale? As you probably expected,
> I'd propose to use another well-known UDP port for pong. And the
> SBFDReflector then will follow RFC 5881 procedure in setting its UDP source
> port number.

I see what you mean. What I should have included in my previous comment was that source UDP port texts from RFC5881 should be modified for S-BFD as well.

[RFC5881]
   BFD Control packets MUST be transmitted in UDP packets with
   destination port 3784, within an IPv4 or IPv6 packet.  The source
   port MUST be in the range 49152 through 65535.  The same UDP source
   port number MUST be used for all BFD Control packets associated with
   a particular session.  The source port number SHOULD be unique among
   all BFD sessions on the system.

[S-BFD]
   A new UDP port is defined for the use of the S-BFD: TBD1.
   SBFDReflector session MUST listen for incoming S-BFD packets on the
   port TBD1.  SBFDInitiator sessions MUST transmit S-BFD packets with
   destination port TBD1.  The source port of the S-BFD packets
   transmitted by SBFDInitiator sessions MUST be in the range 49152
   through 65535.  The same UDP source port number MUST be used for all
   S-BFD packets associated with a particular SBFDInitiator session.
   The source port number MAY be unique among all SBFDInitiator sessions
   on the system.

Note: The last "SHOULD" changing to "MAY" is the key.

This will address the scale issue, and S-BFD pong packets are identified with "source port == TBD1", so similar hooks (ex: rate limiter) should still be possible. But we can go either way (i.e. above or having a separate well-known UDP port for pong). What would be beneficial is to have vendors think about this, and see which we prefer more.

Thanks!

-Nobo

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 14 Jul 2014 12:19:51 -0400

> GIM>> By the reference to RFC 5881 Initiator would use dynamic port number as its Source port. How would that scale? As you probably expected, I'd propose to use another well-known UDP port for pon…

There are two nice properties for the swap:
- The ability to use UDP port partially for demux.  (Yes, you should use
  discriminator but sometimes it's nice to get layer 4 to help.)
- Additional entropy for security considerations.  Not a *lot* of entropy
  but given we're already making discriminator values sticky in at least one
  direction we could use the help.  (Security considerations will plague
  this feature.)

-- Jeff

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 15 Jul 2014 16:27:44 +0000

Hi Jeff,
having additional knob to demux is certainly beneficial.  
As for entropy, I tend to think that swapping may not be the best instrument if our intention is to have both directions of S-BFD traverse the same ECMP links.  But then swapping is the least state-aware procedure to set UDP ports for a reflected S-BFD control packet. For that, I think, I can accept swapping.

	Regards,
		Greg

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Monday, July 14, 2014 9:20 AM
To: Gregory Mirsky
Cc: Nobo Akiya (nobo); [email-masked]; [email-masked]
Subject: Re: draft-ietf-bfd-seamless-base

-- Jeff

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 15 Jul 2014 10:48:54 -0700

Hello everyone,

bit behind with reading I found this ...

> - SBFDReflector is to swap source/destination ports when copying from ping 

Do I understand this right: initiator sends with S-BFD dst-port 7784 (not 
assigned yet) and src-port 50000 and you want to send the "pong" with 
dst-port 50000 and src-port 7784 ?

Why? Using the well-know S-BFD UDP port as destination port for all S-BFD 
packets seems straight forward. Why would my receiver logic need an 
additional clause "if the source-port is the S-BFD port" ?

Plus: another IP-ish detail I would argue to keep out of the base draft. It's 
just obfuscating the core aspects of S-BFD, IMHO.

>   discriminator but sometimes it's nice to get layer 4 to help.)

maybe but again this is "IP heavy" for a base draft. These details maybe all 
worthwhile but should be in the IP-specific draft.

>   direction we could use the help.  (Security considerations will plague

you could use the UDP src port for the entropy, e.g. for filtering. "I sent 
out with src-port X and will only accept a packet with src-port X"

Apropos security, taking the "real thing" aside and using proper 
authentication (*), ever thought about using the echo field as a "nonce" 
similar to what LISP is doing?  You send out the packet with a random 32bit 
nonce and accept the pong only when the nonce is what you have sent out.
For hardware implementation of the filtering you could keep the nonce fixed 
for N seconds.

(*: problem is if the hardware supports the authentication, otherwise it just 
adds more load on the software plane)

Regards, Marc

On Mon, 14 Jul 2014 12:19:51 -0400, Jeffrey Haas wrote:
>> GIM>> By the reference to RFC 5881 Initiator would use dynamic port number 
>> as its Source port. How would that scale? As you probably expected, I'd 
>> propose to use another well-known UDP port for pong. And the SBFDReflector 
>> then will follow RFC 5881 procedure in setting its UDP source port number.
>

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 15 Jul 2014 11:56:15 -0700

Hello Nobo and Greg,

reading your interesting conversation :-)

> This was a very thoughtful question. This paragraph (second paragraph of 
> section 8.1) requires a complete rewrite. Because of the S-BFD UDP port (or 
> S-BFD Ach if we ever define one), there is no need to punch out local S-BFD 
> discriminators in the BFD discriminator pool. That also means, if a 
> classical BFD session or an SBFDInitiator happen to use a same 
> discriminator value as locally allocated S-BFD discriminators, there is 
> problem. In other words, as long as received BFD control packets are first 
> demux'ed into SBFDReflector or (SBFDInitiator or classical BFD), then it's 
> ok.

Not sure I follow this.

I think what is required is a MUST clause in the draft that the upper layer 
provides the information that the packet is a S-BFD packet. The whole idea of 
separate pools can only work when either these pools have no numerical 
overlap; then you can use the normal demux based on the discriminator for all 
BFD packets. Or if the pools have an overlap you need the "hint" from upper 
layer and S-BFD packets MUST use the S-BFD pool to interpret discriminators.

As you mentioned the upper layer information for IP it's the UDP port, for 
MPLS-ish use it could be some new (G)ACH code point and so on.

>   allocated from the BFD discriminator pool.

How will your demux logic for an incoming packet then look like? You look 
into the BFD pool? But this makes sense only for the "pong" packet: your 
incoming packet is an S-BFD packet, so what happens when the particular 
router is also a reflector and the BFD pool discriminator value is identical 
with your entity discriminator - how do I know what to do?

> Good suggestion, will make the changes to this section using that 
> terminology (and thanks for coming up with good terminology!).

I would propose - as already discussed - to move this into an appendix. It's 
useful information but IMO it's an implementation example and is not relevant 
to define S-BFD.

This is of course based on my assumption that the S-BFD definition is not 
trying to impose a particular state machine - I don't see why we want to do 
this if we don't need to do it.

Regards, Marc

On Fri, 11 Jul 2014 22:08:30 +0000, Nobo Akiya (nobo) wrote:
> The authors certainly placed good effort to roll out this -01, but that was 
> possible largely due to many great comments on/off the list. So thanks and 
> congratulations to all!
> 
>> Please find my notes and
>> editorial nits below:
> True, scanning the document we can do s/connectivity/continuity/ in most 
> places, and do s/connectivity/reachability/ in couple of places. ACK, in 
> todo list for the next revision.
> 
> Right, "internal discriminator collision" is different than "S-BFD 
> discriminator uniqueness within an administrative domain".
> 
> And re-thinking about the discriminator pool rules (along with your 2nd 
> from last comment below), they should be described as:
> 
> A lot depends on how much we (i.e. BFD WG) want to do with S-BFD, and I'd 
> like us to discuss a bit more on the topics of 
> advertisements/s-bfd-uniqueness aspects. Rather this is the one of the last 
> few strings holding down the S-BFD before it can really start flying :)
> 
> This was a very thoughtful question. This paragraph (second paragraph of 
> section 8.1) requires a complete rewrite. Because of the S-BFD UDP port (or 
> S-BFD Ach if we ever define one), there is no need to punch out local S-BFD 
> discriminators in the BFD discriminator pool. That also means, if a 
> classical BFD session or an SBFDInitiator happen to use a same 
> discriminator value as locally allocated S-BFD discriminators, there is 
> problem. In other words, as long as received BFD control packets are first 
> demux'ed into SBFDReflector or (SBFDInitiator or classical BFD), then it's 
> ok.
> 
> I'm not fully convinced that we need to go that length. Today (at least 
> today), pong is IP routed, thus it can be demux'ed with destination of the 
> packet (ex: IP address). If you agree, then I can add some texts for this.
> 
> Good suggestion, will make the changes to this section using that 
> terminology (and thanks for coming up with good terminology!).
> 
> Thanks!
> 
> -Nobo
>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 16 Jul 2014 00:09:41 +0000

Hi Greg, Jeff, et al,

> Sent: Tuesday, July 15, 2014 12:28 PM
> To: Jeffrey Haas
> As for entropy, I tend to think that swapping may not be the best instrument
> if our intention is to have both directions of S-BFD traverse the same ECMP
> links.  But then swapping is the least state-aware procedure to set UDP ports
> for a reflected S-BFD control packet. For that, I think, I can accept swapping.

That's two big votes to push this closer to closure :)

As far as same ECMP links go, as much as I wish, I don't think we can achieve that even if we preserved same UDP dst/src ports in ping/pong S-BFD packets. IP addresses, dst/src, will be different, and sometimes implementations take incoming interface identifier into account. So unfortunately, that won't guarantee the trick.

>   direction we could use the help.  (Security considerations will plague

Yes I agree that it does add a bit more security improvements.

Thanks!

-Nobo

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 16 Jul 2014 00:47:07 +0000

Hi Marc,

> From: Marc Binderberger [mailto:[email-masked]]
> Sent: Tuesday, July 15, 2014 1:49 PM
> To: Jeffrey Haas; Gregory Mirsky; Nobo Akiya (nobo)
> Cc: [email-masked]; [email-masked]
> assigned yet) and src-port 50000 and you want to send the "pong" with dst-
> port 50000 and src-port 7784 ?

Correct, at least that's the proposals on the table.

> additional clause "if the source-port is the S-BFD port" ?

To explain this reason, we need to start with S-BFD discriminators for SBFDReflector sessions.

We _want_ to be able to preserve the ability to be flexible with the S-BFD discriminator values we allocate for local entities. To achieve this, S-BFD base document will describe following two rules in the next revision (thank Greg for solidifying this).

   This document defines following rules for discriminator management on
   SBFDInitiator and SBFDReflector sessions, to minimize the collision
   between required S-BFD discriminators on a local device.

   o  SBFDInitiator is to allocate a discriminator from the BFD
      discriminator pool.  If the system also supports classical BFD
      that runs on [RFC5880], then the BFD discriminator pool MUST be
      shared by SBFDInitiator sessions and classical BFD sessions.

If we were to do this with a single discriminator pool, then we lose the flexibility to allocate various S-BFD discriminator values for local entities as many values may already being used by SBFDInitiator sessions and classical BFD sessions. So two discriminator tables.

Now, in order to look up the correct session object, we need to first identify whether an incoming S-BFD packet is for SBFDReflector sessions or other BFD sessions (i.e. SBFDInitiator sessions and classical BFD sessions) so that correct discriminator table can be accessed with "your discriminator".

If S-BFD packets from both SBFDInitiator and SBFDReflector had destination port of 7784, then we will not be able to determine which discriminator table to look up. Hence the UDP port swap by SBFDReflector sessions. Alternative is to allocate well-known UDP port in one direction (i.e. SBFDInitiator to SBFDReflector) and different well-known UDP port in the other direction (i.e. SBFDReflector to SBFDInitiator).

> just obfuscating the core aspects of S-BFD, IMHO.

I'm willing to re-structure S-BFD document if WG consensus points that way :)

Please take a look at two possible document structures.

http://www.ietf.org/proceedings/90/slides/slides-90-bfd-2.pptx

As for IP-less, we could have [new] S-BFD associated channel type in one direction, and reuse [existing] BFD associated channel type in the other direction. That will also achieve differentiating of SBFDReflector sessions and other BFD sessions.

Thanks!

- Nobo

> >> - SBFDReflector is to swap source/destination ports when copying from
> ping
> >> to pong.
> >>
> >> Agree?
> number

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 16 Jul 2014 00:57:01 +0000

Hi again Marc,

> Sent: Tuesday, July 15, 2014 2:56 PM
> To: Nobo Akiya (nobo); Gregory Mirsky
> Cc: [email-masked]; [email-masked]; Marc
> Binderberger (mbinderb)
> > This was a very thoughtful question. This paragraph (second paragraph
> > of section 8.1) requires a complete rewrite. Because of the S-BFD UDP
> > port (or S-BFD Ach if we ever define one), there is no need to punch
> > out local S-BFD discriminators in the BFD discriminator pool. That
> > also means, if a classical BFD session or an SBFDInitiator happen to
> > use a same discriminator value as locally allocated S-BFD
> > discriminators, there is problem. In other words, as long as received
> > BFD control packets are first demux'ed into SBFDReflector or
> > (SBFDInitiator or classical BFD), then it's ok.
> 
> Not sure I follow this.
> 
> provides the information that the packet is a S-BFD packet. The whole idea
> of separate pools can only work when either these pools have no numerical
> overlap; then you can use the normal demux based on the discriminator for
> all BFD packets. Or if the pools have an overlap you need the "hint" from
> upper layer and S-BFD packets MUST use the S-BFD pool to interpret
> discriminators.
> 

Correct. Please see my response in the other email.

> with your entity discriminator - how do I know what to do?

Exactly, hence we need to demux first between S-BFD discriminator pool lookup vs. BFD discriminator pool lookup.

> this if we don't need to do it.

What state is set by SBFDReflector in sending S-BFD packets is one of the topics in the S-BFD update at Toronto.

Once there's a consensus on the behavior, then we can update the document accordingly.

Thanks!

-Nobo

> discriminators
> discriminator

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 15 Jul 2014 19:47:30 -0700

Hello Nobo,

ah, thanks for the explanation! Makes sense. But I disagree (surprise!). 
Maybe it's just me :-)

Anyway, it brings up several aspects that are probably important for the 
design:

* the discriminator pools. Do we really need two pools and the complexity 
that comes with them?

The new pool should help to reduce collisions. But it cannot prevent them, so 
collisions need to be addressed anyway. I do see the advantage by reducing 
collisions to the S-BFD domain as we have the chance to define collision 
resolution as a requirement, something we cannot do for all 588x anymore (or 
maybe we can?). Still we should re-think if all the complexity of a new pool 
is worth it.

* if we go with a separate pool, does it then makes sense to "muddy the 
water" and mix it with the existing BFD pool on the Initiator side? Would a 
ships-in-the-night S-BFD not more favorable where everything of S-BFD is 
separated from 588x-BFD, including the pool? Would be a simple design 
guideline.

You mention

> We _want_ to be able to preserve the ability to be flexible with the S-BFD 
> discriminator values we allocate for local entities.

have to ask: why? With flexible you mean the choice between BFD pool and 
S-BFD pool for the my-discriminator for a system that has the S-BFD pool 
implemented? What does this flexibility buy you?

The draft being flexible for an implementor to use a shared pool 
(exclusive-)or to implement two separate and potentially overlapping pools - 
okay. I think your draft allows already both and it's a local matter, not 
affecting interop.

(Yes, we do talk about separate things ;-) as I mean "separate pool" strictly 
separated. You have to extend your lookup with the "hint" from lower layer 
(IP, MPLS-TP, ...) and the "hint", e.g. the UDP dst-port or ACK for S-BFD, is 
always used. S-BFD would never use the 588x pool)

> As for IP-less, we could have [new] S-BFD associated channel type in one 
> direction, and reuse [existing] BFD associated channel type in the other 
> direction. That will also achieve differentiating of SBFDReflector sessions 
> and other BFD sessions.

I was wondering about this :-) So for IP/UDP we design the S-BFD base draft 
with the help of this additional degree of freedom that we can swap source 
and destination port but still know it's BFD (because the src-port is S-BFD 
port). For IP-less we reuse the existing ACH. The IP/UDP equivalent we should 
discuss then is using 3784 or 4784 as dst-port for the reflected packet.

Which technically should be do-able but it also opens the discussion (again) 
if RFC 588x allows this or that.

Personally I think mixing 588x-BFD with S-BFD is a burden unless you go to 
the extremes, which keeps is fairly clean: one pool, lookup as it exists 
already. Or two pools, strictly separated by the UDP/ACH hint of 588x-BFD vs 
S-BFD. S-BFD port as UDP dst-port in all cases for S-BFD packets, both 
Initiator and Reflector.

> http://www.ietf.org/proceedings/90/slides/slides-90-bfd-2.pptx

Hey, you have been quite active it seems ;-)
Thanks for the slides, I'll give them a look this evening.

Thanks & Regards,
Marc

On Wed, 16 Jul 2014 00:47:07 +0000, Nobo Akiya (nobo) wrote:
>>> ping to pong.
> We _want_ to be able to preserve the ability to be flexible with the S-BFD 
> discriminator values we allocate for local entities. To achieve this, S-BFD 
> base document will describe following two rules in the next revision (thank 
> Greg for solidifying this).
> 
> If we were to do this with a single discriminator pool, then we lose the 
> flexibility to allocate various S-BFD discriminator values for local 
> entities as many values may already being used by SBFDInitiator sessions 
> and classical BFD sessions. So two discriminator tables.
> 
> Now, in order to look up the correct session object, we need to first 
> identify whether an incoming S-BFD packet is for SBFDReflector sessions or 
> other BFD sessions (i.e. SBFDInitiator sessions and classical BFD sessions) 
> so that correct discriminator table can be accessed with "your 
> discriminator".
> 
> If S-BFD packets from both SBFDInitiator and SBFDReflector had destination 
> port of 7784, then we will not be able to determine which discriminator 
> table to look up. Hence the UDP port swap by SBFDReflector sessions. 
> Alternative is to allocate well-known UDP port in one direction (i.e. 
> SBFDInitiator to SBFDReflector) and different well-known UDP port in the 
> other direction (i.e. SBFDReflector to SBFDInitiator).
> 
>> 
> As for IP-less, we could have [new] S-BFD associated channel type in one 
> direction, and reuse [existing] BFD associated channel type in the other 
> direction. That will also achieve differentiating of SBFDReflector sessions 
> and other BFD sessions.
> 
> Thanks!
> 
> - Nobo
> 
>> 
>>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 16 Jul 2014 23:20:44 +0000

Hi Marc,

> Sent: Tuesday, July 15, 2014 10:48 PM
> To: Nobo Akiya (nobo)
> Cc: Jeffrey Haas; Gregory Mirsky; draft-ietf-bfd-seamless-
> [email-masked]; [email-masked]; Marc Binderberger (mbinderb)

Haha. Well, everyone's views are important to steer where we going to converge to, so let's continue :)

> The new pool should help to reduce collisions. But it cannot prevent them,
> so collisions need to be addressed anyway. I do see the advantage by
> reducing collisions to the S-BFD domain as we have the chance to define
> collision resolution as a requirement, something we cannot do for all 588x
> anymore (or maybe we can?). Still we should re-think if all the complexity
> of a new pool is worth it.

Personally I think separate discriminator pool is strongly desired and is worth it.
(1) Collision between S-BFD discriminators and (2) collision between S-BFD and other BFD sessions can be two different things.
More complexity will come from needing to handle (2).

Additionally, you and me have discussed a possibility of reserving some S-BFD discriminator values.
That would be another reason why separate discriminator pool is worth the effort.

> separated from 588x-BFD, including the pool? Would be a simple design

The way I see this:
- BFD discriminator pool is for all sessions that can be assigned an arbitrary discriminator.
- S-BFD discriminator pool is for all sessions that may have rules on how discriminator value is derived.

So placing SBFDInitiator sessions in the BFD discriminator pool along with classical sessions make sense me.

> 
> 
> You mention
> 
> > We _want_ to be able to preserve the ability to be flexible with the
> > S-BFD discriminator values we allocate for local entities.
> 
> The draft being flexible for an implementor to use a shared pool (exclusive-
> )or to implement two separate and potentially overlapping pools - okay. I
> think your draft allows already both and it's a local matter, not affecting
> interop.

By "flexibility" I mean flexibility to use attribute Foobar of the local entity to derive the discriminator value to reserve in the S-BFD discriminator pool.
For example, Router-ID is used to derive the discriminator value, and that is reserved in the S-BFD discriminator pool.

> always used. S-BFD would never use the 588x pool)

I'm pretty sure you meant ACh and not ACK, yes?

If so, then yes that's correct.

> 
> 
> > As for IP-less, we could have [new] S-BFD associated channel type in
> > one direction, and reuse [existing] BFD associated channel type in the
> > other direction. That will also achieve differentiating of
> > SBFDReflector sessions and other BFD sessions.
> 
> port).

Yes.

> For IP-less we reuse the existing ACH. The IP/UDP equivalent we
> should discuss then is using 3784 or 4784 as dst-port for the reflected packet.

Yes.

> S-BFD. S-BFD port as UDP dst-port in all cases for S-BFD packets, both

Well, I'm sure if I see it that way. Existing code (i.e. classical BFD) can remain the same. Implementations need to add code for SBFDInitiator and SBFDReflector, which, one pool or two, will be fairly similar in terms of code churns required. As for "cleanness", given the definition of discriminator pools above, I think it's still clean, but I'm very biased :)

Thanks!

-Nobo

> > I'm willing to re-structure S-BFD document if WG consensus points that
> way
> > :)
> >

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 18 Jul 2014 10:37:05 -0400

> More complexity will come from needing to handle (2).

But distinguished already via UDP dest port.

This is one of those things like how label assignment is done in MPLS that
largely should be an implementation detail.

I suspect some implementations will do pools, but you need not be able to
tell from the outside.  The complicating factor, of course, being if you
assign your discriminator and your implementation needs unique ones and
making sure that you don't have a collision from dynamic discriminator
assignment in regular BFD.

-- Jeff

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 18 Jul 2014 23:05:41 +0000

> Sent: Friday, July 18, 2014 10:37 AM
> To: Nobo Akiya (nobo)
> Cc: Marc Binderberger; Jeffrey Haas; Gregory Mirsky; draft-ietf-bfd-
> [email-masked]; [email-masked]; Marc Binderberger
> (mbinderb)
> > (1) Collision between S-BFD discriminators and (2) collision between S-
> BFD and other BFD sessions can be two different things.
> tell from the outside.  The complicating factor, of course, being if you assign
> your discriminator and your implementation needs unique ones and making
> sure that you don't have a collision from dynamic discriminator assignment
> in regular BFD.

That aligns with my thought. And to accommodate the comment about "... some implementations will do ...", "MUST" is no longer used in the text that describes discriminator pool, and the word "rule" has been replaced with "suggestion".  Here's the proposal text for the next revision.

5.1.  Discriminator Pools

   This document defines following suggestions for discriminator
   management on SBFDInitiator and SBFDReflector sessions, to minimize
   the collision between required S-BFD discriminators on a local
   device.

   o  SBFDInitiator is to allocate a discriminator from the BFD
      discriminator pool.  If the system also supports classical BFD
      that runs on [RFC5880], then the BFD discriminator pool SHOULD be
      shared by SBFDInitiator sessions and classical BFD sessions.

   Remainder of this subsection describes the reasons for above
   suggestions.

   Locally allocated S-BFD discriminator values for entities, listened
   by SBFDReflector sessions, may be arbitrary allocated or derived from
   values provided by applications.  These values may be protocol IDs
   (ex: System-ID, Router-ID) or network targets (ex: IP address).  To
   avoid derived S-BFD discriminator values already being assigned to
   other BFD sessions (i.e.  SBFDInitiator sessions and classical BFD
   sessions), it is RECOMMENDED that discriminator pool for
   SBFDReflector sessions be separate from other BFD sessions.

   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 (ex: 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.

Thanks!

-Nobo