Re: [Idr] IDR Charter discussion

On Tue, Jul 23, 2019 at 10:33:05AM -0400, Susan Hares wrote:
> 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.   

	I have partial XML for something doing this but think as it's a protcol extension it will end up in IDR vs GROW.  I'll try to finish getting the text done and send it to both lists.  If you want a private copy to help make sense of it - ping me off-list.

	think route-refresh type message that provides info on-demand.

	- jared

> 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. 
> 
> Sue 
> 
> 
> -----Original Message-----
> From: Neil J. McRae [mailto:neil@domino.org] 
> 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
> 
> 
> On Mon, Jun 10, 2019 at 03:51:03PM -0400, Susan Hares wrote:
> > The IDR Charter was last revised in March, 2010. 
> > 
> > It's time to reconsider what needs to go in the charter: 
> > 
> > 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"? 
> 
> Kind regards,
> 
> Job
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> 

-- 
Jared Mauch  | pgp key available via finger from jared@puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.