From: "Susan Hares" <shares@ndzh.com>
To: "'Neil J. McRae'" <neil@domino.org>, "'Job Snijders'" <job@ntt.net>,
 <jared@puck.nether.net>
Cc: <idr@ietf.org>
References: <022b01d51fc5$d6576dd0$83064970$@ndzh.com>
 <20190722151151.GS33367@vurt.meerval.net>
 <04D143A8-FCFF-4FCD-A6FE-7446B1E86617@domino.org>
In-Reply-To: <04D143A8-FCFF-4FCD-A6FE-7446B1E86617@domino.org>
Date: Tue, 23 Jul 2019 10:33:05 -0400
Message-ID: <007201d54163$8b404370$a1c0ca50$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQIdg7HoWEJ9E9Q2QbmV0ImeCpD95AGXQrsVAVHrUzGmMHLnsA==
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/k5pvAGfg3_M2CaOwfOplfuG3mhk>
Subject: Re: [Idr] IDR Charter discussion
Precedence: list

Neil:

On 1 + 2:  NM/OPS groups such as GROW have more expertise to decide =
requirements regarding E-BGP maximum prefixes and appropriate actions. =
IDR will be glad to review proposed requirements, appropriate action and =
any proposals on BGP changes.  =20

On 3, proposals on sending key contact info over BGP have been proposed =
for 15 years.   People in operations have stated: "Please do not put =
this information in".  Other operations have stated - "Please put =
contact info" so I can survive outages without looking up phone numbers. =
Unless there are clear operational requirements,  IDR working on =
protocol changes will end up in the same debates.   So we will look to =
NM/OPS WGs to provide better requirements.=20

Sue=20


-----Original Message-----
From: Neil J. McRae [mailto:neil@domino.org]=20
Sent: Tuesday, July 23, 2019 8:37 AM
To: Job Snijders; Susan Hares; jared@puck.nether.net
Cc: idr@ietf.org
Subject: Re: [Idr] IDR Charter discussion

I think 1+2 have some merit but 3 is not managing routing at a human =
level and shouldn't be here. IMO

=EF=BB=BF
On Mon, Jun 10, 2019 at 03:51:03PM -0400, Susan Hares wrote:
> The IDR Charter was last revised in March, 2010.=20
>=20
> It's time to reconsider what needs to go in the charter:=20
>=20
> Somethings we might include are:

It may be good to consider some operations and management functions to =
be specced out in IDR.

>From the operational side of the house I recall a few long-standing
wishes:

    - ability to see which prefixes are accepted/rejected by the
      EBGP neighbor
    - ability to see the maximum prefix limits configured by the
      EBGP neighbor
    - ability to relay some contact / circuit details over an EBGP
      session to facilitate inter-organization coordination

All of the above can be accomplished in non-realtime through out-of-band =
mechanisms like e-mail and phone; but this type of out-of-band channels =
often are error-prone.

I think we would benefit from actively shifting some of this OAM from =
out-of-band into the BGP protocol itself so less coordination is needed =
between autonomous system operators.

I am not sure how to exactly word a high level milestone suitable for =
the charter. "Add more OAM"? "Add more operational debugging =
capabilities"?=20

Kind regards,

Job

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr