Brian, Sriram, others,
I'd like to propose a different strategy and describe some background.
Both of you mention per-peer flags or new per-route state flags, which
in essence are updates to rfc4271, this feels like too heavy of a
hammer.
I'd prefer to make the document compatible with existing deployments of
software which is already compliant with the spirit of this document.
OLD:
Software MUST mark any routes from an EBGP peer as 'invalid' in the
Adj-RIB-In, if no import policy was configured.
NEW:
Software MUST consider any routes from an EBGP peer as invalid, if
no import policy was configured.
NEW2:
"Software MUST discard any routes from an EBGP peer, if no import
policy was configured."
We should leave it to the implementor of the software to decide what the
invalid consideration means in terms of exposure in the user interface.
Thoughts?
Kind regards,
Job
On Wed, Aug 24, 2016 at 02:51:51PM +0000, Sriram, Kotikalapudi (Fed) wrote:
> >For now, it may be necessary to add clarification/definitions to this
> >document
> >to make it clear to readers/implementers, what "invalid" means in this
> >context.
>
> In the case OV, the marking (in accordance with RFC 6811) needs to be per
> route
> (regardless of the peer it was received from).
>
> My suggestion for the case of policy/no-policy:
> There can be two overarching flags per peer that can be Red (set) or Green
> (not set):
>
> 1. No-ingress-policy flag: If Red (set) for a given peer, then all routes
> from that peer will be marked ‘no-policy-invalid’ in the Adj-RIB-in.
>
> 2. No-egress-policy flag: If Red (set) for a given peer,
> then no routes will be announced to that peer.
>
> Sriram
> -----------------------------------------------------------------------------------------------------------------
>
> From: Brian Dickson [mailto:[email protected]]
> Sent: Tuesday, August 23, 2016 8:33 PM
> To: Sriram, Kotikalapudi (Fed) <[email protected]>
> Cc: Greg Hankins <[email protected]>; [email protected]; Job Snijders
> <[email protected]>
> Subject: Re: [GROW] Working Group Adoption Call: draft-mauch-bgp-reject
>
> Sriram & Greg:
>
> I think the underlying issue is some terms used in *implementations*, which
> do not match exactly with the BGP protocol specifications (1771 and 4271).
>
> There are a few terms which get used interchangeably, unfortunately, which
> need some disambiguation (IMHO).
> Those terms are:
> - unfeasible
> - withdrawn
> - unresolvable
> - invalid
> - (excluded)
> and now includes
> - OV-invalid
> - (this document's marking of "no-policy-invalid")
>
> Whether the same "bit" in the internal representation should/could be
> used is pretty important; if different implementations conflate
> distinct situations, interoperability could be affected.
>
> I believe it is the case that at least the two big router vendors used
> the labels "invalid"/"valid" as a representation of "unresolvable",
> which has lead to this confusion.
>
> The RFCs actually use "invalid" to mean that some mandatory attribute
> is either missing or malformed, and should temporarily be marked that
> way, until withdrawal(s) happen, including from the RIB/FIB. (I think
> there are minimum 3 conditions that trigger that in the base spec,
> probably more in subsequent BGP attributes/families.) Invalid is
> actually an temporary thing, since the affected NRLI should be purged
> once other actions are completed.
>
> Unfeasible is aka withdrawn, and is also in effect a temporary thing;
> once processed, the unfeasible routes are gone from the in-RIBs and
> RIB.
>
> Unresolvable is a derived state, based on the NEXT_HOP not being
> resolvable.
> It doesn't go away automatically, unlike invalid and unlike unfeasible
> routes.
> It CAN change as a result of state changes on the route specified by
> the NEXT_HOP, independent of the NLRI itself.
>
> OV-invalid is similar to, but distinct from, unresolvable, and should
> NOT be implemented using the same "bit"/flag.
>
> However, I believe the "unresolvable" and the "no-policy-invalid"
> attributes are fine to represent with the same "bit", since neither
> should be able to pass Phase 2 of the path selection process.
>
> At some point down the road, a "bis" version of the base spec should
> be done, which makes minor revisions to clarify these terms, among
> other things. IMHO.
>
> For now, it may be necessary to add clarification/definitions to this
> document to make it clear to readers/implementers, what "invalid"
> means in this context.
>
> Brian
> _____________________
> _______________________________________________
> GROW mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
