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

[Christoph Loibl <[e-mail]>]

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] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at



> On 29.09.2020, at 17:24, Robert Raszuk <[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://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26#section-1>> introduces the Flow Specification NLRI.  In [RFC5575 <https://tools.ietf.org/html/rfc5575 <https://tools.ietf.org/html/rfc5575>>]
>>      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