[Nsi-wg] call tomorrow - 6/24

Jerry Sobieski jerry at nordu.net
Tue Jun 23 20:59:48 CDT 2009


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 at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
>
>   


More information about the nsi-wg mailing list