Hi Lucy, Thanks for the follow-up, please see inline.
> On Apr 22, 2015, at 11:26 AM, Lucy yong <[email protected]> wrote: > > 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. > Defining “Tunneling encapsulation” as something that "contains tunnel end point information” seems to be of marginal value. What is a tunnel? But entertaining that definition for a bit, a corollary: MPLS LSPs are not “Tunneling encapsulation” since they do not "contains tunnel end point information”. Further, encapsulations like SFC could be “Tunneling encapsulations” (although before you classify that as Service), because it “Transports an encapsulated payload, tunneling it, from tunnel ingress to egress.” Basically, SFC tunnels a payload from SF ingress to SF egress, passing through a number of SFF hops. > 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. > GRE includes a protocol identifier field, which is used for the encapsulated payload identification. Maybe GRE is non-tunneling... L2TPv3 contains an Adaptation Layer, the L2-Specific Sublayer, which includes for “information that is used for the encapsulated payload operations”. E.g., with payload header bits in RFC 4454 and RFC 4591. It also includes fragmentation info, RFC 4623. Based on this, L2TPv3 is a non-tunneling “L2 tunneling protocol version 3”. The point is there is no such distinction as you are trying to make — it is all depending on whether you look from “above” or from “below”. And the point behind the point is that attempting to make that distinction does not help solve the problem at hand anyway. > 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. > This is a non-sequitur. Thanks, — Carlos. > Regards, > Lucy > > > > > From: Carlos Pignataro (cpignata) [mailto:[email protected] > <mailto:[email protected]>] > Sent: Saturday, April 11, 2015 12:46 PM > To: Lucy yong > Cc: Erik Nordmark; [email protected] <mailto:[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] > <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] <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/ > > <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 > > <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 > > <https://www.ietf.org/mailman/listinfo/nvo3> > > > > _______________________________________________ > > nvo3 mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/nvo3 > > <https://www.ietf.org/mailman/listinfo/nvo3>
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
