Subject: S-BFD port allocation

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 12 Dec 2014 18:09:26 +0000

BFD WG,

Here's an update of the allocation of S-BFD ports, and we need your input & consensus to decide how to proceed forward.

>> s-bfd (request #7784)
>> s-bfd-echo (request #7785)

Comments from expert review is that the BFD WG should not continue to allocate new ports for every BFD feature. It looks like this point was brought up when we progressed BFD on LAG back in 2012. However, this may not be easily achievable by BFD unless the BFD header had some sort of a Type field. Given where we are with the BFD, and the S-BFD progress, experts have offered a compromising solution for the S-BFD port allocation.

1. Continue with s-bfd (request #7784) port allocation.
2. Cancel s-bfd-echo (request #7785) and let standards/implementations figure out a way to reuse port 3785.
3. For any further port allocations for BFD features, consider feature demux logic within the BFD layer. This may require us to define v2 BFD.

Please chime in and provide comments, especially if you have objections to this direction.

Thanks!

-Nobo & Jeff

---

From: Santosh P K <[email-masked]>
Date: Mon, 15 Dec 2014 13:25:44 +0000

Nobo,

> figure out a way to reuse port 3785.

If we are not using separate port number then we might need to dig in to payload of BFD. Not all hardware can do this right? Will this become a bottleneck for S-BFD which are hardware based? I am assuming that few hardware implementation might not do any parsing of S-BFD packets but will simply do a blind compare of received packet with template from software? To do this it might want to check if this is S-BFD echo or legacy BFD echo so that it can take right path. 

> 3. For any further port allocations for BFD features, consider feature demux
> logic within the BFD layer. This may require us to define v2 BFD.

I agree :). 

Thanks
Santosh P K 

> 3. For any further port allocations for BFD features, consider feature demux
> logic within the BFD layer. This may require us to define v2 BFD.
>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 15 Dec 2014 23:01:57 +0000

Hi Santosh, et al,

Thanks for providing your opinion. I also received a private comment from another person saying "let's push for S-BFD echo port allocation".

Let me, however, play devil's advocate on (2), as I don't think we have enough good arguments against the port allocation push back for S-BFD echo.

> If we are not using separate port number then we might need to dig in to
> payload of BFD. Not all hardware can do this right? Will this become a
> bottleneck for S-BFD which are hardware based? I am assuming that few
> hardware implementation might not do any parsing of S-BFD packets but
> will simply do a blind compare of received packet with template from
> software? To do this it might want to check if this is S-BFD echo or legacy
> BFD echo so that it can take right path.

1) I do agree that BFD feature demux is easier off of lower layer information (i.e., dest port).
2) New lower layer information to demux new BFD feature will allow clean introduction of new BFD features.

However, if we were to go down the path of demux logic within the BFD layer in the future, what you described above as "difficult" is exactly what implementations will have to do. So, doing this with BFD/S-BFD echo on 3785 is a good starting point.

What do you think?

Thanks!

-Nobo

> 
> 
> > 3. For any further port allocations for BFD features, consider feature
> > demux logic within the BFD layer. This may require us to define v2 BFD.
> 
> I agree :).
> 
> 
> Thanks
> Santosh P K
> 
> 
> > 3. For any further port allocations for BFD features, consider feature
> > demux logic within the BFD layer. This may require us to define v2 BFD.
> >

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Wed, 17 Dec 2014 05:44:45 +0000

Hello Nobo,
  I agree with your thoughts on absorbing the complexity of de-multiplexing S-BFD v/s classical BFD based on the contents of the echo packet and not rely on the destination port. However, the destination port for S-BFD Async packets will have to be different to help current implementation efforts. Without it, it becomes difficult for implementations to go back to the drawing board at this stage. A related question in this context would be: Would the (future) de-mupltiplex  header affect current S-BFD Async or echo packet formats ?  
Thanks
Prasad

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Tuesday, December 16, 2014 4:32 AM
To: Santosh P K; [email-masked]
Subject: RE: S-BFD port allocation

Hi Santosh, et al,

> > 2. Cancel s-bfd-echo (request #7785) and let 
> > standards/implementations figure out a way to reuse port 3785.
> 
> If we are not using separate port number then we might need to dig in 
> to payload of BFD. Not all hardware can do this right? Will this 
> become a bottleneck for S-BFD which are hardware based? I am assuming 
> that few hardware implementation might not do any parsing of S-BFD 
> packets but will simply do a blind compare of received packet with 
> template from software? To do this it might want to check if this is 
> S-BFD echo or legacy BFD echo so that it can take right path.

What do you think?

Thanks!

-Nobo

> 
> 
> > 3. For any further port allocations for BFD features, consider 
> > feature demux logic within the BFD layer. This may require us to define v2 BFD.
> 
> I agree :).
> 
> 
> Thanks
> Santosh P K
> 
> 
> > 3. For any further port allocations for BFD features, consider 
> > feature demux logic within the BFD layer. This may require us to define v2 BFD.
> >

---

From: "MALLIK MUDIGONDA (mmudigon)" <[email-masked]>
Date: Wed, 17 Dec 2014 05:57:24 +0000

Hi Nobo et al,

Please find my responses inline

Regards
Mallik

From: "Nobo Akiya (nobo)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 16 December 2014 4:31 am
To: Santosh P K <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: S-BFD port allocation

Hi Santosh, et al,

Mallik>> I agree with this suggestion. When classic BFD can have two ports for Async and Echo, why is this an issue for SBFD?

Mallik>> Yes. There are implementations today which does it based on Destination port.

Mallik>> It is easier to demux classic echo verses SBFD echo if we use 3785 because we have the “D” bit that is set by the initiator. But then implementation will have to look deeper inside BFD/SBFD packets which may be one of the reasons for asking for a separate port.

What do you think?

Mallik>> If we plan to implement additional headers in BFD packets for demux purpose then it is time we start discussing the same.

Thanks!

-Nobo

I agree :).
Thanks
Santosh P K

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 17 Dec 2014 14:08:55 +0000

Hi Prasad,

>   I agree with your thoughts on absorbing the complexity of de-multiplexing
> S-BFD v/s classical BFD based on the contents of the echo packet and not
> rely on the destination port.

It is good to know that one vendor thinks S-BFD echo reusing 3785 is a possibility.

> However, the destination port for S-BFD Async
> packets will have to be different to help current implementation efforts.
> Without it, it becomes difficult for implementations to go back to the
> drawing board at this stage.

I agree. We definitely need a new port for S-BFD async.

> A related question in this context would be:
> Would the (future) de-mupltiplex  header affect current S-BFD Async or
> echo packet formats ?

I would guess that BFD layer demux will require an additional field to do so, and we all know that BFD v1 has difficulty finding a space for any additional fields. This is up for discussion, and it is up to the "new approach" to ensure that changes are backwards compatible.

Thanks!

-Nobo

> From: Vengada Prasad Govindan (venggovi)
> Sent: Wednesday, December 17, 2014 12:45 AM
> To: Nobo Akiya (nobo); Santosh P K; [email-masked]
>   I agree with your thoughts on absorbing the complexity of de-multiplexing
> S-BFD v/s classical BFD based on the contents of the echo packet and not
> rely on the destination port. However, the destination port for S-BFD Async
> packets will have to be different to help current implementation efforts.
> Without it, it becomes difficult for implementations to go back to the
> drawing board at this stage. A related question in this context would be:
> Would the (future) de-mupltiplex  header affect current S-BFD Async or
> echo packet formats ?
> Thanks
> Prasad
> 
> Thanks for providing your opinion. I also received a private comment from
> another person saying "let's push for S-BFD echo port allocation".
> 
> Let me, however, play devil's advocate on (2), as I don't think we have
> enough good arguments against the port allocation push back for S-BFD
> echo.
> 
> However, if we were to go down the path of demux logic within the BFD
> layer in the future, what you described above as "difficult" is exactly what
> implementations will have to do. So, doing this with BFD/S-BFD echo on
> 3785 is a good starting point.
> 
> What do you think?
> 
> Thanks!
> 
> -Nobo
> 
> >
> >

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 17 Dec 2014 14:16:42 +0000

Hi Mallik,

Please see in-line with [NOBO].

From: MALLIK MUDIGONDA (mmudigon)
Sent: Wednesday, December 17, 2014 12:57 AM
To: Nobo Akiya (nobo); Santosh P K; [email-masked]
Subject: Re: S-BFD port allocation

Hi Nobo et al,

Regards
Mallik

Hi Santosh, et al,

[NOBO] IANA believe that the BFD protocol is abusing the port space. They are strongly suggesting that feature demux be done on the feature layer. And it appears that this isn't the first time this topic was brought up. Thu the pushback from IANA.

[NOBO] And we will need to revisit this, if we are to do feature demux in the BFD layer.

Mallik>> It is easier to demux classic echo verses SBFD echo if we use 3785 because we have the "D" bit that is set by the initiator. But then implementation will have to look deeper inside BFD/SBFD packets which may be one of the reasons for asking for a separate port.

[NOBO] I don't disagree. It is easier to be able to demux in the lower layer, and I wish this model can be preserved going forward. However, we (BFD WG) have been flagged by the "police", and we need to look into how this can be addressed in the BFD layer, going forward.

[NOBO] Good thing is that IANA is willing to allow the port for S-BFD async. And considering echo packet contents is something implementations can define (i.e. having version, type, etc), we _should be_ able to reuse 3785 for S-BFD echo. Do you think this is true?

What do you think?

[NOBO] This can start up now, or this has to start up when there is another BFD feature requiring a new port.

Thanks!

-Nobo

Thanks!

-Nobo

I agree :).
Thanks
Santosh P K

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 17 Dec 2014 17:08:38 -0500

> [NOBO] This can start up now, or this has to start up when there is another BFD feature requiring a new port.

I think we have enough breathing room for S-BFD to proceed with a single
port for async and letting the remote demux on echo contents with existing
BFD echo port from 5880.  At least that's how I read the above.

I've added the BFDv2 item to my internal TODO list as I mentioned to Nobo.
There's already been some thoughts on what we might want out of such a thing
in terms of "well known payloads", but I think additional demux is probably
the killer app for it.

The modeling exercise I'll be recommending when the conversation starts
moving is how we would rewrite our existing features to all fit into BFDv2
with a single port assigned.

-- Jeff

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 18 Dec 2014 13:54:26 +0000

[snipping in only the s-bfd port discussion portion ... to attempt to close this off]

> > [NOBO] Good thing is that IANA is willing to allow the port for S-BFD async.
> And considering echo packet contents is something implementations can
> define (i.e. having version, type, etc), we _should be_ able to reuse 3785 for
> S-BFD echo. Do you think this is true?
> >
> > What do you think?
> >
> > Mallik>> If we plan to implement additional headers in BFD packets for
> demux purpose then it is time we start discussing the same.
> >

Since there hasn't been any major objection to going with one port for S-BFD, I'm starting to conclude that this is something which we can live with. If anyone object, do chime in within few days and provide your reasons. Otherwise, we'll provide "let's go ahead with one S-BFD port" to IANA.

Thanks!

-Nobo

---

From: Marc Binderberger <[email-masked]>
Date: Sat, 20 Dec 2014 19:42:58 -0800

Hello Nobo et al.,

> Since there hasn't been any major objection to going with one port for 
> S-BFD, I'm starting to conclude that this is something which we can live 
> with. If anyone object, do chime in within few days and provide your 
> reasons. Otherwise, we'll provide "let's go ahead with one S-BFD port" to 
> IANA.

which proves the pushback from IANA was actually a good thing. "do you really 
need this?" is a reasonable question. Overall the mechanisms seem to work.

In another email you said:

[NOBO] IANA believe that the BFD protocol is abusing the port space. They are 
strongly suggesting that feature demux be done on the feature layer. And it 
appears that this isn’t the first time this topic was brought up. Thu the 
pushback from IANA.

Actually I do not remember that this was a real problem in the past - I think 
it is just normal business that you have to explain why you need to take a 
port.
Or maybe it's another (set of) person this time but again, they see the point 
for S-BFD and are willing to provide a port, so it's not the end of the world.

Not that you will see me argue against "v2" ;-) but it doesn't seem to be 
necessary for S-BFD.

For the echo, as asked in another email: what is different for S-BFD echo?  
Is there any special/different behaviour expected on the remote side, 
compared to 3785/udp echo ?

Regards, Marc

On Thu, 18 Dec 2014 13:54:26 +0000, Nobo Akiya (nobo) wrote:
>>> [NOBO] This can start up now, or this has to start up when there is 
>>> another
>> BFD feature requiring a new port.
>> 
> Since there hasn't been any major objection to going with one port for 
> S-BFD, I'm starting to conclude that this is something which we can live 
> with. If anyone object, do chime in within few days and provide your 
> reasons. Otherwise, we'll provide "let's go ahead with one S-BFD port" to 
> IANA.
> 
> Thanks!
> 
> -Nobo
> 
>

---

From: Alia Atlas <[email-masked]>
Date: Sun, 21 Dec 2014 01:17:23 -0500

> appears that this isn’t the first time this topic was brought up. Thu the

Just to clarify - this is not IANA.  This is the designated expert, whom is
assigned
by the IESG.  IANA, of course, doesn't do policy related to the protocol
parameters.

I am very glad to see the conversation resolving well.

Regards,
Alia

> > [snipping in only the s-bfd port discussion portion ... to attempt to
> close
> > this off]
> >
> >> define (i.e. having version, type, etc), we _should be_ able to reuse
> 3785
> >> for

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sun, 21 Dec 2014 15:27:49 +0000

Hi Alia,

Ah yes, thanks for clarifying that the comments are from designated experts and not IANA.

Hi Marc,

Many thanks for providing comments.

> compared to 3785/udp echo ?

The contents of the echo can be easily updated to be able to demux between BFD/S-BFD. But the concerns were:
- Can SW/HW implementations easily demux the BFD/S-BFD echo on the BFD layer?
- Are there any implementations that has special code path for port 3785 that can result in a conflict by S-BFD echo also using that port?

[chair hat on]

WG,

Based on the comments on this thread (and lack of opposing comments), I have concluded that we can move forward with the followings for S-BFD port allocations.
- Move forward with S-BFD control port allocation (7784)
- Cancel S-BFD echo port allocation (7785)

Additionally, do continue to think and discuss the aspect of BFD feature demux on the BFD layer, because this will be a topic that we will have to resolve if/when the BFD WG need to request another port.

[chair hat off]

Thanks!

-Nobo

> From: Alia Atlas [mailto:[email-masked]]
> Sent: Sunday, December 21, 2014 1:17 AM
> To: Marc Binderberger
> Cc: Nobo Akiya (nobo); [email-masked]