Agreed. Sounds good. Gyan On Sun, Apr 25, 2021 at 9:52 PM Jakob Heitz (jheitz) <[email protected]> wrote:
> If we do that, we should secure it with the router certificate > > https://tools.ietf.org/html/rfc8209 > > Then the URL should be secured with DNSSec, or why don't we just put the > > IP address in place of the hostname portion of the URL? > > > > Regards, > > Jakob. > > > > *From:* GROW <[email protected]> *On Behalf Of * Gyan Mishra > *Sent:* Sunday, April 25, 2021 6:37 PM > *To:* Rayhaan Jaufeerally (IETF) <[email protected]> > *Cc:* idr@ietf. org <[email protected]>; [email protected] > *Subject:* Re: [GROW] BGP Looking Glass Capability > > > > > > +1 on the new AFI idea. I would support developing the new draft. > > > > Out of al the ideas proposed I think the new AFI seems to be the best > method of achieving the BGP looking glass capability and propagation of > routes. > > > > Thanks > > > > Gyan > > > > On Sun, Apr 25, 2021 at 7:25 PM Rayhaan Jaufeerally (IETF) < > [email protected]> wrote: > > Thanks for the history Robert, I should have read the authors list more > closely on that draft :) > > > > From that description it seems that it was more circumstances at the time > rather than push back on the implementation itself which is good news for > trying to revive it, > > > > I'll try and rework the draft to use the operational message and see which > common parts are useful here, then reply to the list / IDR with the updated > draft, > > > > Cheers, > > Rayhaan > > > > On Mon, Apr 26, 2021 at 12:48 AM Robert Raszuk <[email protected]> wrote: > > Hi Rayhaan, > > > > I guess a good starting point would be to reach out to IDR folks / authors > of the operational message draft and get their input as to why it didn't > progress further since that would be useful to guide any revival attempts. > > > > Good idea. As I am co-author of this draft taking the liberty to do it > right here :) > > > > A bit of history - in min 2010 I wrote > https://tools.ietf.org/html/draft-raszuk-bgp-diagnostic-message-00. > > > > Then we spoke about it, trimmed a bit and formed what we considered most > important operationally into > https://tools.ietf.org/html/draft-ietf-idr-operational-message-00 > > > > The draft was having good support during the IDR WG adoption and hence it > became WG doc. > > > > Since then most of the authors left the vendor world and our influence to > implement it in significant commercial BGP code bases was no longer > sufficient. Yet vendors told we will implement it if customers ask for it. > So we are 9+ years and still I am not sure if anyone cares much about > switching phone and email channels between NOCs into more programmatic way. > > > > Yet we do see from time to time a pop request to some form to tell peer > ascii strings like sms by BGP, pass some well known address, etc ... > > > > I think this is the fundamental challenge in how we operate peering > relations. I have seen a lot of good automation happening in the IX world, > but when trying to establish BGP sessions today it seems still emails, xls, > word documents style ... > > > > While it does not need to be all TLVs as listed in the > https://tools.ietf.org/html/draft-ietf-idr-operational-message-00 draft > but I think operational message is indeed needed. > > > > Cheers, > R. > > > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow > > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email [email protected] <[email protected]>* > > *M 301 502-1347* > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
