Hi Carlos, Thank you for the response, please se inline.
From: Carlos Pignataro (cpignata) [mailto:[email protected]] Sent: Thursday, April 23, 2015 8:27 PM To: Lucy yong Cc: Erik Nordmark; [email protected] Subject: Re: [nvo3] Encapsulation considerations Hi Lucy, Thanks for the follow-up, please see inline. On Apr 22, 2015, at 11:26 AM, Lucy yong <[email protected]<mailto:[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? [Lucy] The tunnel is defined by a pair of end points. The tunnel carries datagrams between the pair of end points. For a tunnel over an IP network, the end points have an IP address. But entertaining that definition for a bit, a corollary: MPLS LSPs are not “Tunneling encapsulation” since they do not "contains tunnel end point information”. [Lucy] LSP stands for label switch path. IMO: It is not a tunnel technology. 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. [Lucy] This does like entertaining. ☺ There are debating on SFC list above if NSH draft should remain transport independent or not. You are in favor of the independent. 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... [Lucy] GRE by itself is non-tunneling. The applications using GRE such as PPTP, GRE-in-UDP, GRE-in-IP are tunnels. 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”. [Lucy] IMHO: L2TPv3 may be an example that does both. What is the reason that L2TPv3 is not widely deployed? 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”. [Lucy] IMO, it is important to be aware of the distinction from the architecture design. It makes clear the role for the encapsulator/decapsulator. BTW, where is the point to look at “above” and “below”? And the point behind the point is that attempting to make that distinction does not help solve the problem at hand anyway. [Lucy] Seems we have a disagreement here. That is OK, the world is like that. ☺ Thanks, Lucy 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]] 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]] 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
