Hi all- I will not be able to make the call as I will be in the air. But a couple comments... First- Radak's diagram on chain and tree models is very good...Might we indicate where the User Agent initiates a request? We understand from our discussions that the service provider can play that role in the diagram, but it may not be as obvious to the casual reader... Second...Regarding asymetric framing for circuits... This requires a very clear definition of what the original [end to end] user request expects in terms of payload. To take Guy's example of a ethernet end point in GEANT and a handoff to I2 as a VCG... I suggest that the model for this is really a tunnel. The user request asked that the circuit use ethernet framing, this means that the actual user data to be moved from end to end will be presented in the payload section of the ethernet frame, presumeably at both ends. If those frames are GFP'd inside a VCG, then the VCG must have a start and end point where the GFP process encapsulates the data and unencapsulates it, or some other protocol adapts the user data in the core and then reframes it in ethernet frames at the end. If GEANT elects to provision and progress that service request over a VCG, then the VCG is actually a lower layer circuit across GEANT that starts where the ethernet is adapted into the VCG. And then that VCG is provisioned across the core and stitched to another lower layer circuit across I2, all of which may or may not carry the ethernet frame in the payload, but must at a minimum present the data at the user's specified end point nside a ethenrnet frame. If GFP is used at the ends of the VCG, then the ethernet framing is being tunneled whether or not the user actually cares about the ethernet frames or just tthe paylaod data itself. If, on the other hand, the Ethernet frame is opened up at the VCG ingress, and only the ethernet payload is carried in the VCG frames, then that is a different adaptation stage more akin to a stitching or concatenation of two circuits with unlike framing - and the data could conceivably be presented in different framing at the access port (on the end). I think this is a very important detail that we should be very clear on: What does the user actually want moved from source to destination...the ethernet frame itself? or the data inside the payload section of the ethernet frame? And this gets a bit more complex when you introduce VLAN taging at the ingress/egress. Once this is understood, then it will define where the start of a circuit exists (or maybe more appropriately - how to present the actual user data at the termination points.) The reason I dwell on this is that this detail seems to cause us a great deal of confusion as we try to define these use cases. We can provide any/all of these capabilites, but for the architecture to be robust and well defined, we need to clear on what is the actual user payload data to be moved end to end, and which parts of the transmission protocols are simply transport containers that the network can maniputlate to establish the end to end path. Hope this was clear:-) and not too geeky. Jerry John Vollbrecht wrote:

We will have a call tomorrow (Wed 6-24) at 9 ET. Call: +1-734-615-7474 (PSTN CALL-OUT DOES NOT WORK) or +1-866-411-0013 (toll free US/Canada Only) Enter access code: 0155180

We can discuss agenda at the beginning. Some suggestions

A. documents sent out yesterday 1) revised use cases tp send to NML group - I sent yesterday 2) Pathfinding examples from Radek 3) request sequence diagrams from Guy

B. Plans for document for next OGF

C. Other issues - Joan's ideas for expanding Tomohiro's diagrams 1) describe how NSA's interoperate - request sequences, trust relations, topology sharing, monitoring

other?

John

_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg

Dear John, all,

C. Other issues - Joan's ideas for expanding Tomohiro's diagrams 1) describe how NSA's interoperate - request sequences, trust relations, topology sharing, monitoring

Please find them attached. Note that these are only three cases. Further details needs to be done on the "effect on the NSI" slides. Best regards, -- Joan Antoni Garcia Espin CTX, Fundació i2CAT El dt 23 de 06 de 2009 a les 12:03 -0400, en/na John Vollbrecht va escriure:

We will have a call tomorrow (Wed 6-24) at 9 ET. Call: +1-734-615-7474 (PSTN CALL-OUT DOES NOT WORK) or +1-866-411-0013 (toll free US/Canada Only) Enter access code: 0155180

We can discuss agenda at the beginning. Some suggestions

A. documents sent out yesterday 1) revised use cases tp send to NML group - I sent yesterday 2) Pathfinding examples from Radek 3) request sequence diagrams from Guy

B. Plans for document for next OGF

C. Other issues - Joan's ideas for expanding Tomohiro's diagrams 1) describe how NSA's interoperate - request sequences, trust relations, topology sharing, monitoring

other?

John

_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg