Hi Carlos, Sorry for the late response due to business travel.
You ask to give the definition of tunneling encapsulation and non-tunneling encapsulation. I give a try here. Tunneling encapsulation: the encapsulation contains tunnel end point information as well as other information that assists tunnel transport purpose. The encapsulated payload is tunneled from tunnel ingress to egress. Non-tunneling encapsulation: the encapsulation contains the information that is used for the encapsulated payload operations. Such payload operations are independent of the architecture of a delivery network and how the payload is carried over the delivery network. Now question is, if we will have an encapsulation that does both? If yes, the corresponding architecture makes two layers dependent each other, which, in general, is a bad design. Regards, Lucy From: Carlos Pignataro (cpignata) [mailto:[email protected]] Sent: Saturday, April 11, 2015 12:46 PM To: Lucy yong Cc: Erik Nordmark; [email protected] Subject: Re: [nvo3] Encapsulation considerations Lucy, Please see inline. Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On Apr 10, 2015, at 18:22, Lucy yong <[email protected]<mailto:[email protected]>> wrote: Hi Carlos, -----Original Message----- From: Carlos Pignataro (cpignata) [mailto:[email protected]] Sent: Friday, April 10, 2015 2:51 PM To: Lucy yong Cc: Erik Nordmark; [email protected]<mailto:[email protected]> Subject: Re: [nvo3] Encapsulation considerations Lucy, > On Mar 25, 2015, at 5:23 PM, Lucy yong > <[email protected]<mailto:[email protected]>> wrote: > > Here is a suggestion to the draft. > > There are two distinct encapsulation purposes. > 1) an encapsulation for tunneling purpose, i.e. transport related > encapsulation, e.g. nvo3. > 2) an encapsulation for a service, i.e. transport independent encapsulation, > e.g. sfc. > I do not see this distinction. What you call tunneling vs. service is an artifact of where in the stack you are placing your reference point. If you go up to the overlay, the "service" becomes the "tunnel". Or looking at it from the bottom, the "tunnel" is a "service". [Lucy] Term "Service" makes confusion here. I think there's more confusion than that :-) But at the overlay, the "service" is not the "tunnel". Maybe this is better way to distinguish the two. 1) an encapsulation for tunneling purpose, i.e. transport related encapsulation, e.g. nvo3. I do not think this is a working definition. What is "tunneling purpose" and "transport related"? [see next comment] 2) an encapsulation for non-tunneling, i.e. transport independent encapsulation, e.g. sfc. >From an SF perspective, the SFP (SFC encap) is a Tunnel. And furthermore, the >SFC encap is used to transport at the SFC graph. And are you saying that a tunnel or the nvo3 encap are inherently "transport dependent"? I don't think that you can move the reference point to make nv03 encapsulation to non-tunneling encapsulation, and make sfc encapsulation into tunneling encapsulation. The architectures determine what they are. You still have not defined what is a "non-tunneling" vs. a "tunneling" encapsulation. Net net, a self-referencing definition is not helping, and neither is using examples instead of a definition. In any case, what's the point of this attempt at grouping? > > Considerations for two types of encapsulations have difference. It is good > for the draft to point out that and give separate considerations. > The considerations seem to apply to all encaps, instead of a grouping, a table might help (where for some encap, some consideration might be a noop). [Lucy] A table ends up with the pattern of two kinds. It does not. Unless you can show how, say, MTU and Entropy (assuming you consider those "transport" and "tunnel" attributes) are not relevant to, say, SFC encap (that you call service). Because what you call a "service" is a tunnel and transport for the actual service. And the "tunnel" is a service to IP. In summary you have not showed a definition or the table. Thanks, Carlos. Thanks, Lucy Thanks, - Carlos. > Thanks, > Lucy > > > -----Original Message----- > From: nvo3 [mailto:[email protected]] On Behalf Of Erik Nordmark > Sent: Wednesday, March 25, 2015 4:01 PM > To: [email protected]<mailto:[email protected]> > Subject: [nvo3] Encapsulation considerations > > > I presented part of this at the most recent NVO3 interim meeting.The full 12 > areas of considerations where presented at RTGWG earlier this week. > The draft is > http://datatracker.ietf.org/doc/draft-rtg-dt-encap/ > and the slides are at > http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-8.pdf > > There is probably additional things in there to consider for NVO3, and advice > that can be reused to make it easier to move NVO3 forward. > > Regards, > Erik > > > > _______________________________________________ > nvo3 mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
