Have to agree on the need to support both. I have been honestly a little baffled by all the "push vs pull" discussion.
In a past life of developing monitoring tools for datacenters/networks we quickly saw that that one model never met all needs. Too many odd scenarios (one being how do you ask someone if they are dead yet) So a hybrid where remote nodes would push but a pull could be done whenever needed or something along those lines would always win out. While I understand the need to lock down certain design ideas, I'm not sure push vs pull needs to be as Boolean as we have made it. And to Thomas's point some implementations may choose to go heavy one way or another as a competitive advantage toward their in house skills. We need to give that room. On Jul 24, 2013, at 9:37 PM, Linda Dunbar <[email protected]> wrote: > Thomas, > > Even though TRILL has detailed directory mechanism document, TRILL's > Directory Framework document includes the following basic requirement for > Push/Pull: > > Push: When the incoming data frame's DA is not found in entries being pushed > down, policies need to be configured on the edge: > > - simply drop the data packet, > > - flood it to the core, or > > - start the pull process to get information from pull directory > server(s) (i.e. NVA in NVO3's terminology) > > > Pull: > - need to specify if the pulled entries can be cached, or timer for the cache > - need policy to specify if the data frame can be flooded across core if > no-reply is received > - Directory (NVA) needs to notify all edges (NVEs) when the pulled entries > become stale. > > > Hope the NVO3 architecture document can also include those necessary > requirement for Push and Pull. > > Linda > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Thomas Narten >> Sent: Wednesday, July 24, 2013 11:57 AM >> To: Lizhong Jin >> Cc: [email protected] >> Subject: [nvo3] Arch: push vs. pull >> >>> 3. If push and pull are supported, then how to combine the pull and >> push >>> mode should be described, which is closely related with NVE-NVA >>> protocol. >> >> I agree, more detail is needed here. But that said, I expect that >> there will be some implementations that want to go heavy on the "push" >> side while others might be heavier on the "pull" side. I don't see it >> as a requirement of the architecture to define exactly where in >> spectrum between pull (only) and push (only) an optimal spot >> is. Rather, I think the architecture should support a range of >> behaviors, so that an NVE would work equally with an NVA that is "push >> heavy" as with one that is "pull heavy". >> >> So in that sense, I don't see the architecture document as being the >> place that "chooses" or "recommends" a "best choice", or makes a lot >> of arguments about the pros an cons of each choice. >> >> Thomas >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
