Re: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017).

[Job Snijders <[e-mail]>]

On Wed, Jul 05, 2017 at 02:02:12PM -0400, Jeffrey Haas wrote:
> On Sun, Jun 04, 2017 at 11:59:47AM +0000, Job Snijders wrote:
> > Unfortunately, as it's currently specified, I still cannot see my
> > affiliation deploying this technology in a meaningful way.
> > 
> > The word "peer" is extremely overloaded: it is a homonym which
> > conflates all kinds of concepts. The term appears in too many
> > training courses to be redefined to one specific meaning. On top of
> > that, I all too often see that provisioning- or customer engineers
> > don't have clear insight as to who is customer and who the supplier
> > is. Even worse: a customer may assume the supplier role as part of a
> > larger deal. While in the hallways we easily talk about simplified
> > models on how the internet works, actually enforcing that
> > simplification in the context of EBGP to me is undesirable.
> 
> I have some opinions here that probably overlap your own.  While I
> haven't paid good attention to operator forums like NANOG for a while,
> I remember that definitions of 'peer' tended to make for a heated
> topic.  I also don't remember any particular convergence on a formal
> definition that would hold up in a BGP AS-graph sort of way.
> 
> It might be helpful if you or other operators rally for what the
> current definition of that term is perceived to be. 

I don't think that is possible.

> > Perhaps if the draft would focus on merely two classifications:
> > "stub" and "transit" networks, where the former would be an
> > affirmation that neither party expects the "stub" network to transit
> > prefixes for any other ASN, and transit networks would enjoy the
> > same behavior as any ASN today, that would give a different twist to
> > this idea. Downside is that one needs to bounce the session to
> > become a transit provider.
> 
> The real issue here is the simple matter of AS-graph definition.  A
> stub network is always clear.  Traditional papers for valley free
> routing tend to focus on the remaining up/down/lateral relationships.
> I believe these are the properties we're looking for, and that
> stub/transit is probably not a sufficient relationship.

Shouldn't the draft perhaps focus on what _is_ clear?

Kind regards,

Job