Re: [Idr] [BULK] [BULK] Bug in draft-ietf-idr-rfc5575bis, worth fixing?

[John Scudder <[e-mail]>]

(Co-chair hat is on)

Yes, agreed. This is not subject to re-litigation now, we are trying to clarify things if needed, but not change decisions that were made.

Thanks,

—John

On Sep 29, 2020, at 11:34 AM, Christoph Loibl <[e-mail]<mailto:[e-mail]>> wrote:


Hi,

This has been a very very long discussion on the mailing-list, at meetings, … . And there was a very strong consensus for removing the opaque property (I was trying to keep it as it was but the WG decided to go that path). The good point: All implementations that I know of are implemented in a way that they do *not* treat FS NLRI as opaque key (at least they reset the session when they encounter a unknown FS component - something that is a good indication that they are not treating the NLRI as opaque key). Maybe for a good reason?

I do not think it makes any sense to change this back and forth every six month. -> go for FS2.0

Cheers Christoph

--
Christoph Loibl
[e-mail]<mailto:[e-mail]> | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at<https://urldefense.com/v3/__http://www.nextlayer.at__;!!NEt6yMaO-gk!WyyQ8EV6anHYW6a37jYyK1ivWQkr7vAVMIS41XLScR0HkQrPY7PwaV9mHCVxIA$>



On 29.09.2020, at 17:24, Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:

Hi John,

I admit I have missed that change or even if I noticed it apparently I did
not realize the magnitude and consequences this change brings.

IMHO it would be a fine change for FSv2 however I am quite sceptical for
rolling it into 5575bis.

Many thx,
R.


On Tue, Sep 29, 2020 at 5:20 PM John Scudder <[e-mail]<mailto:[e-mail]>> wrote:

Hi Robert,

You are right that RFC 5575 is very clear about that decision:

  We define a "Flow Specification" NLRI type that may include several
  components such as destination prefix, source prefix, protocol,
  ports, etc.  This NLRI is treated as an opaque bit string prefix by
  BGP.  Each bit string identifies a key to a database entry with which
  a set of attributes can be associated.


It’s also true that rfc5575bis retracts it. Appendix B makes it clear this
wasn’t an accident:

     Section 1 <https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26#section-1<https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26*section-1__;Iw!!NEt6yMaO-gk!WyyQ8EV6anHYW6a37jYyK1ivWQkr7vAVMIS41XLScR0HkQrPY7PwaV-WOlQhkQ$>> introduces the Flow Specification NLRI.  In [RFC5575 <https://tools.ietf.org/html/rfc5575<https://urldefense.com/v3/__https://tools.ietf.org/html/rfc5575__;!!NEt6yMaO-gk!WyyQ8EV6anHYW6a37jYyK1ivWQkr7vAVMIS41XLScR0HkQrPY7PwaV_U8CO1xA$>>]
     this NLRI was defined as an opaque-key in BGPs database.  This
     specification has removed all references to an opaque-key
     property.  BGP implementations are able to understand the NLRI
     encoding.


I haven’t gone back to check, but given that this was made so explicit in
the draft, I’m going to suppose that it was discussed in the WG before the
WGLC concluded, so I’m not very excited to re-litigate it.

I do think that it would be good to commence work on FSv2 soon, while we
still have this experience fresh in our minds.

—John