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

From: Jeffrey Haas <[email-masked]>
Date: Wed, 5 Jul 2017 14:02:12 -0400

Job,

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. 

(And yes, I realize that simply asking the question may be tantamount to
starting a flame war...)

[...]

> 
> 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.

-- Jeff

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 05 Jul 2017 19:44:23 +0100

> definition of that term is perceived to be. 

It means just what people choose it to mean - neither more nor less.

Words mean so many different things.

Nick

---

From: Job Snijders <[email-masked]>
Date: Wed, 5 Jul 2017 20:54:12 +0200

On Wed, Jul 05, 2017 at 02:02:12PM -0400, Jeffrey Haas wrote:
> > 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

---

From: Randy Bush <[email-masked]>
Date: Thu, 06 Jul 2017 10:34:17 +0200

life is simple.  you are tryingt o detect valley violations.  whether
you call it dogs and cats, coffee and tea, ... are merely fun ways of
trying to make simple things appear complex and are not constructive.

randy