Re: [Idr] Document shepherd review for draft-ietf-idr-rfc7752bis

[Jeffrey Haas <[e-mail]>]

Ketan,

On Wed, Nov 10, 2021 at 06:21:46AM -0500, Jeffrey Haas wrote:
> Ketan,
> 
> On Wed, Nov 10, 2021 at 08:56:00AM +0000, Ketan Talaulikar (ketant) wrote:
> > > A critical detail is you've added "A BGP-LS Consumer would need the ability to merge..." and we're not asking routers carrying this information to do the work.
> > [KT] Yes, that is correct. This distinction and boundary between the "BGP protocol module" and "BGP-LS Consumer module" is precisely why we've introduced these terminologies and clarifications in Sec 3. IIRC (it been a few years now), this was one of the key inputs that I got from Alvaro for this bis.
> 
> I'll spend some time hopefully today to try to re-read sections 3 and 7.2.

I took some time to deeply contemplate those sections.  In particular:

Section 3:
:    The above roles are not mutually exclusive.  The same BGP Speaker may
:    be the producer for some link-state information and propagator for
:    some other link-state information while also providing this
:    information to a consumer application.  Nothing precludes a BGP
:    implementation performing some of the validation and processing on
:    behalf of the BGP-LS Consumer as long as it does not impact the
:    semantics of its role as BGP-LS Propagator as described in this
:    document.

Section 7.2.2:
:    A BGP-LS Propagator SHOULD NOT perform semantic validation of the
:    Link-State NLRI or the BGP-LS Attribute to determine if it is
:    malformed or invalid.

The circumstance we're effectively discussing is BGP Speakers that are
operating in the context of either a mixed Consumer/Propagator or at least
an implementation that "some of the validation" above.

The CBOR RFC provides a nice phrase that covers some of the classes of
errors we're discussing here for BGP-LS, and also for other current IDR
proposals: "Well-formed, but invalid".

BGP-LS puts us in competing philosophies for the link-state we're carrying
in BGP:
- In the IGP, well formed trash gets happily carried.
- In BGP, well formed trash has been responsible for routing outages.

As John Scudder has pointed out over the years, "SHOULD NOT" in some
circumstances can mean MAY.  So, we have the wiggle room for implementations
that wish to not propagate "well-formed, but invalid" if they choose not to
do so.

Given this wiggle room, would the following small change be acceptable?

"A BGP-LS Propagator, even when also operating as a BGP-LS Consumer, SHOULD
 NOT perform semantic validation of the Link-State NLRI or the BGP-LS
 Attribute to determine if it is malformed or invalid."

The motivation for this update is more signaling to an implementor of BGP-LS
that in cases where validation happens that propagation is expected.  If you
can't reduce the BGP-LS state to internal data structures, you had best be
prepared to carry it as opaque binary data.

It's my personal belief that multiple implementations will simply treat
well-formed but invalid as reason to use RFC 7606 treat-as-withdraw.  But
perhaps that will change with time.

-- Jeff