Subject: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)

From: "MALLIK MUDIGONDA (mmudigon)" <[email-masked]>
Date: Fri, 7 Mar 2014 12:58:11 +0000

Hi,

Loop prevention
===============

Description:

Consider a scenario where we have two nodes and both are S-BFD capable.

     Node A (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2)
				|
				|
			 Man in the Middle (MiM)

Node A reserved discriminator 0x01010101 and will have a reflector session
in listening mode. Similarly Node B reserved discriminator 0x02020202 for
its reflector session.

Suppose MiM sends a spoofed packet with MyDisc = 0x01010101, YourDisc =
0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.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 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 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.

Solutions
=========

The current proposals are:

	1.	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.

	2.	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 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.

	3.	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.

Please share your thoughts on the proposals.

Thanks

Regards
Mallik

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sat, 8 Mar 2014 18:46:16 +0000

Hi Mallik, et al,

My preference:

1 > 2 > 3

Reasons:

[3] Deviating discriminator by reflector session - Proposed will prevent a single S-BFD session to speak to multiple reflectors (cannot do reply demux'ing), if implementation wants to do this or if there is ever such use-case.

[2] State - No strong opposition here, but just looks cleaner for S-BFD initiator to reflect session state in state field of packets sent.
 
[1] D bit - I can't think of any reason why S-BFD initiator wants to set D bit in packet to reflector session that is stateless. If S-BFD initiator is not interested in receiving back any response, S-BFD initiator can simply "not send". Thus, there is no issue with changing the meaning of D bit in S-BFD context.

-Nobo

> -----Original Message-----
> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of MALLIK
> MUDIGONDA (mmudigon)
> Sent: Friday, March 07, 2014 7:58 AM
> To: [email-masked]
> Subject: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)
> 
> 
> Hi,
> 
> Loop prevention
> ===============
> 
> Description:
> 
> Suppose MiM sends a spoofed packet with MyDisc = 0x01010101, YourDisc
> = 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When this packet
> 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
> FYI: Packet fields do not carry any direction information, i.e., if this is Ping
> packet or reply packet.
> 
> Solutions
> =========
> 
> 		Initiator always sets the 'D' bit and reflector clears it. This
> way we can identify if a received packet was a reflected packet
> 	     	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 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.
> 
> 		Reflector will always fill in My Discriminator with a locally
> allocated discriminator value (not reserved discriminators) and will

---

From: Gregory Mirsky <[email-masked]>
Date: Sat, 8 Mar 2014 21:42:50 +0000

Dear Mallik, et. al,
apologies for being terribly behind on processing mail queue.
I was to propose use of another well-known UDP port for S-BFD but then I looked closer at RFC 5881. I think that we may use UDP source port of S-BFD packet received by a reflector as UDP destination  port in reflected packet to break the spoofed loop. If not that, then Option #1 but with new version (I think we'll need new version # anyway).

	Regards,
		Greg

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Saturday, March 08, 2014 10:46 AM
To: MALLIK MUDIGONDA (mmudigon); [email-masked]
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)

Hi Mallik, et al,

My preference:

1 > 2 > 3

Reasons:

 

-Nobo

> Node A reserved discriminator 0x01010101 and will have a reflector 
> session in listening mode. Similarly Node B reserved discriminator 
> 0x02020202 for its reflector session.
> 
> = 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When this 
> packet reaches Node B, the reflector session on Node B will swap the 
> have
> 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 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.
> 
> Solutions
> =========
> 
> 		Initiator always sets the 'D' bit and reflector clears it. This way 
> we can identify if a received packet was a reflected packet

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sun, 9 Mar 2014 13:32:33 +0000

Hi Mallik, Greg, [S-]BFDers,

Please see in-line.

> From: Gregory Mirsky [mailto:[email-masked]]
> Sent: Saturday, March 08, 2014 4:43 PM
> To: Nobo Akiya (nobo); MALLIK MUDIGONDA (mmudigon); [email-masked]
> I was to propose use of another well-known UDP port for S-BFD but then I
> looked closer at RFC 5881.

S-BFD proposes to use a new well-known UDP port (starting from base-02 ... sorry doc is still not very clear, but we've done major facelift on -03, which is to be submitted after loop/security discussions). And since different UDP ports, even if were to change meaning of some fields of BFD control header (ex: D bit interpretation), I don't feel that up versioning is absolutely required. We could, but we could also avoid.

> I think that we may use UDP source port of S-
> BFD packet received by a reflector as UDP destination  port in reflected
> packet to break the spoofed loop.

Regarding usage of source UDP port to break the loop, true that's another possibility. This should definitely be listed as one of the options. It would require that (dest UDP port != src UDP port) ... and solution is outside of BFD control header (do we ever want to do IP-less?).

> If not that, then Option #1 but with new
> version (I think we'll need new version # anyway).

I'm glad to see that you also prefer option #1. I recommend we move forward with this, but list all other options in the appendix and keep the discussion open for BFDers to comment/discuss further. Mallik, Greg, [S-]BFDers, what do you think?

-Nobo

> [3] Deviating discriminator by reflector session - Proposed will prevent a
> single S-BFD session to speak to multiple reflectors (cannot do reply
> demux'ing), if implementation wants to do this or if there is ever such use-
> case.
> 
> [2] State - No strong opposition here, but just looks cleaner for S-BFD
> initiator to reflect session state in state field of packets sent.
> 
> [1] D bit - I can't think of any reason why S-BFD initiator wants to set D bit
> in packet to reflector session that is stateless. If S-BFD initiator is not
> interested in receiving back any response, S-BFD initiator can simply "not
> send". Thus, there is no issue with changing the meaning of D bit in S-BFD
> context.
> 
> -Nobo
> 
> way

---

From: Santosh P K <[email-masked]>
Date: Sun, 9 Mar 2014 15:47:56 +0000

I prefer D-bit option too. Simply because it is clean. D-bit loses its meaning in S-BFD context and I don't think it will be used. Only question is do we need to come up with a new version to use D-bit? 

Thanks
Santosh P K  

> Sent: Sunday, March 09, 2014 7:03 PM
> To: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); [email-masked]
> > I was to propose use of another well-known UDP port for S-BFD but then
> > I looked closer at RFC 5881.
> 
> S-BFD proposes to use a new well-known UDP port (starting from base-02 ...
> sorry doc is still not very clear, but we've done major facelift on -03, which is to
> be submitted after loop/security discussions). And since different UDP ports,
> even if were to change meaning of some fields of BFD control header (ex: D bit
> interpretation), I don't feel that up versioning is absolutely required. We could,
> but we could also avoid.
> 
> > I think that we may use UDP source port of S- BFD packet received by a
> > reflector as UDP destination  port in reflected packet to break the
> > spoofed loop.
> 
> Regarding usage of source UDP port to break the loop, true that's another
> possibility. This should definitely be listed as one of the options. It would require
> that (dest UDP port != src UDP port) ... and solution is outside of BFD control
> header (do we ever want to do IP-less?).
> 
> > If not that, then Option #1 but with new version (I think we'll need
> > new version # anyway).
> 
> I'm glad to see that you also prefer option #1. I recommend we move forward
> with this, but list all other options in the appendix and keep the discussion open
> for BFDers to comment/discuss further. Mallik, Greg, [S-]BFDers, what do you
> think?
> 
> -Nobo
> 
> >
> > 	Regards,
> > 		Greg
> >
> > From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo
> > Akiya
> > (nobo)
> > [3] Deviating discriminator by reflector session - Proposed will
> > prevent a single S-BFD session to speak to multiple reflectors (cannot
> > do reply demux'ing), if implementation wants to do this or if there is
> > ever such use- case.
> >
> > [2] State - No strong opposition here, but just looks cleaner for
> > S-BFD initiator to reflect session state in state field of packets sent.
> >
> > [1] D bit - I can't think of any reason why S-BFD initiator wants to
> > set D bit in packet to reflector session that is stateless. If S-BFD
> > initiator is not interested in receiving back any response, S-BFD
> > initiator can simply "not send". Thus, there is no issue with changing
> > the meaning of D bit in S-BFD context.
> >
> > -Nobo
> >
> > > 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
> > > Since reflectors MUST set the TTL of the reflected packets to 255,
> > > the above scenario will result in an infinite loop with just one
> > > malicious packet injected from MiM.
> > >

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sun, 9 Mar 2014 23:32:13 +0000

Hi Santosh,

Seamless BFD uses a new UDP port and that should be good enough to overload the D bit. I don't  think we should be revising the version number -- at least not based on what I have heard till now.

Cheers, Manav

> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Santosh P
> K
> Sent: Sunday, March 09, 2014 9:18 PM
> To: Nobo Akiya (nobo); Gregory Mirsky; MALLIK MUDIGONDA (mmudigon);
> [email-masked]
> I prefer D-bit option too. Simply because it is clean. D-bit loses its
> meaning in S-BFD context and I don't think it will be used. Only
> question is do we need to come up with a new version to use D-bit?
> 
> Thanks
> Santosh P K
>

---

From: "MALLIK MUDIGONDA (mmudigon)" <[email-masked]>
Date: Mon, 10 Mar 2014 06:19:01 +0000

Hi,

Good that we have some consensus to use D bit as the option. We will update the draft 03 with this and also list all other options discussed in the appendix so that all are aware of these. We will include the UDP port based solution suggested by Greg also.

Thanks

Regards
Mallik

From: <Bhatia>, "Manav (Manav)" <[email-masked]<mailto:[email-masked]>>
Date: Monday 10 March 2014 5:02 AM
To: Santosh P K <[email-masked]<mailto:[email-masked]>>, "Nobo Akiya (nobo)" <[email-masked]<mailto:[email-masked]>>, Gregory Mirsky <[email-masked]<mailto:[email-masked]>>, Cisco Employee <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)

Hi Santosh,

Cheers, Manav

-----Original Message-----
[email-masked]<mailto:[email-masked]>
Akiya
> To: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); [email-masked]<mailto:[email-masked]>
> > To: Nobo Akiya (nobo); MALLIK MUDIGONDA (mmudigon); rtg-
[email-masked]<mailto:[email-masked]>
> > To: MALLIK MUDIGONDA (mmudigon); [email-masked]<mailto:[email-masked]>
> > > To: [email-masked]<mailto:[email-masked]>

---

From: "MALLIK MUDIGONDA (mmudigon)" <[email-masked]>
Date: Mon, 10 Mar 2014 06:42:42 +0000

Hi Greg,

Yes, using source UDP port would be one of the options. But I have a question here. Is it mandatory that we carry the Well Known UDP port (yet to be allocated for SBFD) as destination port in all packets including the reflected ones? If yes, then we cannot swap the UDP ports but should use well known UDP port as destination and a local port as source port when reflecting packets back to the initiator. In such a case the initiator will not be able to use this to break the loop. Am I missing something?

Thanks

Regards
Mallik

From: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Sunday 9 March 2014 3:12 AM
To: "Nobo Akiya (nobo)" <[email-masked]<mailto:[email-masked]>>, Cisco Employee <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)

Dear Mallik, et. al,

Regards,
Greg

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Saturday, March 08, 2014 10:46 AM
To: MALLIK MUDIGONDA (mmudigon); [email-masked]<mailto:[email-masked]>
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)

Hi Mallik, et al,

My preference:

1 > 2 > 3

Reasons:

-Nobo

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 10 Mar 2014 06:49:57 +0000

Hi Mallik,

You can check for UDP ports only if a well known UDP port is NOT assigned to S-BFD.

The current draft proposes using a well known UDP port. In that case we will use the "D" bit to avoid the loop.

Cheers, Manav

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of MALLIK MUDIGONDA (mmudigon)
Sent: Monday, March 10, 2014 12:13 PM
To: Gregory Mirsky; Nobo Akiya (nobo); [email-masked]
Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)

Hi Greg,

Thanks

Regards
Mallik

Dear Mallik, et. al,

Regards,
Greg

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Saturday, March 08, 2014 10:46 AM
To: MALLIK MUDIGONDA (mmudigon); [email-masked]<mailto:[email-masked]>
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)

Hi Mallik, et al,

My preference:

1 > 2 > 3

Reasons:

-Nobo

-----Original Message-----
1.
Overload "D" bit (Demand mode bit).
2.
Use of State field in the BFD control packets:

3.
Use of local discriminator as My Disc at reflector:

---

From: "MALLIK MUDIGONDA (mmudigon)" <[email-masked]>
Date: Mon, 10 Mar 2014 06:55:02 +0000

Hi Nobo,

My replies inline

Regards
Mallik

From: "Nobo Akiya (nobo)" <[email-masked]<mailto:[email-masked]>>
Date: Sunday 9 March 2014 12:16 AM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)

Hi Mallik, et al,

My preference:

1 > 2 > 3

Reasons:

Mallik Even in this case, Reflectors need not use different discriminators for different initiators. They can still use the same discriminator for all reflected packets. Is there a problem here? The other point about reply demuxing, even the base BFD draft specifies that myDisc can change for a session and that yourDisc should be used for de-multiplexing. Am I missing some point?

-Nobo

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Mon, 10 Mar 2014 07:23:45 +0000

Hello Manav/ all,
  I beg to differ here - while BFD relies on using UDP port numbers to demux packet types (Async or Echo), there is currently no notion of interpreting bits differently based on UDP destination port numbers. IMHO, it may be cleaner to consider defining a packet format of S-BFD Async afresh instead of re-defining BFD Async [RFC5880], while still using the UDP destination port to demux the packet type. This could provide an opportunity to revisit the entire Async header to reclaim/ add additional bit(s). Two candidates could be (a) the M bit which was intended for P2MP sessions (the Initiator ->Reflector model proposed by S-BFD is already MP2P) (b) the RequiredMinEchoRxInterval given that S-BFD defines Async only. 
PS> The above two candidates are mere examples to make the case for redefining the header and not proposals by themselves.
Thanks
Prasad

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: Monday, March 10, 2014 5:02 AM
To: Santosh P K; Nobo Akiya (nobo); Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); [email-masked]
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)

Hi Santosh,

Cheers, Manav

> [email-masked]
> > sorry doc is still not very clear, but we've done major facelift on 
> > -
> 03, which is to
> > > reflector as UDP destination  port in reflected packet to break 
> > > the spoofed loop.
> >
> > for BFDers to comment/discuss further. Mallik, Greg, [S-]BFDers, 
> > what
> do you
> > think?
> >
> > -Nobo
> >
> > >
> > > 	Regards,
> > > 		Greg
> > >
> > > do reply demux'ing), if implementation wants to do this or if 
> > > there
> is
> > > ever such use- case.
> > >
> > > > 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.

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 10 Mar 2014 12:18:18 +0000

Hi Mallik, et. al,
I'd assume that S-BFD Sender, node that initiates S-BFD session, would use dynamic UDP port as its UDP source port while UDP destination port required to be set to well-known value. RFC 5880 doesn't make firm requirements on use of UDP source port number. I think that recommendations made in the RFC 5880 are quite favorable for S-BFD and can be re-used. Use of S-BFD well-known UDP port as source by Reflector seemed reasonable to me but we can certainly discuss if it useful.
But I think that there might be one aspect of selection of UDP ports that I'd like to discuss. In many sets of OAM Requirements we find requirement to ensure OAM being in-band with user traffic. That is problematic if there's ECMP. Hence my question, would we take upon S-BFD in-band requirement or leave it out of scope of base specification. I'm raising this question since UDP port numbers, destination and source, usually used to produce hash for ECMP distribution.

                Regards,
                                Greg

From: MALLIK MUDIGONDA (mmudigon) [mailto:[email-masked]]
Sent: Sunday, March 09, 2014 11:43 PM
To: Gregory Mirsky; Nobo Akiya (nobo); [email-masked]
Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)

Hi Greg,

Thanks

Regards
Mallik

Dear Mallik, et. al,

Regards,
Greg

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Saturday, March 08, 2014 10:46 AM
To: MALLIK MUDIGONDA (mmudigon); [email-masked]<mailto:[email-masked]>
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)

Hi Mallik, et al,

My preference:

1 > 2 > 3

Reasons:

-Nobo

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 10 Mar 2014 13:17:54 +0000

Hi Mallik,

Please see inline.

> From: MALLIK MUDIGONDA (mmudigon)
> Sent: Monday, March 10, 2014 2:55 AM
> To: Nobo Akiya (nobo); [email-masked]
> From: "Nobo Akiya (nobo)" <[email-masked]>
> To: Cisco Employee <[email-masked]>, "[email-masked]" <rtg-
> [email-masked]>
> Mallik Even in this case, Reflectors need not use different discriminators for
> different initiators. They can still use the same discriminator for all
> reflected packets. Is there a problem here? The other point about reply
> demuxing, even the base BFD draft specifies that myDisc can change for a
> session and that yourDisc should be used for de-multiplexing. Am I missing
> some point?

If a single initiator is to talk to multiple reflectors (a, b, c), then my_discrim (x) may be the same for BFD packets sent to (a, b, c). When reply from reflectors come back, then your_discrim cannot be used to demux as it will be the same (x). Other demux candidates are source IP and dest UDP in the reply ... but I was pointing out that if reply had my_discrim as (a, b, c), then that can be used to demux. Of course emphasis on "... if implementations wants to do this or if there is ever such use-case".

-Nobo
 
> [1] D bit - I can't think of any reason why S-BFD initiator wants to set D bit in
> packet to reflector session that is stateless. If S-BFD initiator is not

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 10 Mar 2014 13:38:22 +0000

Hi Greg, Mallik, Manav, Prasad, et al,

We've had version number bump conversation before, it tends end ugly. Even if we [all] were able to get passed that with warm-fuzzy-feeling, there'll be strong possibility of feature creep. Thus, I prefer to not revisit the version number bump, until there's a necessity to do so which I don't see at the moment.

> I'd assume that S-BFD Sender, node that initiates S-BFD session, would use
> dynamic UDP port as its UDP source port while UDP destination port
> required to be set to well-known value. RFC 5880 doesn't make firm
> requirements on use of UDP source port number. I think that
> recommendations made in the RFC 5880 are quite favorable for S-BFD and
> can be re-used. Use of S-BFD well-known UDP port as source by Reflector
> seemed reasonable to me but we can certainly discuss if it useful.

I agree, RFC5880 style of UDP port usage is favorable for S-BFD.

> But I think that there might be one aspect of selection of UDP ports that I'd
> like to discuss. In many sets of OAM Requirements we find requirement to
> ensure OAM being in-band with user traffic. That is problematic if there's
> ECMP. Hence my question, would we take upon S-BFD in-band requirement
> or leave it out of scope of base specification. I'm raising this question since
> UDP port numbers, destination and source, usually used to produce hash for
> ECMP distribution.

The fact that we can't do this with BFD today keeps me up some nights. I agree Greg, it would be a very nice problem to solve, but a very difficult one to solve at that, i.e. we would need flexibility in both UDP source and destination ports. For now, I'm relying on Entropy Label to pick up the slack on this front. If absolutely required w/o EL, it's still possible if all nodes employed 3-tuple hashing.

-Nobo

> Sent: Monday, March 10, 2014 8:18 AM
> To: MALLIK MUDIGONDA (mmudigon); Nobo Akiya (nobo); [email-masked]
> I'd assume that S-BFD Sender, node that initiates S-BFD session, would use
> dynamic UDP port as its UDP source port while UDP destination port
> required to be set to well-known value. RFC 5880 doesn't make firm
> requirements on use of UDP source port number. I think that
> recommendations made in the RFC 5880 are quite favorable for S-BFD and
> can be re-used. Use of S-BFD well-known UDP port as source by Reflector
> seemed reasonable to me but we can certainly discuss if it useful.
> But I think that there might be one aspect of selection of UDP ports that I'd
> like to discuss. In many sets of OAM Requirements we find requirement to
> ensure OAM being in-band with user traffic. That is problematic if there's
> ECMP. Hence my question, would we take upon S-BFD in-band requirement
> or leave it out of scope of base specification. I'm raising this question since
> UDP port numbers, destination and source, usually used to produce hash for
> ECMP distribution.
> 
>                 Regards,
>                                 Greg
> 
> Yes, using source UDP port would be one of the options. But I have a
> question here. Is it mandatory that we carry the Well Known UDP port (yet
> to be allocated for SBFD) as destination port in all packets including the
> reflected ones? If yes, then we cannot swap the UDP ports but should use
> well known UDP port as destination and a local port as source port when
> reflecting packets back to the initiator. In such a case the initiator will not be
> able to use this to break the loop. Am I missing something?
> 
> Thanks
> 
> Regards
> Mallik
> 
> From: Gregory Mirsky <[email-masked]>
> To: "Nobo Akiya (nobo)" <[email-masked]>, Cisco Employee
> <[email-masked]>, "[email-masked]" <[email-masked]>
> looked closer at RFC 5881. I think that we may use UDP source port of S-BFD
> packet received by a reflector as UDP destination  port in reflected packet to
> break the spoofed loop. If not that, then Option #1 but with new version (I
> think we'll need new version # anyway).
> 
> Regards,
> Greg
>

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 10 Mar 2014 15:26:10 -0700

Hello Prasad, Nobo et al.,

>          IMHO, it may be cleaner to consider defining a packet format 
> of S-BFD Async afresh instead of re-defining BFD Async [RFC5880], 
> while still using the UDP destination port to demux the packet type.

Maybe this is the main point: by re-using the D bit it would not be the 
RFC5880 packet anymore but a different packet (albeit a small 
difference). And looking into the Demand parts of 5880 I don't think 
reusing "Demand" for S-BFD will fit well.
One could go back (must go back?) to RFC5880 and declare 
that the D bit definition depends on the session type, leave it 
otherwise undefined in RFC5880 and re-define today's (D)emand use in 
RFC5881. And the new use in the S-BFD document. That would be cleaner, 
IMHO. But is also a prohibitive amount of work.

(the software change for generic CPU to re-interpret the D bit for 
S-BFD is likely trivial. I like this aspect. Not so sure about your NP 
though. And your ASIC may need a re-spin. It's always the same problem 
with re-defining something that is already defined).

For the introduction of a new version - I got fierce rejection when I 
proposed it a while ago :-) .  We probably would want to introduce more 
changes then, remember the "want more flags" discussion we had.

> prevent a single S-BFD session to speak to multiple reflectors 
> (cannot do reply demux'ing), if implementation wants to do this or if 
> there is ever such use-case.

I admit I haven't understood the "speak to multiple reflector" part. 
How would this work, the reflector is defined by the your_discr of the 
outgoing packet, so how can multiple reflectors react on the BFD packet 
(?). Some kind of multicast or multipoint transport with a "multicast 
discriminator"?

Regards, Marc

On Mon, 10 Mar 2014 07:23:45 +0000, Vengada Prasad Govindan (venggovi) 
wrote:
> Hello Manav/ all,
>   I beg to differ here - while BFD relies on using UDP port numbers 
> to demux packet types (Async or Echo), there is currently no notion 
> of interpreting bits differently based on UDP destination port 
> numbers. IMHO, it may be cleaner to consider defining a packet format 
> of S-BFD Async afresh instead of re-defining BFD Async [RFC5880], 
> while still using the UDP destination port to demux the packet type. 
> This could provide an opportunity to revisit the entire Async header 
> to reclaim/ add additional bit(s). Two candidates could be (a) the M 
> bit which was intended for P2MP sessions (the Initiator ->Reflector 
> model proposed by S-BFD is already MP2P) (b) the 
> RequiredMinEchoRxInterval given that S-BFD defines Async only. 
> PS> The above two candidates are mere examples to make the case for 
> redefining the header and not proposals by themselves.
> Thanks
> Prasad
> 
> Seamless BFD uses a new UDP port and that should be good enough to 
> overload the D bit. I don't  think we should be revising the version 
> number -- at least not based on what I have heard till now.
> 
> Cheers, Manav
>

---

From: Mach Chen <[email-masked]>
Date: Tue, 11 Mar 2014 03:20:21 +0000

Hi Nobo,

Sorry to chime in...

> > Mallik Even in this case, Reflectors need not use different
> > discriminators for different initiators. They can still use the same
> > discriminator for all reflected packets. Is there a problem here? The
> > other point about reply demuxing, even the base BFD draft specifies
> > that myDisc can change for a session and that yourDisc should be used
> > for de-multiplexing. Am I missing some point?
> 
> If a single initiator is to talk to multiple reflectors (a, b, c), then my_discrim (x)
> may be the same for BFD packets sent to (a, b, c). When reply from reflectors

I'd recommend not to allow the same my_discrim for multiple reflectors. Consider that there are scenarios that multiple S-BFD sessions between the same initiator and reflector, where it requires that the my_discrim should be different for different session. Although the same my_discrim for different reflectiors is techniall workable, this may make the implementation complex. 

Best regards,
Mach

> come back, then your_discrim cannot be used to demux as it will be the same (x).
> Other demux candidates are source IP and dest UDP in the reply ... but I was
> pointing out that if reply had my_discrim as (a, b, c), then that can be used to
> demux. Of course emphasis on "... if implementations wants to do this or if there
> is ever such use-case".
>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 11 Mar 2014 14:27:41 +0000

Hi Marc, Mach,

Thanks for comments!

Combining the responses into a single thread.

[Marc wrote]
> > ever such use-case.
> outgoing packet, so how can multiple reflectors react on the BFD packet (?).
> Some kind of multicast or multipoint transport with a "multicast
> discriminator"?

I wasn't thinking multicast, but fuzzy/vague unicast possibilities.

[Mac wrote]
> > If a single initiator is to talk to multiple reflectors (a, b, c),
> > then my_discrim (x) may be the same for BFD packets sent to (a, b, c).
> > When reply from reflectors
> 
> I'd recommend not to allow the same my_discrim for multiple reflectors.
> Consider that there are scenarios that multiple S-BFD sessions between the
> same initiator and reflector, where it requires that the my_discrim should
> be different for different session. Although the same my_discrim for
> different reflectiors is techniall workable, this may make the
> implementation complex.

Agree. Such support shouldn't be a MUST, but I'm just not convinced that we want to strictly disallow this in the protocol.

[Marc wrote]
> RFC5880 packet anymore but a different packet (albeit a small difference).
> And looking into the Demand parts of 5880 I don't think reusing "Demand"
> for S-BFD will fit well.

Agree.

> One could go back (must go back?) to RFC5880 and declare that the D bit
> definition depends on the session type, leave it otherwise undefined in
> RFC5880 and re-define today's (D)emand use in RFC5881. And the new use in
> the S-BFD document. That would be cleaner, IMHO. But is also a prohibitive
> amount of work.

S-BFD draft can override the meaning of D-bit in the context of S-BFD only. We do not need to go back to RFC5880/RFC5881 and make changes.

> 
> (the software change for generic CPU to re-interpret the D bit for S-BFD is
> likely trivial. I like this aspect. Not so sure about your NP though. And your
> ASIC may need a re-spin. It's always the same problem with re-defining
> something that is already defined).
> 
> For the introduction of a new version - I got fierce rejection when I proposed
> it a while ago :-) .  We probably would want to introduce more changes then,
> remember the "want more flags" discussion we had.

I remember this very well :)

Which is why I'm pushing to avoid that path, until WG consensus shows absolute need to do so.

-Nobo

> From: Marc Binderberger [mailto:[email-masked]]
> Sent: Monday, March 10, 2014 6:26 PM
> To: Vengada Prasad Govindan (venggovi); Nobo Akiya (nobo)
> Cc: Bhatia, Manav (Manav); Santosh P K; Gregory Mirsky; MALLIK
> MUDIGONDA (mmudigon); [email-masked]
> RFC5880 packet anymore but a different packet (albeit a small difference).
> And looking into the Demand parts of 5880 I don't think reusing "Demand"
> for S-BFD will fit well.
> One could go back (must go back?) to RFC5880 and declare that the D bit
> definition depends on the session type, leave it otherwise undefined in
> RFC5880 and re-define today's (D)emand use in RFC5881. And the new use in
> the S-BFD document. That would be cleaner, IMHO. But is also a prohibitive
> amount of work.
> 
> (the software change for generic CPU to re-interpret the D bit for S-BFD is
> likely trivial. I like this aspect. Not so sure about your NP though. And your
> ASIC may need a re-spin. It's always the same problem with re-defining
> something that is already defined).
> 
> For the introduction of a new version - I got fierce rejection when I proposed
> it a while ago :-) .  We probably would want to introduce more changes then,
> remember the "want more flags" discussion we had.
> 
> 
> > ever such use-case.
> outgoing packet, so how can multiple reflectors react on the BFD packet (?).
> Some kind of multicast or multipoint transport with a "multicast
> discriminator"?
> 
> 
> 
> Regards, Marc
> 
> 
> 
> 
> >   I beg to differ here - while BFD relies on using UDP port numbers to
> > demux packet types (Async or Echo), there is currently no notion of
> > interpreting bits differently based on UDP destination port numbers.
> > IMHO, it may be cleaner to consider defining a packet format of S-BFD
> > Async afresh instead of re-defining BFD Async [RFC5880], while still
> > using the UDP destination port to demux the packet type.
> >> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Santosh
> >> P K
> >> I prefer D-bit option too. Simply because it is clean. D-bit loses
> >> its meaning in S-BFD context and I don't think it will be used. Only
> >> (cannot

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 11 Mar 2014 16:57:05 -0700

Hello Nobo et al.,

> S-BFD draft can override the meaning of D-bit in the context of S-BFD 
> only. We do not need to go back to RFC5880/RFC5881 and make changes.

This is an interesting point: can we?

Technically I like to have a flag to separate the "ping" from the 
"pong". Simple logic. Redefining a packet definition, not "from here 
on" but in parallel to the still valid RFC5880 seems somewhat odd to 
me. Do we have examples in IETF for this?

Regards, Marc

On Tue, 11 Mar 2014 14:27:41 +0000, Nobo Akiya (nobo) wrote:
> Agree. Such support shouldn't be a MUST, but I'm just not convinced 
> that we want to strictly disallow this in the protocol.
> 
> [Marc wrote]
> S-BFD draft can override the meaning of D-bit in the context of S-BFD 
> only. We do not need to go back to RFC5880/RFC5881 and make changes.
> 
>>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 12 Mar 2014 12:36:11 +0000

Hi Marc,

> Sent: Tuesday, March 11, 2014 7:57 PM
> To: Nobo Akiya (nobo)
> Cc: Vengada Prasad Govindan (venggovi); Bhatia, Manav (Manav); Santosh P
> K; Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); [email-masked]

Yes, S-BFD base document can update RFC5880 wrt D bit definition and procedures.
i.e. For S-BFD, meaning and procedure is foobar. For all other BFD types, remains as defined in RFC5880.

-Nobo

> 
> Technically I like to have a flag to separate the "ping" from the "pong".
> Simple logic. Redefining a packet definition, not "from here on" but in
> parallel to the still valid RFC5880 seems somewhat odd to me. Do we have
> examples in IETF for this?
> 
> 
> Regards, Marc
> 
> 
> 
> 
> >>> (cannot do reply demux'ing), if implementation wants to do this or
> >>> if there is ever such use-case.
> >>
> >> How would this work, the reflector is defined by the your_discr of
> >> the outgoing packet, so how can multiple reflectors react on the BFD
> >> packet (?).
> >> Consider that there are scenarios that multiple S-BFD sessions
> >> between the same initiator and reflector, where it requires that the
> >> my_discrim should be different for different session. Although the
> >> same my_discrim for different reflectiors is techniall workable, this
> >> may make the implementation complex.
> >
> >>>          IMHO, it may be cleaner to consider defining a packet
> >>> format of S-BFD Async afresh instead of re-defining BFD Async
> >>> [RFC5880], while still using the UDP destination port to demux the
> packet type.
> >>
> >> One could go back (must go back?) to RFC5880 and declare that the D
> >> bit definition depends on the session type, leave it otherwise
> >> undefined in
> >> RFC5880 and re-define today's (D)emand use in RFC5881. And the new
> >> use in the S-BFD document. That would be cleaner, IMHO. But is also a
> >> prohibitive amount of work.
> >
> >> S-BFD is likely trivial. I like this aspect. Not so sure about your
> >> NP though. And your ASIC may need a re-spin. It's always the same
> >> problem with re-defining something that is already defined).
> >>
> >> proposed it a while ago :-) .  We probably would want to introduce
> >> more changes then, remember the "want more flags" discussion we had.
> >
> >>>          IMHO, it may be cleaner to consider defining a packet
> >>> format of S-BFD Async afresh instead of re-defining BFD Async
> >>> [RFC5880], while still using the UDP destination port to demux the
> packet type.
> >>
> >> One could go back (must go back?) to RFC5880 and declare that the D
> >> bit definition depends on the session type, leave it otherwise
> >> undefined in
> >> RFC5880 and re-define today's (D)emand use in RFC5881. And the new
> >> use in the S-BFD document. That would be cleaner, IMHO. But is also a
> >> prohibitive amount of work.
> >>
> >> S-BFD is likely trivial. I like this aspect. Not so sure about your
> >> NP though. And your ASIC may need a re-spin. It's always the same
> >> problem with re-defining something that is already defined).
> >>
> >> proposed it a while ago :-) .  We probably would want to introduce
> >> more changes then, remember the "want more flags" discussion we had.
> >>
> >>
> >>> (cannot do reply demux'ing), if implementation wants to do this or
> >>> if there is ever such use-case.
> >>
> >> How would this work, the reflector is defined by the your_discr of
> >> the outgoing packet, so how can multiple reflectors react on the BFD
> >> packet (?).
> >>> of interpreting bits differently based on UDP destination port numbers.
> >>> IMHO, it may be cleaner to consider defining a packet format of
> >>> S-BFD Async afresh instead of re-defining BFD Async [RFC5880], while
> >>> still using the UDP destination port to demux the packet type.
> >>> To: Santosh P K; Nobo Akiya (nobo); Gregory Mirsky; MALLIK
> MUDIGONDA
> >>>> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of
> >>>> Santosh P K
> >>>> its meaning in S-BFD context and I don't think it will be used.
> >>>> Only question is do we need to come up with a new version to use D-
> bit?
> >>>>
> >>>> Thanks
> >>>> Santosh P K
> >>>>
> >>>>> S-BFD proposes to use a new well-known UDP port (starting from
> >>>>> base-
> >>>> 02 ...
> >>>>> even if were to change meaning of some fields of BFD control
> >>>>> header
> >>>> (ex: D bit
> >>>>> that (dest UDP port != src UDP port) ... and solution is outside
> >>>>> of
> >>>> BFD control
> >>>>> I'm glad to see that you also prefer option #1. I recommend we
> >>>>> move
> >>>> forward
> >>>>>> S-BFD initiator to reflect session state in state field of
> >>>>>> packets
> >>>> sent.
> >>>>>>

---

From: "MALLIK MUDIGONDA (mmudigon)" <[email-masked]>
Date: Wed, 12 Mar 2014 12:43:34 +0000

Hi Nobo,

I think we need to define the packet type in SBFD draft again and update the interpretation of 'D' bit alone in the new draft clearly mentioning that implementations conforming to SBFD draft should interpret 'D' bit for identifying Request or Reflected packets. This will be similar to the State Machine diagram that we added removing the INIT state.

Thanks

Regards
Mallik

From: "Nobo Akiya (nobo)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 12 March 2014 6:06 PM
To: Marc Binderberger <[email-masked]<mailto:[email-masked]>>
Cc: "Vengada Prasad Govindan (venggovi)" <[email-masked]<mailto:[email-masked]>>, "Bhatia, Manav (Manav)" <[email-masked]<mailto:[email-masked]>>, Santosh P K <[email-masked]<mailto:[email-masked]>>, Gregory Mirsky <[email-masked]<mailto:[email-masked]>>, Cisco Employee <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)

Hi Marc,

-----Original Message-----
From: Marc Binderberger [mailto:[email-masked]]
Sent: Tuesday, March 11, 2014 7:57 PM
To: Nobo Akiya (nobo)
Cc: Vengada Prasad Govindan (venggovi); Bhatia, Manav (Manav); Santosh P
K; Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); [email-masked]<mailto:[email-masked]>
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)
Hello Nobo et al.,

-Nobo

packet type.
>> MUDIGONDA (mmudigon); [email-masked]<mailto:[email-masked]>
packet type.
>>> To: Santosh P K; Nobo Akiya (nobo); Gregory Mirsky; MALLIK
MUDIGONDA
>>> (mmudigon); [email-masked]<mailto:[email-masked]>
bit?
>>>>> To: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); rtg-
>>>> MALLIK

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 12 Mar 2014 13:02:46 +0000

Hi Mallik,

That would add value to readability, agree.

-Nobo

From: MALLIK MUDIGONDA (mmudigon)
Sent: Wednesday, March 12, 2014 8:44 AM
To: Nobo Akiya (nobo); Marc Binderberger
Cc: Vengada Prasad Govindan (venggovi); Bhatia, Manav (Manav); Santosh P K; Gregory Mirsky; [email-masked]
Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)

Hi Nobo,

Thanks

Regards
Mallik

Hi Marc,

-----Original Message-----
From: Marc Binderberger [mailto:[email-masked]]
Sent: Tuesday, March 11, 2014 7:57 PM
To: Nobo Akiya (nobo)
Cc: Vengada Prasad Govindan (venggovi); Bhatia, Manav (Manav); Santosh P

-Nobo

packet type.
packet type.
MUDIGONDA
bit?

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 13 Mar 2014 14:24:32 -0400

> me. Do we have examples in IETF for this?

IMNSHO, D-bit behavior is a base feature of BFD v0/v1 as defined in the
various specs.  Making that behavior vary without a version number change
may be pushing things a bit.

FWIW, I thought we had a discussion about this particular issue off-list
previously.  The suggested semantic was P/F state to be used to prevent
infinite looping.  E.g.

A---M---B

M sends packet to A in current scenario spoofing B's address.  We have loop
in current proposal.

If A required P to be set and always responded with F, B would receive F and
drop the packet.

-- Jeff

---

From: Marc Binderberger <[email-masked]>
Date: Thu, 13 Mar 2014 11:35:57 -0700

Hello Jeff,

> If A required P to be set and always responded with F, B would receive F and

ah!  Let me go back to RFC5880 and what it says about Ps and Fs but I 
think this sounds good.

Right, this was mentioned before but I never understood why someone 
would want to go for a Poll sequence - now I know.

Regards, Marc

P.S.: IMNSHO ?!? In My Not So Humble Opinion?  Or the new set of flags 
proposed for S-BFD? ;-)

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 13 Mar 2014 14:49:36 -0400

> would want to go for a Poll sequence - now I know.

There you have it.  Just for the broader record, I believe it was Santosh PK
who made the original observation.

> P.S.: IMNSHO ?!? In My Not So Humble Opinion?  Or the new set of flags 

Ego flag bits particularly required for IETF WG chairs. :-)

-- Jeff

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 13 Mar 2014 19:59:40 +0000

Hi Jeff, Marc, et al,

Had to go dig in my old mail box to find the reason for tossing the P/F idea.

When a reflector session is receiving too many BFD control packets, we proposed two ways which reflector session can handle this.

draft-akiya-bfd-seamless-base-02, sec 8.8

To do first bullet of above section, we need to preserve a way for reflector session to tell initiators to "slow down" (i.e. update Required Min RX Interval w/ P bit set). Reflector, w/o having state, won't be able to tell whether initiators have honored the request, but it's a best effort way to "make room for more initiators speaking to it". 

> who made the original observation.

Funny thing is, it was also Santosh PK who pointed out that P/F can't be used if we want to preserve this ability.

So we could keep P/F as originally proposed but remove the first bullet from sec 8.8 of s-bfd-base-02 ... that's one way to go.

> may be pushing things a bit.

Alright, noted. I'm still hoping that we can converge on a route which we do not have to bump up BFD version number (Pandora's box?), as that'll likely add significant delay before vendors can start the implementation.

Another lesser-of-evils idea ...

How about initiator MUST set both P and F, and reflector MUST clear [at least] F? Packets with both P/F set will be considered invalid by any non-S-BFD-reflector-sessions. Technically (fine line here) we don't have to change the definition of the bits for S-BFD, but we only have to update procedures and what is/isn't allowed by S-BFD.
	
-Nobo

> From: Jeffrey Haas [mailto:[email-masked]]
> Sent: Thursday, March 13, 2014 2:50 PM
> To: Marc Binderberger
> Cc: Jeffrey Haas; Nobo Akiya (nobo); [email-masked]
> > > If A required P to be set and always responded with F, B would
> > > receive F and drop the packet.
> >

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 13 Mar 2014 16:09:27 -0400

> So we could keep P/F as originally proposed but remove the first bullet from sec 8.8 of s-bfd-base-02 ... that's one way to go.

I may be mis-remembering the conversation or mis-reading the document, but
since the reflector is intended to be stateless why would it expect to
receive a Final from the Initiator?

> How about initiator MUST set both P and F, and reflector MUST clear [at least] F? Packets with both P/F set will be considered invalid by any non-S-BFD-reflector-sessions. Technically (fine line he…

Another bit from 5880:

:  Poll bit cleared.  A BFD Control packet MUST NOT have both the Poll
:  (P) and Final (F) bits set.

-- Jeff

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 13 Mar 2014 20:17:22 +0000

Hi Jeff,

> Sent: Thursday, March 13, 2014 4:09 PM
> To: Nobo Akiya (nobo)
> Cc: Jeffrey Haas; Marc Binderberger; [email-masked]
> > When a reflector session is receiving too many BFD control packets, we
> proposed two ways which reflector session can handle this.
> >
> > To do first bullet of above section, we need to preserve a way for reflector
> session to tell initiators to "slow down" (i.e. update Required Min RX
> Interval w/ P bit set). Reflector, w/o having state, won't be able to tell
> whether initiators have honored the request, but it's a best effort way to
> "make room for more initiators speaking to it".
> >
> > > There you have it.  Just for the broader record, I believe it was
> > > Santosh PK who made the original observation.
> >
> > Funny thing is, it was also Santosh PK who pointed out that P/F can't be
> used if we want to preserve this ability.
> >
> > So we could keep P/F as originally proposed but remove the first bullet
> from sec 8.8 of s-bfd-base-02 ... that's one way to go.
> 
> I may be mis-remembering the conversation or mis-reading the document,
> but since the reflector is intended to be stateless why would it expect to

It doesn't, reflector doesn't expect F bit (hence best effort). P bit will alert initiator that parameter has changed (i.e. Required Min RX Interval has changed).

> 
> > How about initiator MUST set both P and F, and reflector MUST clear [at
> least] F? Packets with both P/F set will be considered invalid by any non-S-
> BFD-reflector-sessions. Technically (fine line here) we don't have to change
> the definition of the bits for S-BFD, but we only have to update procedures
> and what is/isn't allowed by S-BFD.
> 
> Another bit from 5880:
> 

Yes that sentence is exactly what I thought of using both P/F. That paragraph can be "updated" by S-BFD base for S-BFD context.

-Nobo

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 13 Mar 2014 16:27:43 -0400

> It doesn't, reflector doesn't expect F bit (hence best effort). P bit will alert initiator that parameter has changed (i.e. Required Min RX Interval has changed).

Remember that the primary reason for the Required Min RX Interval in regular
BFD is that the receiver is also running a timer and will use that for its
state by helping to adjust the sender's speed in a graceful fashion.

In this case, graceful is important since only the Initiator cares about the
actual timing of the packets.  

And even then, for our original scenario:

A---M---B

As long as each side doesn't respond to F packets (but sends them), I think
we're still good.  I think this means you can keep the poll bit idea to help
suggest an Initiator to slow down and still prevent DoS.  In such a
scenario, M is injecting packets to A, with or without P, using B's
addressing.  Without P, A could still respond with F and B would drop it.

So, I suppose the suggested addition to the S-BFD logic is "in the absence
of a P-bit, F will still be set for security purposes upon reflection."

If a reflector wants to tell an Initiator to slow down, it would simply need
to inject an additional packet (perhaps a DoS on its own, so should be
rate-limited) with the P bit set.  This is effectively the "dueling poll"
scenario that had popped up much earlier in standardization.

-- Jeff

---

From: Marc Binderberger <[email-masked]>
Date: Thu, 13 Mar 2014 13:30:01 -0700

Hello Nobo et al.,

> When a reflector session is receiving too many BFD control packets, 
> we proposed two ways which reflector session can handle this.
> 
> To do first bullet of above section, we need to preserve a way for 
> reflector session to tell initiators to "slow down" (i.e. update 
> Required Min RX Interval w/ P bit set). Reflector, w/o having state, 
> won't be able to tell whether initiators have honored the request, 
> but it's a best effort way to "make room for more initiators speaking 
> to it". 

ah well, we simply don't have enough flags in the BFD packet. You are 
sure we don't want a BFD "v2" to add another 32/64 bit for future flag 
use? ;-)

But seriously: as the S-BFD sender is effectively talking to itself you 
do not need P/F to synchronize two systems. The reflector can simply 
set the Required Min RX Interval as it wants and the S-BFD sender 
adjusts.

Also: as Jeff mentioned, without any "session state" on the reflector 
side it would be difficult to match any received F bit to a particular 
P sent out?

Nevertheless, it would require we "overwrite" the statement in RFC5880 
that any parameter change requires a Poll sequence. Not sure if we are 
any further then (?). But without state the Poll sequence doesn't seem 
applicable anyway, so ... .

Regards, Marc

> Funny thing is, it was also Santosh PK who pointed out that P/F can't 
> be used if we want to preserve this ability.
> 
> So we could keep P/F as originally proposed but remove the first 
> bullet from sec 8.8 of s-bfd-base-02 ... that's one way to go.
> 
> Alright, noted. I'm still hoping that we can converge on a route 
> which we do not have to bump up BFD version number (Pandora's box?), 
> as that'll likely add significant delay before vendors can start the 
> implementation.
> 
> How about initiator MUST set both P and F, and reflector MUST clear 
> [at least] F? Packets with both P/F set will be considered invalid by 
> any non-S-BFD-reflector-sessions. Technically (fine line here) we 
> don't have to change the definition of the bits for S-BFD, but we 
> only have to update procedures and what is/isn't allowed by S-BFD.
> 	
> -Nobo
>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 13 Mar 2014 20:48:27 +0000

Hi Jeff, Marc, BFDers,

[Jeff wrote]
> So, I suppose the suggested addition to the S-BFD logic is "in the absence of
> a P-bit, F will still be set for security purposes upon reflection."

This  is certainly lesser evil than other evil ideas (especially v2 BFD), I'll take it :)
S-BFD authors/collaborators & BFDers, comments?
(speak now or forever hold your peace)

[Jeff wrote]
> If a reflector wants to tell an Initiator to slow down, it would simply need to
> inject an additional packet (perhaps a DoS on its own, so should be

So bit it.

[Marc wrote]
> ah well, we simply don't have enough flags in the BFD packet. You are sure
> we don't want a BFD "v2" to add another 32/64 bit for future flag use? ;-)

I am very sure :)

[Marc wrote]
> But seriously: as the S-BFD sender is effectively talking to itself you do not
> need P/F to synchronize two systems. The reflector can simply set the
> Required Min RX Interval as it wants and the S-BFD sender adjusts.

True that's definitely a possibility, but someone will surely argue that changing interval w/o presence of P bit will violate RFC5880.

[Marc wrote]
> Also: as Jeff mentioned, without any "session state" on the reflector side it
> would be difficult to match any received F bit to a particular P sent out?

With new proposal by Jeff, [P=0, F=1] will be dropped by reflector now. Reflector can still send [P=1, F=0], but that is one-way-communication/request.

-Nobo

> Sent: Thursday, March 13, 2014 4:28 PM
> To: Nobo Akiya (nobo)
> > > I may be mis-remembering the conversation or mis-reading the
> > > document, but since the reflector is intended to be stateless why
> > > would it expect to receive a Final from the Initiator?
> >
> > It doesn't, reflector doesn't expect F bit (hence best effort). P bit will alert
> initiator that parameter has changed (i.e. Required Min RX Interval has
> changed).
> 
> Remember that the primary reason for the Required Min RX Interval in
> regular BFD is that the receiver is also running a timer and will use that for
> its state by helping to adjust the sender's speed in a graceful fashion.
> 
> suggest an Initiator to slow down and still prevent DoS.  In such a scenario, M
> is injecting packets to A, with or without P, using B's addressing.  Without P,
> A could still respond with F and B would drop it.
> 
> So, I suppose the suggested addition to the S-BFD logic is "in the absence of
> a P-bit, F will still be set for security purposes upon reflection."
> 
> If a reflector wants to tell an Initiator to slow down, it would simply need to
> inject an additional packet (perhaps a DoS on its own, so should be

---

From: Marc Binderberger <[email-masked]>
Date: Thu, 13 Mar 2014 14:12:10 -0700

Hello Nobo,

okay. Now there is one detail: the security logic is actually:

(1) upon reflection of an S-BFD packet, set the F bit to 1
(2) when receiving a S-BFD packet for reflection and the F bit is set, 
then drop the packet (or punt but do not reflect).

So far, so good. Say "A" is the S-BFD originator and "B" is the 
reflector. If you use the Poll sequence now for a parameter change from 
the B side, we would send out a packet from A in reply to B's P packet, 
that has the F bit set and is directed to B's reflector. And the 
security rule above will drop this packet.

That's okay when the F-bit packet from A is an additional packet. 
RFC5880 is kind of stating this by saying

                                       When the other system receives a
   Poll, it immediately transmits a BFD Control packet with the Final
   (F) bit set, independent of any periodic BFD Control packets it may
   be sending (see section 6.8.7).

but we may want to ensure that the periodic packets have no F bit set.
Otherwise fine with it.

Regards, Marc

On Thu, 13 Mar 2014 20:48:27 +0000, Nobo Akiya (nobo) wrote:
> True that's definitely a possibility, but someone will surely argue 
> that changing interval w/o presence of P bit will violate RFC5880.
> 
> [Marc wrote]
> With new proposal by Jeff, [P=0, F=1] will be dropped by reflector 
> now. Reflector can still send [P=1, F=0], but that is 
> one-way-communication/request.
> 
> -Nobo
> 
>> scenario, M

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 13 Mar 2014 21:23:50 +0000

Hi Marc,

> but we may want to ensure that the periodic packets have no F bit set.

Agree, we have to be crystal clear on this point in the base document.

> Otherwise fine with it.

Excellent & thanks!

-Nobo

> Sent: Thursday, March 13, 2014 5:12 PM
> To: Nobo Akiya (nobo)
> Cc: Jeffrey Haas; [email-masked]
> (2) when receiving a S-BFD packet for reflection and the F bit is set, then
> drop the packet (or punt but do not reflect).
> 
> 
> sure

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 13 Mar 2014 15:47:14 -0700

Comments inline.

Sent from my iPad

> On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)" <[email-masked]> wrote:
> 
> 
> Hi Jeff, Marc, BFDers,
> 
> [Jeff wrote]
Catching on this long email thread, finally. 

I too prefer not going v2 way, as it creates more complexity or open up many more issues.
P/F bits as suggested by Jeff is a good option and we should use it. Base document should document on how those bits should be used, that includes any interval change.
> True that's definitely a possibility, but someone will surely argue that changing interval w/o presence of P bit will violate RFC5880.
If it deviates from the way the P bit is presently being used, true. But if S-BFD could set rx interval differently to regular BFD as long as we document it right, we wouldn't  be violating RFC5880, IMO. Do you think RFC is rigid about interval change?
> With new proposal by Jeff, [P=0, F=1] will be dropped by reflector now. Reflector can still send [P=1, F=0], but that is one-way-communication/request.

Nod.

Sam

---

From: "Girija Raghavendra Rao (giraghav)" <[email-masked]>
Date: Mon, 17 Mar 2014 10:33:48 +0000

Hi Jeff, Marc, Nobo, BFDers,

If using of "D" bit to differentiate initiator/Reflector generated packets
is not preferred, how about the second option listed in the start of this
thread?

Thanks  & Regards
R.Girija

On 14/03/14 4:17 AM, "Sam Aldrin" <[email-masked]> wrote:

>P/F bits as suggested by Jeff is a good option and we should use it. Base
>document should document on how those bits should be used, that includes
>any interval change.
>> 
>> [Jeff wrote]
>If it deviates from the way the P bit is presently being used, true. But
>if S-BFD could set rx interval differently to regular BFD as long as we
>document it right, we wouldn't  be violating RFC5880, IMO. Do you think
>RFC is rigid about interval change?
>> 
>> [Marc wrote]
>>>side it
>> With new proposal by Jeff, [P=0, F=1] will be dropped by reflector now.
>>Reflector can still send [P=1, F=0], but that is

---

From: "MALLIK MUDIGONDA (mmudigon)" <[email-masked]>
Date: Mon, 17 Mar 2014 10:56:20 +0000

Hi All,

>From the discussions I understand that the following is the sequence being discussed:

(Initiator)A=====M=====B(Reflector)

Normal Sequence

A to B: [p=0,F=0] ==> ping packets
B to A: [p=0,F=1] ==> pong packets

Timer negotiation (ack)

A to B: [p=1,F=0] ==> ping packets
B to A: [p=0,F=1] ==> pong packet with ack for timer poll

Timer negotiation (nack) Dueling poll

A to B: [p=1,F=0] ==> ping packets
B to A: [p=0.F=1] ==> pong packet with ack for timer poll
B to A: [p=1,F=0] ==> Reflector initiated poll

We have a few questions:

  1.  In the above P/F approach, we are still overloading the interpretation of 'F' bit. In our view this is same as re-interpreting/overloading 'D' bit. Don't the same arguments that we used against 'D' bit apply here too?
  2.  Most of the H/W based implementations use P/F bits to punt the received packets to S/W . Overloading P/F bits may impact H/W based implementations depending on these bits.
  3.  'F' bit itself is now ambiguous. Implementations will have to go through extra logic to process a packet with 'F' bit set I.e to know if it is a reflected packet or a response to the poll that is initiated.

 Thanks

Regards
Mallik
From: Sam Aldrin <[email-masked]<mailto:[email-masked]>>
Date: Friday 14 March 2014 4:17 AM
To: "Nobo Akiya (nobo)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)

Comments inline.

Sent from my iPad

On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jeff, Marc, BFDers,
[Jeff wrote]

Nod.

Sam
-Nobo

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Mon, 17 Mar 2014 11:16:57 +0000

Hello all,
  One comment inlined with GVP>.
Thanks
Prasad

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of MALLIK MUDIGONDA (mmudigon)
Sent: Monday, March 17, 2014 4:26 PM
To: Sam Aldrin; Nobo Akiya (nobo)
Cc: [email-masked]
Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)

Hi All,

Normal Sequence

Timer negotiation (ack)

We have a few questions:

  1.  In the above P/F approach, we are still overloading the interpretation of 'F' bit. In our view this is same as re-interpreting/overloading 'D' bit. Don't the same arguments that we used against 'D' bit apply here too?
  2.  Most of the H/W based implementations use P/F bits to punt the received packets to S/W . Overloading P/F bits may impact H/W based implementations depending on these bits.
GVP> Fully agree, I would prefer an option not re-interpreting or overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA assumptions that are hard to change.

  1.  'F' bit itself is now ambiguous. Implementations will have to go through extra logic to process a packet with 'F' bit set I.e to know if it is a reflected packet or a response to the poll that is initiated.
 Thanks

Regards
Mallik

Comments inline.

Sent from my iPad

Nod.

Sam
-Nobo

---

From: Santosh P K <[email-masked]>
Date: Mon, 17 Mar 2014 12:28:16 +0000

Hello Prasad,

>>Most of the H/W based implementations use P/F bits to punt the received packets to S/W . Overloading P/F bits may impact H/W based implementations depending on these bits.
This should not be an issue right? We have dedicated UDP port number for S-BFD. The way a packet is processed is different for S-BFD than regular BFD.

Thanks
Santosh P K
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Vengada Prasad Govindan (venggovi)
Sent: Monday, March 17, 2014 4:47 PM
To: MALLIK MUDIGONDA (mmudigon); Sam Aldrin; Nobo Akiya (nobo)
Cc: [email-masked]
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)

Hello all,

Cc: [email-masked]<mailto:[email-masked]>

Hi All,

Normal Sequence

Timer negotiation (ack)

We have a few questions:

Regards
Mallik

Comments inline.

Sent from my iPad

Nod.

Sam
-Nobo

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Mon, 17 Mar 2014 15:19:23 +0000

Hello Santosh,
  Please see inline GVP2>.
Thanks
Prasad

From: Santosh P K [mailto:[email-masked]]
Sent: Monday, March 17, 2014 5:58 PM
To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA (mmudigon); Sam Aldrin; Nobo Akiya (nobo)
Cc: [email-masked]
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)

Hello Prasad,

GVP2>While I agree on the destination port value, the simpler the flags/ criteria for taking decisions the better especially given the tight time budgets of BFD.

Hello all,

Hi All,

Normal Sequence

Timer negotiation (ack)

We have a few questions:

Regards
Mallik

Comments inline.

Sent from my iPad

Nod.

Sam
-Nobo

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 17 Mar 2014 10:36:30 -0700

Hello Mallik and Prasad,

> 	1.	In the above P/F approach, we are still overloading the 
> interpretation of 'F' bit. In our view this is same as 
> re-interpreting/overloading 'D' bit. Don't the same arguments that we 
> used against 'D' bit apply here too?

what we discussed about the "D" bit was more on a formal level. For "D" 
is would be a replacement of what it means in RFC5880 and this is 
formally kind of a no-no. At least difficult to change. The P/F bit use 
for S-BFD should, as far as I can see, work smoothly with the existing 
RFC5880 interpretation.

Receiving F-bit set while you are not in a Poll sequence anymore is 
what existing implementations - which we want to re-use largely on the 
S-BFD originator side - must support anyway.

> 	2.	Most of the H/W based implementations use P/F bits to punt the 
> received packets to S/W . Overloading P/F bits may impact H/W based 
> implementations depending on these bits.
> GVP> Fully agree, I would prefer an option not re-interpreting or 
> overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA 
> assumptions that are hard to change.

Thanks for your feedback on this aspect :-)   I don't have any good 
answer here. It would mean on the S-BFD originator side the hw needs a 
differentiation based on the UDP port instead of simply re-using the 
existing packet I/O. Or it needs at least a knob to suppress this F-bit 
punting (which potentially breaks other things).

> 	3.	'F' bit itself is now ambiguous. Implementations will have to go 
> through extra logic to process a packet with 'F' bit set I.e to know 
> if it is a reflected packet or a response to the poll that is 
> initiated.

Don't see that. The only difference it to drop F-bit packets when you 
are about to reflect them - but the reflector is different code/hw 
anyway. Otherwise as mentioned above you have already today the 
situation of receiving F-bit packets while your are not in a Poll 
sequence (anymore).

sigh, this kind of re-using a protocol always has risks and personally 
I still think we should introduce v2 BFD with 32 or 64 more bits in an 
otherwise unchanged header and stop spending time on these "clever 
protocol tricks". But then we won't proceed with S-BFD anymore and have 
long discussions about the new BFD v2 packet (risk of another "IPv6" 
with an uber-engineered protocol). So I understand nobody is keen on 
the v2 topic :-)

Really not any good answer from my side other than we may have to look 
further for something else to "overload".

Regards, Marc

On Mon, 17 Mar 2014 11:16:57 +0000, Vengada Prasad Govindan (venggovi) 
wrote:
> 	1.	In the above P/F approach, we are still overloading the 
> interpretation of 'F' bit. In our view this is same as 
> re-interpreting/overloading 'D' bit. Don't the same arguments that we 
> used against 'D' bit apply here too?
> 	2.	Most of the H/W based implementations use P/F bits to punt the 
> received packets to S/W . Overloading P/F bits may impact H/W based 
> implementations depending on these bits.
> GVP> Fully agree, I would prefer an option not re-interpreting or 
> overloading the P/F bits as it breaks existing NP/ ASIC/ FPGA 
> assumptions that are hard to change.
> 	3.	'F' bit itself is now ambiguous. Implementations will have to go 
> through extra logic to process a packet with 'F' bit set I.e to know 
> if it is a reflected packet or a response to the poll that is 
> initiated.
>  Thanks
>  
> Regards
> Mallik
> From: Sam Aldrin <[email-masked]>
> To: "Nobo Akiya (nobo)" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> P/F bits as suggested by Jeff is a good option and we should use it. 
> Base document should document on how those bits should be used, that 
> includes any interval change.
>> [Jeff wrote]
> If it deviates from the way the P bit is presently being used, true. 
> But if S-BFD could set rx interval differently to regular BFD as long 
> as we document it right, we wouldn't  be violating RFC5880, IMO. Do 
> you think RFC is rigid about interval change?
>> [Marc wrote]

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 17 Mar 2014 14:29:52 -0400

> with an uber-engineered protocol). So I understand nobody is keen on 

A "BFD v2" is not completely out of question but will have a fair amount of
chair resistance to overcome to get us there. :-)

In all cases, when we consider such new mechanisms, I shall always ask one
critical question: Are your extensions to the protocol interesting enough
that some very low-level hardware wants to hear about that new information
once ever few milliseconds? If the answer is no, BFD may be the wrong place
for it. 

So, the topic isn't off-limits, but build your case upon that premise.

-- Jeff

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 17 Mar 2014 12:01:06 -0700

Hello Girija

playing with the state field is a bold move :-)

Okay, it "violates" RFC5880 section "6.8.7. Transmitting BFD Control 
Packets" which says

   The contents of transmitted BFD Control packets MUST be set as
   follows:
	[...]
   State (Sta)

      Set to the value indicated by bfd.SessionState.

but as the whole state machine has been changed I wonder if that's 
actually a real concern. My criticism about the state machine in 
"8.1.1. Initiator State machine" of the S-BFD draft is actually that it 
is a new state machine :-)

Seriously: to maintain as much code/hw and spec (5880) as possible I 
would have kept the Down/Init/Up on the S-BFD originator side plus a 
rule for the reflector

(1) MAY set the outgoing state to AdminDown
(2) otherwise MUST copy the outgoing state from the incoming packet

But this idea would definitely clash with your idea. Let's see what 
others think.

Regards, Marc

On Mon, 17 Mar 2014 10:33:48 +0000, Girija Raghavendra Rao (giraghav)

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 17 Mar 2014 18:36:01 -0700

Hello Jeff et al.,

slowly changing the subject. I don't want to create a roadblock for the 
S-BFD discussion.

But S-BFD is a good example. Technically the redundant-session 
discussion we had a while ago was a good reason too to talk about "v2" 
but it probably would have been shot down as S-BFD should be able to 
cover this redundancy. The "do we need this" discussion for new 
drafts/RFCs will not and should not go away.

In my opinion the only "flaw" BFD has is the lack of reserved fields to 
grow for new applications. Today we start bending the standard to fit 
something in. Even if we do a good job it's still likely to cause some 
trouble, simply because of BFDs success and the resulting number of 
implementations. Not to mention the time we - pardon - waste discussing 
which field(s) we can highjack. E.g. the main aspect, that a 
(R)eflected bit would be a neat solution for S-BFD to break a 
loop-attack - just takes a single bit, simple rules how to use it, 
simple to implement in hw/sw - is pushed into the background. We don't 
focus so much on what "doing the right thing" may be, we are just glad 
if it fits the existing RFC5880 in an acceptable manner.

And still, to avoid the bigger "v2" topic delaying the discussions, we 
keep going. That's why I actually think it's time to do a next step and 
discuss "v2".

My proposal would be fairly simple: just add a few 32bit fields. There 
is an upper limit, so NPs still can see the full IPv6+UDP+BFD packet
(keep in mind some NPs process the first N bytes, the rest of the 
packet is DMAed "around" the NP, not through the NP)

The proposal would look like:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Vers |  Diag   |Sta|P|F|C|A|D|M|  Detect Mult  |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       My Discriminator                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Your Discriminator                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Desired Min TX Interval                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Required Min RX Interval                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Required Min Echo RX Interval                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Reserved-1                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Reserved-2                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   An optional Authentication Section MAY be present:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Auth Type   |   Auth Len    |    Authentication Data...     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vers: 2

The new packet would allow to include BFD v1 and it's standard. 
Effectively keep the new bytes zero and you have a BFD v1 "embedded" 
into BFD v2. RFCs would apply as they do today (modulo a larger packet 
length, obviously), so all the good things we have would remain. Fixed 
packet size. No TLV complexity, just flags and fixed fields. Small 
packets. And so on.

And if you ask: why 64bit?  Because it's a lot of flags, yet small 
enough to stop people from squeezing in an IPv6 address :-) Seriously, 
these details would need to be discussed. One relevant point is: don't 
think too complex, it's really just more room for flags or small 
fields. Because from my point of view that is the flaw to fix.

> chair resistance to overcome to get us there. :-)

:-)

Regards, Marc

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 18 Mar 2014 14:45:22 +0000

Hi Marc,

If the "A" bit is set (authentication is present) then you can no longer embed the BFDv1 inside a BFDv2 packet since the parser for v1 assumes that the authentication info starts from a fixed offset from the start of the packet. 

Any talk about a version upgrade before coming across real deployment issue to solve is akin to putting a cart before the horse. 

You have proposed a 64 bit reserved field assuming that this would fix all the new and interesting stuff that we would want to do with BFD (in the future). Now assume, that we come across a use case that requires some additional data to be carried along with the BFD packet. How will you do it?

You will add a bit which when turned on would mean that the additional data will be carried. But where will you store it - before the authentication data or after it? If you place it before the auth data, then you would need to carry some offset within the BFD packet that tells the receiver where the authentication data starts. This has not been accounted in your packet format. If you do account for this, then we are unnecessarily complicating the packet.

If you don't, then there is no guarantee that the new BFD packet format will work for all possible extensions that we may expect from BFD.

If you really want to be safe, then you need to go in for a TLV format -- since that's always extensible. But, then you cant just go in for a TLV format when you expect the HW to consume the data (just makes life more complicated).

I thus believe we should only go with a version upgrade if we really have no other option left and when we have a *real* issue that requires us to.

Cheers, Manav

> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Marc
> Binderberger
> Sent: Tuesday, March 18, 2014 7:06 AM
> To: Jeffrey Haas
> Cc: [email-masked]
> Subject: BFD v2? (was: Loop Prevention in S-BFD (draft-akiya-bfd-
> seamless-base))
> 
> Hello Jeff et al.,
>

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 18 Mar 2014 10:46:25 -0700

Hello Manav,

okay, learned my first lesson and will avoid the word "embedding" as it 
creates the wrong expectations on your side :-)

Obviously parsing a v2 packet is done with a v2 parser, not a v1 
parser. But you can re-use large parts of the v1 parser, practically 
everything except the authentication, in the case that the v2 packet is 
"v1 packet plus zeros". That's what I named "embedded".

Authentication would be done for the whole v2 packet. Sorry if this was 
causing confusion.

> Any talk about a version upgrade before coming across real deployment 
> issue to solve is akin to putting a cart before the horse. 

I think I explained in my email why I think it's time for "v2", so your 
comment does not apply, IMO.

Honestly, reading your reply there is not much constructive in it. I 
mentioned why I think what is the flaw. There is no answer to this in 
your email. The rest is "why this won't work". With this attitude no 
protocol would ever start flying. If you think 64bit is not enough - we 
can 96, 128. And "playing safe" with TLVs is exactly what I don't want. 
This is not ISIS or BGP.

> I thus believe we should only go with a version upgrade if we really 
> have no other option left and when we have a *real* issue that 
> requires us to.

sorry Manav, just read my email again. I explained what I propose to 
fix.

Regards, Marc

On Tue, 18 Mar 2014 14:45:22 +0000, Bhatia, Manav (Manav) wrote:
> Hi Marc,
> 
> If the "A" bit is set (authentication is present) then you can no 
> longer embed the BFDv1 inside a BFDv2 packet since the parser for v1 
> assumes that the authentication info starts from a fixed offset from 
> the start of the packet. 
> 
> Any talk about a version upgrade before coming across real deployment 
> issue to solve is akin to putting a cart before the horse. 
> 
> You have proposed a 64 bit reserved field assuming that this would 
> fix all the new and interesting stuff that we would want to do with 
> BFD (in the future). Now assume, that we come across a use case that 
> requires some additional data to be carried along with the BFD 
> packet. How will you do it?
> 
> You will add a bit which when turned on would mean that the 
> additional data will be carried. But where will you store it - before 
> the authentication data or after it? If you place it before the auth 
> data, then you would need to carry some offset within the BFD packet 
> that tells the receiver where the authentication data starts. This 
> has not been accounted in your packet format. If you do account for 
> this, then we are unnecessarily complicating the packet.
> 
> If you don't, then there is no guarantee that the new BFD packet 
> format will work for all possible extensions that we may expect from 
> BFD.
> 
> If you really want to be safe, then you need to go in for a TLV 
> format -- since that's always extensible. But, then you cant just go 
> in for a TLV format when you expect the HW to consume the data (just 
> makes life more complicated).
> 
> I thus believe we should only go with a version upgrade if we really 
> have no other option left and when we have a *real* issue that 
> requires us to.
> 
> Cheers, Manav
>

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 18 Mar 2014 11:52:37 -0700

Hello Mallik, Prasad et al.,

okay, the following looks a bit weird. Maybe it is :-) On the other 
hand it avoids dealing with the "flags" which seem to either hit formal 
or practical problems.

The draft for S-BFD says ""Required Min Echo RX Interval" SHOULD be 
zero.", both for the originator and the reflector. Unless there is an 
idea what "echo" would mean for S-BFD (which is already pretty close to 
an echo function itself), what about re-using this field

(1) Initiator sets "Required Min Echo RX Interval" to zero
(2) Reflector sets "Required Min Echo RX Interval" to a non-zero value
(3) the reflector is not reflecting a packet received with non-zero 
"Required Min Echo RX Interval"

Basically the flag idea, just a different field. As echo functionality 
is driven on the initiator side - the remote side only informs if it 
allows and to what speed - I would not expect any adverse impact on the 
initiator side, even when the whole functionality (i.e. the code) is 
re-used for S-BFD on the initiator side. And RFC5880 doesn't put too 
many restrictions on echo and "Required Min Echo RX Interval".

Feedback welcome :-)

Btw, what happened to the discriminator discussion?  If I recall right 
then the idea was the reflector is inserting a local discriminator into 
the my_discr field when sending out the reflected packet. Nobo 
mentioned this makes it impossible to differentiate reflectors - I 
admit he lost me at this point ;-) Was this discussion conclusive? 
No-Go for the discriminator idea?

Regards, Marc

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 18 Mar 2014 19:03:26 +0000

Hi Marc, et al,

Thanks for continued discussions on this topic.

Just wanted to let you and others know that few of us have been studying how BFD-Multipoint draft updated RX procedures of RFC5880, we should be able to provide an update to this thread soon.

BFD-Multipoint pointer:
http://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/?include_text=1

-Nobo

> Sent: Tuesday, March 18, 2014 2:53 PM
> To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA
> (mmudigon); Nobo Akiya (nobo)
> Cc: [email-masked]
> okay, the following looks a bit weird. Maybe it is :-) On the other hand it
> avoids dealing with the "flags" which seem to either hit formal or practical
> problems.
> 
> The draft for S-BFD says ""Required Min Echo RX Interval" SHOULD be zero.",
> both for the originator and the reflector. Unless there is an idea what "echo"
> would mean for S-BFD (which is already pretty close to an echo function
> itself), what about re-using this field
> 
> (3) the reflector is not reflecting a packet received with non-zero "Required
> Min Echo RX Interval"
> 
>

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 19 Mar 2014 02:03:24 +0000

Dear All,
very interesting discussion and feel sorry to not being able to participate fully.
If understand correctly, there's practical scenario that emphasizes need to differentiate S-BFD Request and S-BFD Reply. I'm somewhat hesitant, even if chairs might look at this proposal kindly, to re-use defined in Base BFD flags. At the same time, though yet implicit, we need the mechanism to work with non-IP encapsulation of BFD, i.e. VCCV/G-ACh. As defined, S-BFD Request being sent to new well-known Destination UDP port. I think that S-BFD Reply may be sent to another well-known Destination UDP port. (We may even use it as Source UDP port in S-BFD Request). And for non-IP encapsulation S-BFD Response will have its own G-ACh, while S-BFD Reply will have G-ACh of its own.

Please let me know if I've missed this  approach already being discussed.

	Regards,
		Greg

PS. I like BFD.v2 approach better but I think that adding flags would solve our problems for limited time. I agree that TLV-based extensions offer more powerful and flexible mechanism.

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Tuesday, March 18, 2014 12:03 PM
To: Marc Binderberger; Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA (mmudigon)
Cc: [email-masked]
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)

Hi Marc, et al,

BFD-Multipoint pointer:

-Nobo

> To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA (mmudigon); 
> Nobo Akiya (nobo)
> Cc: [email-masked]
> hand it avoids dealing with the "flags" which seem to either hit 
> formal or practical problems.
> 
> zero.", both for the originator and the reflector. Unless there is an idea what "echo"
> would mean for S-BFD (which is already pretty close to an echo 
> function itself), what about re-using this field
> 
> allows and to what speed - I would not expect any adverse impact on 
> the initiator side, even when the whole functionality (i.e. the code) 
> is re-used for S-BFD on the initiator side. And RFC5880 doesn't put 
> too many restrictions on echo and "Required Min Echo RX Interval".
> 
> 
> Feedback welcome :-)
> 
> 
> then the idea was the reflector is inserting a local discriminator 
> into the my_discr field when sending out the reflected packet. Nobo 
> >> re-interpreting/overloading 'D' bit. Don't the same arguments that 
> >> we used against 'D' bit apply here too?
> >
> > formally kind of a no-no. At least difficult to change. The P/F bit 
> > use for S-BFD should, as far as I can see, work smoothly with the 
> > existing
> > RFC5880 interpretation.
> >
> > what existing implementations - which we want to re-use largely on 
> > the S-BFD originator side - must support anyway.
> >
> >
> > answer here. It would mean on the S-BFD originator side the hw needs 
> > a differentiation based on the UDP port instead of simply re-using 
> > the existing packet I/O. Or it needs at least a knob to suppress 
> > this F-bit punting (which potentially breaks other things).
> >
> >
> >> through extra logic to process a packet with 'F' bit set I.e to 
> >> know if it is a reflected packet or a response to the poll that is 
> >> initiated.
> >
> > Don't see that. The only difference it to drop F-bit packets when 
> > you are about to reflect them - but the reflector is different 
> > code/hw anyway. Otherwise as mentioned above you have already today 
> > the situation of receiving F-bit packets while your are not in a 
> > Poll sequence (anymore).
> >
> >
> > sigh, this kind of re-using a protocol always has risks and 
> > personally I still think we should introduce v2 BFD with 32 or 64 
> > more bits in an otherwise unchanged header and stop spending time on 
> > these "clever protocol tricks". But then we won't proceed with S-BFD 
> > anymore and have long discussions about the new BFD v2 packet (risk of another "IPv6"
> > Really not any good answer from my side other than we may have to 
> > look further for something else to "overload".
> >
> >
> > Regards, Marc
> >
> >
> >
> >> B to A: [p=0.F=1] ==> pong packet with ack for timer poll B to A: 
> >> [p=1,F=0] ==> Reflector initiated poll
> >>
> >> We have a few questions:
> >>
> >> re-interpreting/overloading 'D' bit. Don't the same arguments that 
> >> we used against 'D' bit apply here too?
> >> through extra logic to process a packet with 'F' bit set I.e to 
> >> know if it is a reflected packet or a response to the poll that is 
> >> initiated.
> >>  Thanks
> >>
> >> Regards
> >> Mallik
> >>>> So, I suppose the suggested addition to the S-BFD logic is "in 
> >>>> the absence of a P-bit, F will still be set for security purposes 
> >>>> upon reflection."
> >>> This  is certainly lesser evil than other evil ideas (especially 
> >>> v2 BFD), I'll take it :) S-BFD authors/collaborators & BFDers, 
> >>> comments?
> >> Base document should document on how those bits should be used, 
> >> that includes any interval change.
> >>> [Jeff wrote]
> >>>> If a reflector wants to tell an Initiator to slow down, it would 
> >>>> simply need to inject an additional packet (perhaps a DoS on its 
> >>>> own, so should be
> >>>> ah well, we simply don't have enough flags in the BFD packet. You 
> >>>> are sure we don't want a BFD "v2" to add another 32/64 bit for 
> >>>> future flag use? ;-)
> >>> I am very sure :)
> >>> [Marc wrote]
> >>>> But seriously: as the S-BFD sender is effectively talking to 
> >>>> itself you do not need P/F to synchronize two systems. The 
> >>>> reflector can simply set the Required Min RX Interval as it wants 
> >>>> and the S-BFD sender adjusts.
> >>> True that's definitely a possibility, but someone will surely 
> >>> argue that changing interval w/o presence of P bit will violate RFC5880.
> >> But if S-BFD could set rx interval differently to regular BFD as 
> >> long as we document it right, we wouldn't  be violating RFC5880, 
> >> IMO. Do you think RFC is rigid about interval change?
> >>> [Marc wrote]
> >>>> Also: as Jeff mentioned, without any "session state" on the 
> >>>> reflector side it would be difficult to match any received F bit 
> >>>> to a particular P sent out?
> >>>> Subject: Re: Loop Prevention in S-BFD 
> >>>> (draft-akiya-bfd-seamless-base) On Thu, Mar 13, 2014 at 08:17:22PM +0000, Nobo Akiya (nobo) wrote:
> >>>>>> document, but since the reflector is intended to be stateless 
> >>>>>> why would it expect to receive a Final from the Initiator?
> >>>> initiator that parameter has changed (i.e. Required Min RX 
> >>>> Interval has changed).
> >>>> Remember that the primary reason for the Required Min RX Interval 
> >>>> in regular BFD is that the receiver is also running a timer and 
> >>>> will use that for its state by helping to adjust the sender's 
> >>>> speed in a graceful fashion.
> >>>> In this case, graceful is important since only the Initiator 
> >>>> cares about the actual timing of the packets.
> >>>> As long as each side doesn't respond to F packets (but sends 
> >>>> them), I think we're still good.  I think this means you can keep 
> >>>> the poll bit idea to help suggest an Initiator to slow down and 
> >>>> still prevent DoS.  In such a scenario, M is injecting packets to 
> >>>> A, with or without P, using B's addressing.  Without P, A could 
> >>>> still respond with F and B would drop it.
> >>>> So, I suppose the suggested addition to the S-BFD logic is "in 
> >>>> the absence of a P-bit, F will still be set for security purposes 
> >>>> upon reflection."
> >>>> If a reflector wants to tell an Initiator to slow down, it would 
> >>>> simply need to inject an additional packet (perhaps a DoS on its 
> >>>> own, so should be

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 19 Mar 2014 04:46:40 +0000

Hi Marc,

All I am saying is that we should not bump the version # till we have a use case where we cant work with the existing fields at all and the change required is so radical that upping the version # is the only recourse left.

The other point, that I was rather unsuccessfully, trying to make was that without a use case in mind, defining a new BFD header will not work as you will still end up with cases where the new header will not be sufficient. Will we then move to BFD v3?

> your email. The rest is "why this won't work". With this attitude no

The flaw you mention is the lack of more bits to extend BFD. Quoting your earlier email "Even if we do a good job it's still likely to cause some trouble, simply because of BFDs success and the resulting number of implementations."

This argument stands on tenuous grounds if you cant exactly qualify the "trouble" that overloading certain bits can cause. We cant just say that there will be trouble and start looking at radical changes in a protocol. This obviously changes if you can think of the issues we can expect when we start overloading certain fields -- in this specific case the "D" bit.

Cheers, Manav

> Sent: Tuesday, March 18, 2014 11:16 PM
> To: Bhatia, Manav (Manav)
> Subject: RE: BFD v2?
> >> personally
> >>>> I still think we should introduce v2 BFD with 32 or 64 more bits
> in
> >> an
> >>> once ever few milliseconds? If the answer is no, BFD may be the
> wrong
> >> place
> >>> for it.
> >>>

---

From: "MALLIK MUDIGONDA (mmudigon)" <[email-masked]>
Date: Wed, 19 Mar 2014 09:11:09 +0000

Hi Marc,

Yes, as you said there are different ways of doing this. Since we have a precedent for the 'M' bit getting updated in the latest multi-point draft, we thought we will take the same route for our 'D' bit usage which is also, like your echo Rx interval filed, pretty simple to implement.

Regarding the discriminator usage for solving this, we do not want to put any specific restrictions on the way discriminators are used. That's the reason the thread stopped there. Can't think of any particular use case where MyDisc is used to demux, but that's the reason not  to impose this restriction.

Thanks

Regards
Mallik

From: "Nobo Akiya (nobo)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 19 March 2014 12:33 AM
To: Marc Binderberger <[email-masked]<mailto:[email-masked]>>, "Vengada Prasad Govindan (venggovi)" <[email-masked]<mailto:[email-masked]>>, Cisco Employee <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)

Hi Marc, et al,

BFD-Multipoint pointer:

-Nobo

-----Original Message-----
From: Marc Binderberger [mailto:[email-masked]]
Sent: Tuesday, March 18, 2014 2:53 PM
To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA
On Mon, 17 Mar 2014 10:36:30 -0700, Marc Binderberger wrote:
>>>> simply need to
>>>> are sure
>>>> reflector side it
>>>> simply need to

---

From: "MALLIK MUDIGONDA (mmudigon)" <[email-masked]>
Date: Wed, 19 Mar 2014 12:14:28 +0000

Hi Greg,

Definitely this is an option that would work. It requires allocation of two well-known UDP ports and also two G-Ach for non-ip encapsulations. The current discussions are all focussed on resolving the issue with BFD header fields so that it is independent of the encapsulations.
We would like to hear comments from others on this.

Thanks

Regards
Mallik

From: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 19 March 2014 7:33 AM
To: "Nobo Akiya (nobo)" <[email-masked]<mailto:[email-masked]>>, Marc Binderberger <[email-masked]<mailto:[email-masked]>>, "Vengada Prasad Govindan (venggovi)" <[email-masked]<mailto:[email-masked]>>, Cisco Employee <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)

Dear All,

Regards,
Greg

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Tuesday, March 18, 2014 12:03 PM
To: Marc Binderberger; Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA (mmudigon)
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)

Hi Marc, et al,

BFD-Multipoint pointer:

-Nobo

-----Original Message-----
From: Marc Binderberger [mailto:[email-masked]]
Sent: Tuesday, March 18, 2014 2:53 PM
To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA (mmudigon);
Nobo Akiya (nobo)
On Mon, 17 Mar 2014 10:36:30 -0700, Marc Binderberger wrote:
>> (draft-akiya-bfd-seamless-base)
>>
>> Hi All,
>>
>> (draft-akiya-bfd-seamless-base)
>>
>> Comments inline.
>>
>> Sent from my iPad
>>

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 19 Mar 2014 08:25:01 -0700

Hello Mallik,

we will see how the discussion goes although I personally do not think 
the M and D bit can be compared. Seems other people didn't see D a good 
fit (formally) either. Anyway, I'll have a look again at the "M" bit 
and the multipoint draft.

> Regarding the discriminator usage for solving this, we do not want to 
> put any specific restrictions on the way discriminators are used. 

what restriction?

> That's the reason the thread stopped there. Can't think of any 
> particular use case where MyDisc is used to demux, but that's the 
> reason not  to impose this restriction.

Huh?!  There is some misunderstanding here, so let me repeat the 
discriminator idea:

(1) S-BFD initiator R1 sends a BFD packet to reflector R2

(2) Reflector R2 copies the my_discr from incoming packet into 
your_discr for outgoing packet.

(3) Reflector R2 copies one of his local discriminator values into 
my_discr of the outgoing packet. This local discriminator is not a 
"reflector discriminator" of R2.

(4) The S-BFD initiator R1 is doing normal BFD operations by looking 
into the your_discr of the reflected packet to demux.

Especially R1 is not using "my_discr" of the reflected packet to demux.

The point is: when someone is injecting an "endless loop" packet by 
using the "reflector discriminator" of R1 as my_discr, the reflector 
discriminator of R2 as your_discr and sends the packet to R2 then the 
steps above result in a packet

   attacker -> R2 -> R1 -> R2 -> drop/punt

So after maximum 2 reflections the loop is broken.

Regards, Marc

On Wed, 19 Mar 2014 09:11:09 +0000, MALLIK MUDIGONDA (mmudigon) wrote:
> Hi Marc,
> 
> Yes, as you said there are different ways of doing this. Since we 
> have a precedent for the 'M' bit getting updated in the latest 
> multi-point draft, we thought we will take the same route for our 'D' 
> bit usage which is also, like your echo Rx interval filed, pretty 
> simple to implement.
> 
> Regarding the discriminator usage for solving this, we do not want to 
> put any specific restrictions on the way discriminators are used. 
> That's the reason the thread stopped there. Can't think of any 
> particular use case where MyDisc is used to demux, but that's the 
> reason not  to impose this restriction.
> 
> Thanks
> 
> Regards
> Mallik  
> 
> To: Marc Binderberger <[email-masked]>, "Vengada Prasad Govindan 
> (venggovi)" <[email-masked]>, Cisco Employee <[email-masked]>
> Just wanted to let you and others know that few of us have been 
> studying how BFD-Multipoint draft updated RX procedures of RFC5880, 
> we should be able to provide an update to this thread soon.
> 
> BFD-Multipoint pointer:
>> In the above P/F approach, we are still overloading the
>> Most of the H/W based implementations use P/F bits to
>> punt the
>> 'F' bit itself is now ambiguous. Implementations will have to
>> go
>> In the above P/F approach, we are still overloading the
>> Most of the H/W based implementations use P/F bits to
>> punt the
>> 'F' bit itself is now ambiguous. Implementations will have to
>> go
>> Interval has

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 19 Mar 2014 15:52:17 +0000

> we will see how the discussion goes although I personally do not think the
> M and D bit can be compared. Seems other people didn't see D a good fit
> (formally) either. Anyway, I'll have a look again at the "M" bit and the
> multipoint draft.

You are right Marc, M and D bit alone is not a good comparison. However, it's not just M bit that's updated in the multipoint draft. Multipoint draft updates M bit, introduces new state variables (bfd.SessionType) and updates RX procedures.

Take a look at following sections in the multipoint draft.
4.4.1. New State Variable
4.16.1. Reception of BFD Control Packets
4.16.2. Demultiplexing BFD Control Packets

Since your_discrim in S-BFD (both directions) is never zero(0), bfd.SessionType is derivable for all cases. And D bit check can be added for new bfd.SessionType values defined for S-BFD (both directions), as part of RX procedures. Not only this approach doesn't require BFDv2, it also addresses the point raised by Greg (i.e. support for non-IP based S-BFD).

-Nobo

> Sent: Wednesday, March 19, 2014 11:25 AM
> To: MALLIK MUDIGONDA (mmudigon)
> Cc: Nobo Akiya (nobo); Vengada Prasad Govindan (venggovi); rtg-
> [email-masked]
> we will see how the discussion goes although I personally do not think the
> M and D bit can be compared. Seems other people didn't see D a good fit
> (formally) either. Anyway, I'll have a look again at the "M" bit and the
> multipoint draft.
> 
> 
> (2) Reflector R2 copies the my_discr from incoming packet into your_discr
> for outgoing packet.
> 
> (3) Reflector R2 copies one of his local discriminator values into my_discr of
> the outgoing packet. This local discriminator is not a "reflector
> discriminator" of R2.
> 
> (4) The S-BFD initiator R1 is doing normal BFD operations by looking into the
> your_discr of the reflected packet to demux.
> 
> The point is: when someone is injecting an "endless loop" packet by using
> the "reflector discriminator" of R1 as my_discr, the reflector discriminator of
> R2 as your_discr and sends the packet to R2 then the steps above result in a
> packet
> 
> > Yes, as you said there are different ways of doing this. Since we have
> > a precedent for the 'M' bit getting updated in the latest multi-point
> > draft, we thought we will take the same route for our 'D'
> > studying how BFD-Multipoint draft updated RX procedures of RFC5880, we
> > should be able to provide an update to this thread soon.
> >
> > BFD-Multipoint pointer:
> >> idea what "echo"
> >> Basically the flag idea, just a different field. As echo
> >> functionality is driven on the initiator side - the remote side only
> >> informs if it allows and to what speed - I would not expect any
> >> adverse impact on the initiator side, even when the whole
> >> functionality (i.e. the code) is re-used for S-BFD on the initiator
> >> side. And RFC5880 doesn't put too many restrictions on echo and
> "Required Min Echo RX Interval".
> >>
> >>
> >> Feedback welcome :-)
> >>
> >>
> >> Btw, what happened to the discriminator discussion?  If I recall
> >> right then the idea was the reflector is inserting a local
> >> discriminator into the my_discr field when sending out the reflected
> >> packet. Nobo mentioned this makes it impossible to differentiate
> >> reflectors - I admit he lost me at this point ;-) Was this discussion
> conclusive?
> >> Most of the H/W based implementations use P/F bits to punt the
> >> 'F' bit itself is now ambiguous. Implementations will have to go
> >> Most of the H/W based implementations use P/F bits to punt the
> >> 'F' bit itself is now ambiguous. Implementations will have to go

---

From: "MALLIK MUDIGONDA (mmudigon)" <[email-masked]>
Date: Wed, 19 Mar 2014 15:55:09 +0000

Hi Marc,

Yes, that was the original proposal. This was the original comment from Nobo for the discriminator proposal:

"Deviating discriminator by reflector session - Proposed will prevent a single S-BFD session to speak to multiple reflectors (cannot do reply demux'ing), if implementation wants to do this or if there is ever such use-case."

Even as per the original proposal, each reflector can have its own local discriminator value allocated. So in theory, every reflector can have a different discriminator.

Nobo,

Any comments?

Thanks

Regards
Mallik
From: Marc Binderberger <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 19 March 2014 8:55 PM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>
Cc: "Nobo Akiya (nobo)" <[email-masked]<mailto:[email-masked]>>, "Vengada Prasad Govindan (venggovi)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)

Hello Mallik,

what restriction?

Regards, Marc

To: Marc Binderberger <[email-masked]<mailto:[email-masked]>>, "Vengada Prasad Govindan
(venggovi)" <[email-masked]<mailto:[email-masked]>>, Cisco Employee <[email-masked]<mailto:[email-masked]>>
-----Original Message-----
From: Marc Binderberger [mailto:[email-masked]]
Sent: Tuesday, March 18, 2014 2:53 PM
To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA
avoids dealing with the "flags" which seem to either hit formal or
practical
both for the originator and the reflector. Unless there is an idea
what "echo"
"Required

1.

2.

3.

Regards, Marc

Hi All,

Normal Sequence

Timer negotiation (ack)

We have a few questions:

1.

Regards
Mallik

Comments inline.

Sent from my iPad

On Mar 13, 2014, at 1:48 PM, "Nobo Akiya (nobo)" <[email-masked]<mailto:[email-masked]>>
wrote:
Hi Jeff, Marc, BFDers,
[Jeff wrote]
So, I suppose the suggested addition to the S-BFD logic is "in the
absence of
a P-bit, F will still be set for security purposes upon reflection."
This  is certainly lesser evil than other evil ideas (especially v2
BFD), I'll take it :)
S-BFD authors/collaborators & BFDers, comments?
(speak now or forever hold your peace)
Catching on this long email thread, finally.

I too prefer not going v2 way, as it creates more complexity or open
up many more issues.
P/F bits as suggested by Jeff is a good option and we should use it.
Base document should document on how those bits should be used, that
includes any interval change.
[Jeff wrote]
If a reflector wants to tell an Initiator to slow down, it would
simply need to
inject an additional packet (perhaps a DoS on its own, so should be
rate-limited) with the P bit set.  This is effectively the
"dueling poll"
scenario that had popped up much earlier in standardization.
So bit it.
[Marc wrote]
ah well, we simply don't have enough flags in the BFD packet. You
are sure
we don't want a BFD "v2" to add another 32/64 bit for future flag
use? ;-)
I am very sure :)
[Marc wrote]
But seriously: as the S-BFD sender is effectively talking to itself
you do not
need P/F to synchronize two systems. The reflector can simply set the
Required Min RX Interval as it wants and the S-BFD sender adjusts.
True that's definitely a possibility, but someone will surely argue
that changing interval w/o presence of P bit will violate RFC5880.
If it deviates from the way the P bit is presently being used, true.
But if S-BFD could set rx interval differently to regular BFD as long
as we document it right, we wouldn't  be violating RFC5880, IMO. Do
you think RFC is rigid about interval change?
[Marc wrote]
Also: as Jeff mentioned, without any "session state" on the
reflector side it
would be difficult to match any received F bit to a particular P
sent out?
With new proposal by Jeff, [P=0, F=1] will be dropped by reflector
now. Reflector can still send [P=1, F=0], but that is
one-way-communication/request.

Nod.

Sam
-Nobo
-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]]
Sent: Thursday, March 13, 2014 4:28 PM
To: Nobo Akiya (nobo)
Cc: Jeffrey Haas; Marc Binderberger; [email-masked]<mailto:[email-masked]>
Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)
On Thu, Mar 13, 2014 at 08:17:22PM +0000, Nobo Akiya (nobo) wrote:
I may be mis-remembering the conversation or mis-reading the
document, but since the reflector is intended to be stateless why
would it expect to receive a Final from the Initiator?
It doesn't, reflector doesn't expect F bit (hence best effort). P
bit will alert
initiator that parameter has changed (i.e. Required Min RX
Interval has
changed).
Remember that the primary reason for the Required Min RX Interval in
regular BFD is that the receiver is also running a timer and will
use that for
its state by helping to adjust the sender's speed in a graceful
fashion.
In this case, graceful is important since only the Initiator cares
about the
actual timing of the packets.
And even then, for our original scenario:
A---M---B
As long as each side doesn't respond to F packets (but sends them),
I think
we're still good.  I think this means you can keep the poll bit
idea to help
suggest an Initiator to slow down and still prevent DoS.  In such a
scenario, M
is injecting packets to A, with or without P, using B's
addressing.  Without P,
A could still respond with F and B would drop it.
So, I suppose the suggested addition to the S-BFD logic is "in the
absence of
a P-bit, F will still be set for security purposes upon reflection."
If a reflector wants to tell an Initiator to slow down, it would
simply need to
inject an additional packet (perhaps a DoS on its own, so should be
rate-limited) with the P bit set.  This is effectively the
"dueling poll"
scenario that had popped up much earlier in standardization.
-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 19 Mar 2014 12:37:39 -0400

On Wed, Mar 19, 2014 at 04:46:40AM +0000, Bhatia, Manav (Manav) wrote:
> All I am saying is that we should not bump the version # till we have a
> use case where we cant work with the existing fields at all and the change
> required is so radical that upping the version # is the only recourse
> left.

This largely reflects my opinion.  The second half of that opinion is "send
at wire rate".

In the life of BFD, we've successfully resisted and engineered our way
around the urge to extend it for various things to keep the core use cases
of the protocol.  Once we can no longer do that, then it's time to look at
bumping the version.

I'm not convinced the s-bfd stuff has pushed us there quite yet.

-- Jeff

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 19 Mar 2014 16:38:27 +0000

The protocol pieces of S-BFD is in three folds:
1. Discriminator mapping/advertisement.
2. Reflector session procedures.
3. Procedures to interact with reflector session.

As long as S-BFD initiator implementation conforms to (3), the rest of S-BFD initiator behaviors are not bound by the protocol, i.e. one is free to use the S-BFD "infrastructure" in any way (i.e. when to start, stop, slow down, round-robin a set of paths, monitor set of [same, diff] targets which results are fed into specific algorithm, whatever it may be). Imagine a network with S-BFD, be it IP, MPLS or SR. Every network node has reflector(s) and every network node knows discriminator(s) of other reflector(s). In such network, one is really free to implement all sorts of S-BFD initiator(s) ... based on specific [existing, new] use-cases and customer demands.

Deviating discriminator approach ... technically fine, but I prefer not to go with it as it can limit S-BFD initiator freedom which may cost us a lot more in long term.
	
-Nobo

> Sent: Wednesday, March 19, 2014 11:55 AM
> To: Marc Binderberger
> "Deviating discriminator by reflector session - Proposed will prevent a
> case."
> Even as per the original proposal, each reflector can have its own local
> discriminator value allocated. So in theory, every reflector can have a
> different discriminator.
> 
> Nobo,
> 
> Any comments?
> 
> Thanks
> 
> Regards
> Mallik
> From: Marc Binderberger <[email-masked]>
> To: Cisco Employee <[email-masked]>
> Cc: "Nobo Akiya (nobo)" <[email-masked]>, "Vengada Prasad Govindan
> (venggovi)" <[email-masked]>, "[email-masked]" <[email-masked]>

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 19 Mar 2014 10:55:02 -0700

Hello Nobo,

> Deviating discriminator approach ... technically fine, but I prefer 
> not to go with it as it can limit S-BFD initiator freedom which may 
> cost us a lot more in long term.

sorry but this is just too vague. The initiator receives back his own 
discriminator as your_disc in the incoming packet and that should be 
enough. You have a different session or destination or whatever else is 
different - give it a unique local discriminator to separate it.

The my_discr field never had much meaning for the receiving BFD entity 
and this worked great for BFD as a general rule.

Regards, Marc

On Wed, 19 Mar 2014 16:38:27 +0000, Nobo Akiya (nobo) wrote:
> As long as S-BFD initiator implementation conforms to (3), the rest 
> of S-BFD initiator behaviors are not bound by the protocol, i.e. one 
> is free to use the S-BFD "infrastructure" in any way (i.e. when to 
> start, stop, slow down, round-robin a set of paths, monitor set of 
> [same, diff] targets which results are fed into specific algorithm, 
> whatever it may be). Imagine a network with S-BFD, be it IP, MPLS or 
> SR. Every network node has reflector(s) and every network node knows 
> discriminator(s) of other reflector(s). In such network, one is 
> really free to implement all sorts of S-BFD initiator(s) ... based on 
> specific [existing, new] use-cases and customer demands.
> 
> Deviating discriminator approach ... technically fine, but I prefer 
> not to go with it as it can limit S-BFD initiator freedom which may 
> cost us a lot more in long term.
> 	
> -Nobo
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 20 Mar 2014 00:00:43 +0000

Adding on top of what Nobo has already said.

New bfd.SessionType variables can be defined for S-BFD clients and reflectors. The S-BFD draft will update the "D" bit based on the bfd.SessionType variable. This requires no other changes to 5880/5881. The S-BFD draft should unequivocally define what the "D" bit means in the context of the S-BFD packets.

It can still be called the "D" (demand) bit and will be redefined to something like below:

Demand (D)

S-BFD clients MUST always set the "D" bit which directs the S-BFD reflector to reflect the S-BFD packets that it receives. The S-BFD reflectors should discard all packets that come with the D bit clear.

S-BFD clients MUST always ignore packets coming with the "D" bit set.

Please note that we will always know the S-BFD clients/reflectors since they would use a new UDP port.

I like this approach over the one that uses descriminator values simply because examining a bit to detect a loop is much easier to implement in hardware. Looking at the descriminator values and then detecting a loop cannot be easily done in HW.

Since the approach using the "D" bit seems to be acceptable to quite a few folks here, I would like to understand the reason, if any, for opposing this.

Cheers, Manav

> Sent: Wednesday, March 19, 2014 9:22 PM
> To: Marc Binderberger; MALLIK MUDIGONDA (mmudigon)
> Cc: [email-masked]
> You are right Marc, M and D bit alone is not a good comparison.
> However, it's not just M bit that's updated in the multipoint draft.
> Multipoint draft updates M bit, introduces new state variables
> (bfd.SessionType) and updates RX procedures.
> 
> Since your_discrim in S-BFD (both directions) is never zero(0),
> bfd.SessionType is derivable for all cases. And D bit check can be
> added for new bfd.SessionType values defined for S-BFD (both
> directions), as part of RX procedures. Not only this approach doesn't
> require BFDv2, it also addresses the point raised by Greg (i.e. support
> for non-IP based S-BFD).
> 
> -Nobo
> 
> my_discr of
> into the
> using

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 20 Mar 2014 00:50:04 +0000

Agree with Manav.

One nit and one clarification.

> S-BFD clients MUST always set the "D" bit which directs the S-BFD reflector
> to reflect the S-BFD packets that it receives. The S-BFD reflectors should
> discard all packets that come with the D bit clear.

s/The S-BFD reflectors should discard/The S-BFD reflectors MUST discard/

> would use a new UDP port.

If implementation shares the local discriminator pool between BFD and S-BFD, then session object located with your_discrim in incoming packet will provide the bfd.SessionType. In this implementation, non-IP based S-BFD can be supported without new G-Ach code point for S-BFD. If implementation does not share the local discriminator pool between BFD and S-BFD, then UDP port is required to first figure out which table to lookup the session object, in which case will provide BFD or S-BFD answer. In this implementation, non-IP based S-BFD will require separate G-Ach code point than BFD (but one new G-Ach code point for S-BFD should be sufficient). We should probably assume that the latter is needed.

-Nobo

> From: Bhatia, Manav (Manav) [mailto:[email-masked]]
> Sent: Wednesday, March 19, 2014 8:01 PM
> New bfd.SessionType variables can be defined for S-BFD clients and
> reflectors. The S-BFD draft will update the "D" bit based on the
> bfd.SessionType variable. This requires no other changes to 5880/5881. The
> S-BFD draft should unequivocally define what the "D" bit means in the
> context of the S-BFD packets.
> 
> S-BFD clients MUST always set the "D" bit which directs the S-BFD reflector
> to reflect the S-BFD packets that it receives. The S-BFD reflectors should
> discard all packets that come with the D bit clear.
> 
> I like this approach over the one that uses descriminator values simply
> because examining a bit to detect a loop is much easier to implement in
> hardware. Looking at the descriminator values and then detecting a loop
> cannot be easily done in HW.
> 
> Since the approach using the "D" bit seems to be acceptable to quite a few
> folks here, I would like to understand the reason, if any, for opposing this.
> 
> Cheers, Manav
> 
> > 4.16.1. Reception of BFD Control Packets 4.16.2. Demultiplexing BFD
> > Control Packets
> >
> > require BFDv2, it also addresses the point raised by Greg (i.e.
> > support for non-IP based S-BFD).
> >
> > -Nobo
> >

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 19 Mar 2014 18:07:58 -0700

Hello Jeff, Manav et al.,

> I'm not convinced the s-bfd stuff has pushed us there quite yet.

if I see the amount of discussions for a problem like the endless-loop 
then I think it is time to think forward, before we hit "there".

Sure we will find a solution somehow for the loop problem within v1 - 
nobody wants to delay this work, including me. I'm just using this 
example as it highlights so nicely what I think is going wrong 
meanwhile.

All we need is a fresh flag, without the "clever" reuse of existing 
fields or the clever word-twisting (or sometimes just bold statements) 
why a reuse is "okay". 

>> use case where we cant work with the existing fields at all

A sharp line of "can't work" does not exist. It's always opinions. And 
if you have a new feature with customers asking for standardization 
then there will be always a way in v1, no matter how "bent".

If the situation is so painful that everyone wants to give in to "v2" 
then it's too late. We would do a rush job for "v2" then where we 
should 
take (some) time.  

> The second half of that opinion is "send at wire rate".

I understand this as an advice for BFD protocol design but don't see 
what this has to do with v1 vs. v2 (?).

Regards, Marc

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 20 Mar 2014 03:42:25 +0000

Hi Marc,

> then it's too late. We would do a rush job for "v2" then where we

A painful situation is not the only time when we might want to move to v2. We may also want to do it, if for example, we want to extend BFD for OAM. Today we only get a binary result from BFD. i.e., in the context of S-BFD, the client only knows whether it can reach the reflector/server or not. In case it cant, the client has no idea of where the fault lies. Now, if the industry wants BFD to be extended to help diagnose such issues (isolate the fault), then the changes to the protocol would be significant and this could be a candidate for a version bump.

Cheers, Manav

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 20 Mar 2014 05:29:00 +0000

Hi Manav,
IP OAM, unlike for example Ethernet Service OAM, is very fragmented indeed. If we compare IP OAM with Y.1731, then BFD is most close to ETH-CC. Fault isolation would done through by traceroute and ETH-LT respectively. And the comparison can be continued to Performance Measurement with OWAMP/TWAMP comparable to 1DM and DMM/DMR. As I think, there are couple of functions Y.1731 that yet unmatched by IP OAM. Hence my question Does "we want to extend BFD for OAM" mean extending BFD to match Y.1731 functionality? IMO, this is very interesting topic to discuss.

	Regards,
		Greg

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: Wednesday, March 19, 2014 8:42 PM
To: Marc Binderberger; Jeffrey Haas
Cc: [email-masked]
Subject: RE: BFD v2?

Hi Marc,

> should take (some) time.

Cheers, Manav

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 20 Mar 2014 05:36:52 +0000

Hi,

I fully agree with Greg here - perhaps we should take time and discuss what is that we have been missing in the current incarnation of BFD and what are the problems we'd want v2 to solve.
Most vendors have implemented BFD in silicon, any significant changes, unless absolutely critical would not justify amount of work and changes  needed to accommodate such thing.

Regards,
Jeff

> On Mar 19, 2014, at 10:29 PM, "Gregory Mirsky" <[email-masked]> wrote:
> 
> Hi Manav,

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 20 Mar 2014 06:37:30 +0000

Hi Greg,

I had taken extending BFD for OAM only as an example of when we may potentially need to go in for a version bump.

> As I think,
> there are couple of functions Y.1731 that yet unmatched by IP OAM.
> Hence my question Does "we want to extend BFD for OAM" mean extending
> BFD to match Y.1731 functionality? IMO, this is very interesting topic
> to discuss.

Don't we have most of what Y.1731 offers available for MPLS networks? Did you mean the gaps in OAM for pure IP (non-MPLS) networks?

Cheers, Manav

> Sent: Thursday, March 20, 2014 10:59 AM
> To: Bhatia, Manav (Manav); Marc Binderberger; Jeffrey Haas
> Cc: [email-masked]
> Subject: RE: BFD v2?
> 
> Hi Manav,
> IP OAM, unlike for example Ethernet Service OAM, is very fragmented
> indeed. If we compare IP OAM with Y.1731, then BFD is most close to
> ETH-CC. Fault isolation would done through by traceroute and ETH-LT
> respectively. And the comparison can be continued to Performance
> Measurement with OWAMP/TWAMP comparable to 1DM and DMM/DMR. As I think,
> there are couple of functions Y.1731 that yet unmatched by IP OAM.
> Hence my question Does "we want to extend BFD for OAM" mean extending
> BFD to match Y.1731 functionality? IMO, this is very interesting topic
> to discuss.
> 
> 	Regards,
> 		Greg
> 
> A painful situation is not the only time when we might want to move to
> v2. We may also want to do it, if for example, we want to extend BFD
> for OAM. Today we only get a binary result from BFD. i.e., in the
> context of S-BFD, the client only knows whether it can reach the
> reflector/server or not. In case it cant, the client has no idea of
> where the fault lies. Now, if the industry wants BFD to be extended to
> help diagnose such issues (isolate the fault), then the changes to the
> protocol would be significant and this could be a candidate for a
> version bump.
> 
> Cheers, Manav
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 20 Mar 2014 06:44:44 +0000

> 
> Don't we have most of what Y.1731 offers available for MPLS networks?
> Did you mean the gaps in OAM for pure IP (non-MPLS) networks?

And gaps in OAM for segment routed networks. 

Cheers, Manav

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 20 Mar 2014 07:01:07 +0000

Hi Manav,
right, MPLS OAM is much functionally closer to Y.1731 though there are some missing functions among them experimental and vendor-specific might be of interest for us. But I'll note that MPLS Performance Measurement RFC 6374 and MPLS-TP profile RFC 6375 need metrics definitions at least.
Yes, I did mean non-MPLS IP. Segment Routed networks - no so much, considering that MPLS dataplane may make MPLS OAM re-usable in SPRING. (That to be seen after we finish SPRING OAM Requirements and gap analysis).

	Regards,
		Greg

-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:[email-masked]] 
Sent: Wednesday, March 19, 2014 11:45 PM
To: Gregory Mirsky
Cc: [email-masked]
Subject: RE: BFD v2?

Cheers, Manav

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 20 Mar 2014 07:17:35 +0000

Hi Greg,

Ideally the demand should come from the operators in case they need enhanced IP OAM capabilities (loss measurement, an equivalent of a link trace, etc) for pure IP networks. Has anybody ever asked for this? I am aware of the ECMP issue where the IP OAM does not follow the traffic. But besides that, is there anything else that folks have been asking for?

Cheers, Manav

> Sent: Thursday, March 20, 2014 12:31 PM
> right, MPLS OAM is much functionally closer to Y.1731 though there are
> some missing functions among them experimental and vendor-specific
> might be of interest for us. But I'll note that MPLS Performance
> Measurement RFC 6374 and MPLS-TP profile RFC 6375 need metrics
> definitions at least.
> Yes, I did mean non-MPLS IP. Segment Routed networks - no so much,
> considering that MPLS dataplane may make MPLS OAM re-usable in SPRING.
> (That to be seen after we finish SPRING OAM Requirements and gap
> analysis).
> 
> 	Regards,
> 		Greg
>

---

From: "Sam K. Aldrin" <[email-masked]>
Date: Thu, 20 Mar 2014 02:29:43 -0700

I would like to see requirements coming in from carriers as well.
We might be over engineering, if there is no real need for doing so.

There are different mechanisms, standard/proprietary for IP.
Rather than revising BFD to increase the scope to making it heavy weight, one needs to have real justification for 'why BFD?'.

cheers
-sam

---

From: Santosh P K <[email-masked]>
Date: Thu, 20 Mar 2014 11:01:24 +0000

Nobo,
  I am confused with your statement below. Can you please clarify?

> If implementation shares the local discriminator pool between BFD and S-BFD,
> then session object located with your_discrim in incoming packet will provide
> the bfd.SessionType.

If pool is shared then how can your_disc help to get the sessionType? Did you mean not share pool between BFD and S-BFD? 

Thanks
Santosh P K

> Sent: Thursday, March 20, 2014 6:20 AM
> To: Bhatia, Manav (Manav); Marc Binderberger
> Cc: [email-masked]
> > S-BFD clients MUST always set the "D" bit which directs the S-BFD
> > reflector to reflect the S-BFD packets that it receives. The S-BFD
> > reflectors should discard all packets that come with the D bit clear.
> 
> If implementation shares the local discriminator pool between BFD and S-BFD,
> then session object located with your_discrim in incoming packet will provide
> the bfd.SessionType. In this implementation, non-IP based S-BFD can be
> supported without new G-Ach code point for S-BFD. If implementation does not
> share the local discriminator pool between BFD and S-BFD, then UDP port is
> required to first figure out which table to lookup the session object, in which
> case will provide BFD or S-BFD answer. In this implementation, non-IP based S-
> BFD will require separate G-Ach code point than BFD (but one new G-Ach code
> point for S-BFD should be sufficient). We should probably assume that the latter
> is needed.
> 
> -Nobo
> 
> > bfd.SessionType variable. This requires no other changes to 5880/5881.
> > The S-BFD draft should unequivocally define what the "D" bit means in
> > the context of the S-BFD packets.
> >
> > S-BFD clients MUST always set the "D" bit which directs the S-BFD
> > reflector to reflect the S-BFD packets that it receives. The S-BFD
> > reflectors should discard all packets that come with the D bit clear.
> >
> > I like this approach over the one that uses descriminator values
> > simply because examining a bit to detect a loop is much easier to
> > implement in hardware. Looking at the descriminator values and then
> > detecting a loop cannot be easily done in HW.
> >
> > Since the approach using the "D" bit seems to be acceptable to quite a
> > few folks here, I would like to understand the reason, if any, for opposing this.
> >
> > Cheers, Manav
> >
> > > > M and D bit can be compared. Seems other people didn't see D a
> > > > good
> > > fit
> > > > (formally) either. Anyway, I'll have a look again at the "M" bit
> > > > and
> > > the
> > > > multipoint draft.
> > >
> > > directions), as part of RX procedures. Not only this approach
> > > doesn't require BFDv2, it also addresses the point raised by Greg (i.e.
> > > > M and D bit can be compared. Seems other people didn't see D a
> > > > good
> > > fit
> > > > (formally) either. Anyway, I'll have a look again at the "M" bit
> > > > and
> > > the
> > > > multipoint draft.
> > > >
> > > >
> > > > > Regarding the discriminator usage for solving this, we do not
> > > > > want
> > > to
> > > > > particular use case where MyDisc is used to demux, but that's
> > > > > the reason not  to impose this restriction.
> > > >

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 20 Mar 2014 11:40:54 +0000

Hi Santosh,

> > If implementation shares the local discriminator pool between BFD and
> > S-BFD, then session object located with your_discrim in incoming
> > packet will provide the bfd.SessionType.
> 
> If pool is shared then how can your_disc help to get the sessionType? Did
> you mean not share pool between BFD and S-BFD?

If we mimic the logic from multipoint draft, it would be something like this.

If the Your Discriminator field is nonzero

    Select a session based on the value of Your Discriminator.
    If no session is found, the packet MUST be discarded.

    If bfd.SessionType is SBFDInitiator

        If Demand (D) bit is set, the packet MUST be discarded.

    Else if bfd.sessionType is SBFDReflector

        If Demand (D) bit is clear, the packet MUST be discarded.

    Else (non S-BFD)

        ... 

-Nobo

> Sent: Thursday, March 20, 2014 7:01 AM
> To: Nobo Akiya (nobo); Bhatia, Manav (Manav); Marc Binderberger
> Cc: [email-masked]
> > If implementation shares the local discriminator pool between BFD and
> > S-BFD, then session object located with your_discrim in incoming
> > packet will provide the bfd.SessionType.
> 
> If pool is shared then how can your_disc help to get the sessionType? Did
> you mean not share pool between BFD and S-BFD?
> 
> 
> Thanks
> Santosh P K
> 
> 
> > If implementation shares the local discriminator pool between BFD and
> > S-BFD, then session object located with your_discrim in incoming
> > packet will provide the bfd.SessionType. In this implementation,
> > non-IP based S-BFD can be supported without new G-Ach code point for
> > S-BFD. If implementation does not share the local discriminator pool
> > between BFD and S-BFD, then UDP port is required to first figure out
> > which table to lookup the session object, in which case will provide
> > BFD or S-BFD answer. In this implementation, non-IP based S- BFD will
> > require separate G-Ach code point than BFD (but one new G-Ach code
> > point for S-BFD should be sufficient). We should probably assume that the
> latter is needed.
> >
> > -Nobo
> >
> > > The S-BFD draft should unequivocally define what the "D" bit means
> > > in the context of the S-BFD packets.
> > >
> > > Since the approach using the "D" bit seems to be acceptable to quite
> > > a few folks here, I would like to understand the reason, if any, for
> opposing this.
> > >
> > > Cheers, Manav
> > >
> > > > 4.16.1. Reception of BFD Control Packets 4.16.2. Demultiplexing
> > > > BFD Control Packets
> > > >
> > > > > the outgoing packet. This local discriminator is not a

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 20 Mar 2014 09:02:48 -0400

Agree with Sam and Manav - lets have operator's input. 
V2 may have h/w implications as well, so lets tread carefully??

/himanshu

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Sam K. Aldrin
Sent: Thursday, March 20, 2014 5:30 AM
To: Bhatia, Manav (Manav)
Cc: [email-masked]
Subject: Re: BFD v2?

cheers
-sam
On Mar 20, 2014, at 12:17 AM, Bhatia, Manav (Manav) wrote:

>> right, MPLS OAM is much functionally closer to Y.1731 though there 
>> are some missing functions among them experimental and 
>> vendor-specific might be of interest for us. But I'll note that MPLS 
>> Performance Measurement RFC 6374 and MPLS-TP profile RFC 6375 need 
>> metrics definitions at least.

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 20 Mar 2014 15:24:12 +0000

Hi Manav,
regarding IP Performance Measurement I can point to IPPM WG. Everything that is related to measurement of performance of IP transports (UDP, TCP) and IP-based applications is in scope of IPPM WG. As mentioned earlier, OWAMP and TWAMP protocols support measurement of delay and delay variation both one-way and two-way metrics. As for link trace, I think that traceroute does that already.
The problem of "in-band" OAM does exist and Nobo and I recently talked about it on this thread. I agree with Nobo that if an operator needs in-band OAM over ECMP then hashing must exclude Destination and Source UDP ports.
What's left? That is good question, particularly for operators that plan to use Segment Routing with IPv6 dataplane.

	Regards,
		Greg

-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:[email-masked]] 
Sent: Thursday, March 20, 2014 12:18 AM
To: Gregory Mirsky
Cc: [email-masked]
Subject: RE: BFD v2?

Hi Greg,

Cheers, Manav

---

From: Marc Binderberger <[email-masked]>
Date: Fri, 21 Mar 2014 11:40:23 -0700

Hello Shah et al.,

agree we should do changes for good reasons. Operator input is vital - 
but is not everything. Actually my experience is that operators have an 
idea about the bigger picture, potentially detailed requirements. But 
the rest is "whatever you implement. But make it interoperable" :-)

So there may be operator-driven reasons. There may be reasons from the 
vendor side.

The hardware aspect is interesting. Obviously it's a barrier for 
change, higher than on the software side (if we talk about fixed 
ASICs). But staying with v1 also faces hardware implementation 
difficulties as we make the rules for the few flags more complex over 
time. The feedback from Mallik about P/F flags is a good example where 
it sometimes hurts with v1.

The feedback from several people, showing sympathy to think the 
different direction of "v2" should be taken as an early sign to think 
about this topic. Nobody likes the trouble of change. And I'm not 
saying we are doomed end of this year if you don't agree with me ;-)  
The change aspect may be overestimated, btw.. Technology is changing 
fast and "needs the next I/O card, ASIC, NP" is not so uncommon, the 
writeoff time of 3-5 years for IP equipment.

Regards, Marc

On Thu, 20 Mar 2014 09:02:48 -0400, Shah, Himanshu wrote:
> Rather than revising BFD to increase the scope to making it heavy 
> weight, one needs to have real justification for 'why BFD?'.
> 
> cheers
> -sam
>> Ideally the demand should come from the operators in case they need 
>> enhanced IP OAM capabilities (loss measurement, an equivalent of a 
>> link trace, etc) for pure IP networks. Has anybody ever asked for 
>> this? I am aware of the ECMP issue where the IP OAM does not follow 
>> the traffic. But besides that, is there anything else that folks 
>> have been asking for?
>> 
>> Cheers, Manav
>>

---

From: Marc Binderberger <[email-masked]>
Date: Fri, 21 Mar 2014 17:54:33 -0700

Hello,

may I propose two things:

* the authors of the draft write down what they have in mind for the D 
bit and publish it as -03 draft. Seems this will require a closer look 
at text details, so having it properly written down would be great

* the discussion about the loop prevention should be completed, there 
are several proposals open. I would like to see what options are 
available. Sure, when the authors found a clean path for the "D" bit 
then this is somewhat academic but so far the discussion isn't 
finished, I think

  * the discriminator proposal. I will re-re-read it but have still 
problems to see why the my_discr of a packet received by the initiator 
is used for ... multiplexing? Something else?  Sorry, I may be slow 
thinking here.

  * Girija proposal to use the state. As S-BFD introduces a new state 
machine this seems a valid proposal. Haven't seen any reply on the list 
(beside myself)

  * my "Required Min Echo RX Interval" proposal. If it's wrong or 
"weird" I would like to learn about it.

  * Greg's source UDP port idea (if I understand it right: reflector 
uses S-BFD port as source port + rule: never reflect when source port 
is the well-known S-BFD port).

Basically a summary with why it won't work or at least pros/cons?

Thanks & Regards,
Marc

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sun, 23 Mar 2014 14:56:20 +0000

Hi Marc, et al,

> * the authors of the draft write down what they have in mind for the D bit
> and publish it as -03 draft. Seems this will require a closer look at text
> details, so having it properly written down would be great

There has been many responses around this particular point (and thanks to all who has responded!), it would be a good idea to have a revised document which provides a new starting baseline for further discussions. Although at this point, *rough consensus* does seem to be D-bit approach. We would place the D-bit as the solution, but place all other alternatives in the Appendix.

The other thing which I would like to point out is that, we are actively discussing the solution but not the use-cases ... many of us are engineers!? :) What would be helpful to take S-BFD to the next step (i.e. re-chartering and WG adoption) is for us to discuss more of use-cases on the list.

Thus I'd like to direct some of the attention to the S-BFD use-case draft.

http://tools.ietf.org/html/draft-aldrin-bfd-seamless-use-case-00

Do you [not] agree with use-cases listed?
Do you see any other use-cases which should be added?
Even a comment such as "I agree with this use-case from the draft" is very helpful.

-Nobo

> Sent: Friday, March 21, 2014 8:55 PM
> To: Nobo Akiya (nobo); Santosh P K; Bhatia, Manav (Manav);
> [email-masked]; MALLIK MUDIGONDA (mmudigon)
> Cc: [email-masked]
> * the authors of the draft write down what they have in mind for the D bit
> and publish it as -03 draft. Seems this will require a closer look at text
> details, so having it properly written down would be great
> 
> 
> * the discussion about the loop prevention should be completed, there are
> several proposals open. I would like to see what options are available. Sure,
> when the authors found a clean path for the "D" bit then this is somewhat
> academic but so far the discussion isn't finished, I think
> 
>   * the discriminator proposal. I will re-re-read it but have still problems to
> see why the my_discr of a packet received by the initiator is used for ...
> multiplexing? Something else?  Sorry, I may be slow thinking here.
> 
>   * Girija proposal to use the state. As S-BFD introduces a new state machine
> this seems a valid proposal. Haven't seen any reply on the list (beside
> myself)
> 
>   * my "Required Min Echo RX Interval" proposal. If it's wrong or "weird" I
> would like to learn about it.
> 
>   * Greg's source UDP port idea (if I understand it right: reflector uses S-BFD
> port as source port + rule: never reflect when source port is the well-known
> S-BFD port).
> 
> 
> >>> If implementation shares the local discriminator pool between BFD
> >>> and S-BFD, then session object located with your_discrim in incoming
> >> If pool is shared then how can your_disc help to get the sessionType?
> >> Did you mean not share pool between BFD and S-BFD?
> >
> >>> If implementation shares the local discriminator pool between BFD
> >>> and S-BFD, then session object located with your_discrim in incoming
> >> If pool is shared then how can your_disc help to get the sessionType?
> >> Did you mean not share pool between BFD and S-BFD?
> >>
> >>
> >> Thanks
> >> Santosh P K
> >>
> >>
> >>> If implementation shares the local discriminator pool between BFD
> >>> and S-BFD, then session object located with your_discrim in incoming
> >>> BFD or S-BFD answer. In this implementation, non-IP based S- BFD
> >>> will require separate G-Ach code point than BFD (but one new G-Ach
> >>> code point for S-BFD should be sufficient). We should probably
> >>> assume that the
> >> latter is needed.
> >>>
> >>> -Nobo
> >>>
> >>>> Since the approach using the "D" bit seems to be acceptable to
> >>>> quite a few folks here, I would like to understand the reason, if
> >>>> any, for
> >> opposing this.
> >>>>
> >>>> Cheers, Manav
> >>>>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sun, 23 Mar 2014 15:46:56 +0000

I *think* there are things which protocols/people are *hoping/wanting* OAM to be able to do (perhaps by BFD, perhaps X together with BFD or perhaps not involving BFD at all) ... small[er] items not mentioned.

1. Rapid verification of path/service availability.
2. In-band monitoring via controller device.
3. Per ECMP/UCMP path in-band monitoring.
4. Controlling the return path of in-band monitoring.
5. Deterministically differentiating link-failure vs. node-failure.

[1-3] Solved by S-BFD (3 solved only with specific hashing (ex: EL)).

[4] http://datatracker.ietf.org/doc/rfc7110/ provides one solution, but there is no generic solution.

[5] Nothing out there?

I agree that v2 definition should be driven by specific requirements. Those can be driven by vendors or operators, but we need to have specific requirements before jumping on to defining the v2.

-Nobo

> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Gregory
> Mirsky
> Sent: Thursday, March 20, 2014 11:24 AM
> regarding IP Performance Measurement I can point to IPPM WG. Everything
> that is related to measurement of performance of IP transports (UDP, TCP)
> and IP-based applications is in scope of IPPM WG. As mentioned earlier,
> OWAMP and TWAMP protocols support measurement of delay and delay
> variation both one-way and two-way metrics. As for link trace, I think that
> traceroute does that already.
> The problem of "in-band" OAM does exist and Nobo and I recently talked
> about it on this thread. I agree with Nobo that if an operator needs in-band
> OAM over ECMP then hashing must exclude Destination and Source UDP
> ports.
> enhanced IP OAM capabilities (loss measurement, an equivalent of a link
> trace, etc) for pure IP networks. Has anybody ever asked for this? I am aware
> of the ECMP issue where the IP OAM does not follow the traffic. But besides
> that, is there anything else that folks have been asking for?
> 
> Cheers, Manav
>