[sidr] Interim Meeting (Apr 30, 2012) fallout/lessons/room-foo
Howdy, for the folks that attended in person, and remotely I think we (chairs) would like to get some feedback on how the meeting was done. I think we know of a few stumbling blocks: 1) late start/technology fail with the webex (probably webex operations failures more than anything - my fault) 2) audio issues (occasionally the webex audio would cut out) 3) local dial-in for webex-call for non-US participants 4) in-room audio failures with respect to typing noise 5) lack of slideware (though really, most of the discussion was based on agenda notes, and slideware wasn't going to be particularly helpful, or so the thought went) 6) microphone discipline for in-room vs external folks, often the in-room folk displayed (me too) an inability to wait their turn (jump into the conversation directly without queuing up, etc) (there are likely others, I'd like to get those from the remote/local folks as well) We tried in this meeting to use: o webex for shared-notes/slides o webex 'voip' audio for those that could make that work o webex PSTN dialin (us-toll-free, us-toll only) for those which could not use webex 'voip' o webex PSTN for in-room audio/bridge-to-webex o jabber for in-meeting communication, disambiguation of speakers, questions and hand-raising/remote-questions. I think the things that worked well were: o PSTN dial-in (especially the addition of local-to-callers numbers in non-US locations) o shared-application for note-taking o jabber for questions/hand-raising/etc I think for this experience webex came out poorly (for me frustrating at best). I'd like to see us either give the meetecho product a whirl (which I think the secretariat supports for us) or go a bit more less all encompassing: o etherpad/shared-doc/etc for notes o shared slides prior to the meeting (no slides, no slot. potentially) o jabber o pstn-bridge and force some better mic/floor discipline. I'd also (and sandy as well) would like some feedback on this message, the meeting, and suggestions for what a direction forward might be. (for sizing I believe we ended up with ~21 folks in-room and 'some number' maybe 10? remote) -Chris co-chair-2-of-3 ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] bgpsec-spec S. 4.2 comments
> The discussion here (and John's comment) is related to text in Section > 4.2, where we discuss what a BGPSEC router does when "propagating" a > route advertisement. "Propagating" connotes here that the update (or > route) was received from an eBGP peer. not exactly. 4.0 says Sections 4.1 and 4.2 cover two cases in which a BGPSEC speaker may generate an update message containing the BGPSEC_Path_Signatures attribute. The first case is that in which the BGPSEC speaker originates a new route advertisement (Section 4.1). That is, the BGPSEC speaker is constructing an update message in which the only AS to appear in the AS_PATH attribute is the speaker's own AS (normally appears once but may appear multiple times if AS prepending is applied). The second case is that in which the BGPSEC speaker receives a route advertisement from a peer and then decides to propagate the route advertisement to an external (eBGP) peer (Section 4.2). That is, the BGPSEC speaker has received a BGPSEC update message and is constructing a new update message for the same NLRI in which the AS_PATH attribute will contain AS number(s) other than the speaker's own AS. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] bgpsec-spec S. 4.2 comments
>that's also flawed. >You should be able to sign anything that you can. > >Suppose you receive it from an ibgp peer that sourced it but didn't sign it. > >-- >Jakob Heitz. > What a BGPSEC router does when "originating" a new BGPSEC update is covered in Section 4.1. You are right -- the router can receive a prefix route (without an AS path) from an ibgp peer who sourced it, and the method of signing that (or any prefix being originated) is in Section 4.1. The discussion here (and John's comment) is related to text in Section 4.2, where we discuss what a BGPSEC router does when "propagating" a route advertisement. "Propagating" connotes here that the update (or route) was received from an eBGP peer. Sriram ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] bgpsec-spec S. 4.2 comments
that's also flawed. You should be able to sign anything that you can. Suppose you receive it from an ibgp peer that sourced it but didn't sign it. -- Jakob Heitz. On May 2, 2012, at 7:21 AM, "Sriram, Kotikalapudi" wrote: > John Scudder asked the following question in an email to the > authors of draft-ietf-sidr-bgpsec-protocol: > >> From: John G. Scudder >> Date: Wed, Apr 18, 2012 at 8:00 PM >> Subject: bgpsec-spec S. 4.2 comments >> >> A few misc questions/comments I noticed while perusing S. 4.2: >> >> "A BGPSEC speaker MUST NOT generate an update message containing the >> BGPSEC_Path_Signatures attribute unless it has selected, as the best >> route to the given prefix, a route that it received in an update >> message containing the BGPSEC_Path_Signatures attribute." >> >> What's the rationale for this MUST NOT? Certainly it's an assumption of the >> base >> protocol, but I assume it wouldn't need to be called out here unless it bore >> on >> some BGPSEC-specific issue. This is relevant in the context of >> draft-ietf-idr-add- >> paths, which allows non-best paths to be sent in BGP. >> > > The authors have agreed that the above text in the bgpsec spec > document (quoted by John) certainly seems problematic. > The authors agreed to make the following text substitution: > (there was also consensus on this at the SIDR Interim meeting April 30, 2012): > > "If a BGPSEC router has received an _unsigned_ route from a peer and > if it chooses to propagate that route, then it MUST NOT attach any > BGPSEC_Path_Signatures attribute to the corresponding update being > propagated." > > It was also agreed that we further add (if not already clearly stated > elsewhere in the spec): > > "If a BGPSEC router has received a _signed_ update, > and if it chooses to propagate that route, then the router SHOULD propagate > the corresponding update with BGPSEC_Path_Signatures attribute > (after adding its own signature)." > > These substitutions would help keep the text unambiguous, and > also inclusive of (or at least not conflicting with) draft-ietf-idr-add-paths. > > Sriram > ___ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
[sidr] bgpsec-spec S. 4.2 comments
John Scudder asked the following question in an email to the authors of draft-ietf-sidr-bgpsec-protocol: >From: John G. Scudder >Date: Wed, Apr 18, 2012 at 8:00 PM >Subject: bgpsec-spec S. 4.2 comments > >A few misc questions/comments I noticed while perusing S. 4.2: > > "A BGPSEC speaker MUST NOT generate an update message containing the > BGPSEC_Path_Signatures attribute unless it has selected, as the best > route to the given prefix, a route that it received in an update > message containing the BGPSEC_Path_Signatures attribute." > >What's the rationale for this MUST NOT? Certainly it's an assumption of the >base >protocol, but I assume it wouldn't need to be called out here unless it bore on >some BGPSEC-specific issue. This is relevant in the context of >draft-ietf-idr-add- >paths, which allows non-best paths to be sent in BGP. > The authors have agreed that the above text in the bgpsec spec document (quoted by John) certainly seems problematic. The authors agreed to make the following text substitution: (there was also consensus on this at the SIDR Interim meeting April 30, 2012): "If a BGPSEC router has received an _unsigned_ route from a peer and if it chooses to propagate that route, then it MUST NOT attach any BGPSEC_Path_Signatures attribute to the corresponding update being propagated." It was also agreed that we further add (if not already clearly stated elsewhere in the spec): "If a BGPSEC router has received a _signed_ update, and if it chooses to propagate that route, then the router SHOULD propagate the corresponding update with BGPSEC_Path_Signatures attribute (after adding its own signature)." These substitutions would help keep the text unambiguous, and also inclusive of (or at least not conflicting with) draft-ietf-idr-add-paths. Sriram ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
