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

From: Sam Aldrin <[email-masked]>
Date: Tue, 8 Apr 2014 11:27:19 -0700

Would it be better to see some references to use cases from the base document? That way, it provides right context. Just a thought.

Cheers
Sam
Sent from my iPhone

> On Mar 23, 2014, at 7:56 AM, "Nobo Akiya (nobo)" <[email-masked]> wrote:
> 
> 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
> 
>> -----Original Message-----
>> From: Marc Binderberger [mailto:[email-masked]]
>> 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]
>> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)
>> 
>> 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
>> 
>> 
>> 
>> 
>> 
>>> On Thu, 20 Mar 2014 11:40:54 +0000, Nobo Akiya (nobo) wrote:
>>> 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
>>> 
>>>> -----Original Message-----
>>>> From: Santosh P K [mailto:[email-masked]]
>>>> Sent: Thursday, March 20, 2014 7:01 AM
>>>> To: Nobo Akiya (nobo); Bhatia, Manav (Manav); Marc Binderberger
>>>> Cc: [email-masked]
>>>> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)
>>>> 
>>>> 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
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo
>>>>> Akiya
>>>>> (nobo)
>>>>> Sent: Thursday, March 20, 2014 6:20 AM
>>>>> To: Bhatia, Manav (Manav); Marc Binderberger
>>>>> Cc: [email-masked]
>>>>> Subject: RE: Loop Prevention in S-BFD
>>>>> (draft-akiya-bfd-seamless-base)
>>>>> 
>>>>> 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/
>>>>> 
>>>>>> Please note that we will always know the S-BFD clients/reflectors
>>>>>> since they 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
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Bhatia, Manav (Manav)
>>>>>> [mailto:[email-masked]]
>>>>>> Sent: Wednesday, March 19, 2014 8:01 PM
>>>>>> To: Nobo Akiya (nobo); Marc Binderberger
>>>>>> Cc: [email-masked]
>>>>>> Subject: RE: Loop Prevention in S-BFD
>>>>>> (draft-akiya-bfd-seamless-base)
>>>>>> 
>>>>>> 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
>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo
>>>>>>> Akiya
>>>>>>> (nobo)
>>>>>>> Sent: Wednesday, March 19, 2014 9:22 PM
>>>>>>> To: Marc Binderberger; MALLIK MUDIGONDA (mmudigon)
>>>>>>> Cc: [email-masked]
>>>>>>> Subject: RE: Loop Prevention in S-BFD
>>>>>>> (draft-akiya-bfd-seamless-base)
>>>>>>> 
>>>>>>>> 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
>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: Marc Binderberger [mailto:[email-masked]]
>>>>>>>> Sent: Wednesday, March 19, 2014 11:25 AM
>>>>>>>> To: MALLIK MUDIGONDA (mmudigon)
>>>>>>>> Cc: Nobo Akiya (nobo); Vengada Prasad Govindan (venggovi); rtg-
>>>>>>>> [email-masked]
>>>>>>>> Subject: Re: Loop Prevention in S-BFD
>>>>>>>> (draft-akiya-bfd-seamless-base)
>>>>>>>> 
>>>>>>>> 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
>>>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 18 Apr 2014 14:39:53 +0000

Hi Sam,

> Would it be better to see some references to use cases from the base
> document? That way, it provides right context. Just a thought.

draft-akiya-bfd-seamless-base-03 now references draft-aldrin-bfd-seamless-use-case document in the introduction section. If WG thinks it's beneficial for the base draft to do more, ex: have a table describing how each use case is addressed, we could also do that. Let's see.

-Nobo

> From: Sam Aldrin [mailto:[email-masked]]
> Sent: Tuesday, April 08, 2014 2:27 PM
> To: Nobo Akiya (nobo)
> Cc: Marc Binderberger; Santosh P K; Bhatia, Manav (Manav); MALLIK
> MUDIGONDA (mmudigon); [email-masked]
> Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base)
> 
> Would it be better to see some references to use cases from the base
> document? That way, it provides right context. Just a thought.
> 
> Cheers
> Sam
> Sent from my iPhone
> 
> >> * 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.
> >
> >> * 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 ...
> >>  * 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).
> >>
> >>
> >>>>> and S-BFD, then session object located with your_discrim in
> >>>>> incoming packet will provide the bfd.SessionType.
> >>>>
> >>>>> and S-BFD, then session object located with your_discrim in
> >>>>> incoming packet will provide the bfd.SessionType.
> >>>>
> >>>>>> 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.
> >>>>>
> >>>>> 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
> >>>>>
> >>>>>> 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.
> >>>>>>
> >>>>>> 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.
> >>>>>>
> >>>>>> implement in hardware. Looking at the descriminator values and
> >>>>>> then detecting a loop cannot be easily done in HW.
> >>>>>>
> >>>>>>> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of
> >>>>>>> Nobo Akiya
> >>>>>>> (nobo)
> >>>>>>>> (formally) either. Anyway, I'll have a look again at the "M"
> >>>>>>>> bit and
> >>>>>>> the
> >>>>>>>> multipoint draft.
> >>>>>>>
> >>>>>>> bfd.SessionType is derivable for all cases. And D bit check can
> >>>>>>> be added for new bfd.SessionType values defined for S-BFD (both
> >>>>>>>> (formally) either. Anyway, I'll have a look again at the "M"
> >>>>>>>> bit and
> >>>>>>> the
> >>>>>>>> multipoint draft.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Huh?!  There is some misunderstanding here, so let me repeat
> >>>>>>>> the discriminator idea:
> >>>>>>>>
> >>>>>>>> the outgoing packet. This local discriminator is not a
> >>>>>>>> "reflector discriminator" of R2.
> >>>>>>>>
> >>>>>>>> The point is: when someone is injecting an "endless loop"
> >>>>>>>> packet by
> >>>>>>> using