Joe pointed out confusion in following reply.(offline) I should state that one 
type is transport related encapsulation and another is non-transport related 
encapsulation. 

Lucy

-----Original Message-----
From: nvo3 [mailto:[email protected]] On Behalf Of Lucy yong
Sent: Wednesday, April 01, 2015 10:27 AM
To: Erik Nordmark; [email protected]
Subject: Re: [nvo3] Encapsulation considerations

Hi Eric,

A "service" might be too generic and cause ambiguous. It means an encapsulation 
for non-tunneling purpose. Thus, one type of encapsulation is for tunneling 
purpose, which is transport related; another is for non-tunneling purpose, 
which is non transport related.

The purpose of the draft is to provide guidelines for encapsulation design. 
IMO, it is good to point out two and make clear what issues that each type 
needs to consider in the draft. In fact, such thought is even important at 
architecture design level.

Regards,
Lucy

-----Original Message-----
From: Erik Nordmark [mailto:[email protected]] 
Sent: Tuesday, March 31, 2015 11:58 PM
To: Lucy yong; Erik Nordmark; [email protected]
Subject: Re: [nvo3] Encapsulation considerations

On 3/30/15 1:16 PM, Lucy yong wrote:
> Hi Eric,
>
> Here is my thought.
>
> Congestion considerations, Header Protection, Entropy, MTU and Fragmentation, 
> and QoS are specific for an encapsulation for tunneling.
>
> Next-protocol, OAM, extensibility, Security, layering, and middle-box are 
> applied to both types of encapsulations.
>
> Service model may only apply to the encapsulation for a service.

Lucy,

I'm not sure I have a crisp definition of a "service" vs. "tunneling".

But looking at your examples I think there are less differences than you claim.
For instance, if a "service" adds a header of some sort it needs to consider 
the MTU/frag implications of that header. And it needs to consider whether it 
needs to protect the header against bit errors (that are undetected by the link 
layer).

Furthermore, if the "service" can be applied to non-congestion controlled 
traffic, e.g., arbitrary Ethernet payload, then congestion needs to be 
considered.

So if we keep in mind that these are considerations and not requirements, then 
I don't think we need to try to find some way to separate them out. Upon 
considering something for e.g., SFC, it might turn out that no action is needed.

Thanks,
    Erik

>
> Regards,
> Lucy
>
>
>
>
>
>
> -----Original Message-----
> From: Erik Nordmark [mailto:[email protected]]
> Sent: Saturday, March 28, 2015 12:32 AM
> To: Lucy yong; [email protected]
> Subject: Re: [nvo3] Encapsulation considerations
>
> On 3/25/15 2:23 PM, Lucy yong 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.
>>
>> Considerations for two types of encapsulations have difference. It is good 
>> for the draft to point out that and give separate considerations.
> Lucy,
>
> which considerations in the draft are different for the two types you suggest?
>
> Thanks,
>      Erik
>
>> 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]
>> 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]
>> https://www.ietf.org/mailman/listinfo/nvo3
>>
>

_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3

_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3

Reply via email to