Re: [Rtg-dt-encap-considerations] draft-rtg-dt-encap-02 for review

[Erik Nordmark <[e-mail]>]

I moved the unique text from section 15.1 to section 8 and dropped 
section 15.1.

I also added this proposed text in section 8 - does it look reasonable?
"It is worth mentioning that in the MPLS case of no implicit protocol 
type many forwarding devices peek at the first nibble of the payload to 
determine whether to apply IPv4 or IPv6 L3/L4 hashes for load balancing 
<xref target="RFC7325"/>. That behavior places some constraints on other 
payloads carried over MPLS and some protocol define an initial control 
word in the payload <xref target="RFC4385"/> to avoid confusion with 
IPv4 and IPv6 payload headers."

Two open issues remain right now.
Tom suggested:
 > Would change "Avoid full packet checksums in encapsulation if
 > possible" to "Avoid full packet checksums in cases where necessary
 > devices cannot support them"
I expressed some concern about that below.

Also, Tom's first issue below about why to use UDP would need some 
proposed text if we want to include it.

We can talk about those on the call tomorrow so we can wrap up -02.

Latest -02 attached.

    Erik

On 5/20/15 9:15 AM, Erik Nordmark wrote:
> On 5/19/15 2:45 PM, Tom Herbert wrote:
>> Some comments on version 02:
>>
>> On the IPv6 flow label: Brian Carpenter made pretty much the same
>> point that IPv6 flow label could be used in lieu of UDP encapsulation
>> for entropy. This was in the context of IP-over-UDP. The argument was
>> short circuited a bit because IP-over-UDP lacked extensibility and we
>> already have N other protocols that can do the same thing but are
>> extensible. It might be worthwhile to point out that a major reason
>> for encapsulating over UDP is that it allows arbitrary and extensible
>> encapsulations, entropy for ECMP is essentially nice side effect.
> Do you have some suggested text to add? I can't easily tell where we 
> would add such text since we don't have a "why use UDP" section; the 
> entropy section talks just about entropy.
>
>>
>> Security:
>>
>> In relationship to encapsulating in UDP it seems like DTLS will be
>> preferred over IPsec (e.g. GRE/UDP)  in this context as being a better
>> fit. In this simplest form this seems to means that UDP encap
>> protocols will be asking for two port assignments.
>>
>> "Interaction with packet security such as IPsec" -> "Interaction with
>> packet security such as IPsec or DTLS"
> OK
>
>>
>> I would rewrite 2nd paragraph is section 11.3 as:
>>
>> "The more interesting case is when security is applied to the
>> encapsulation payload. This will keep the encapsulation headers in the
>> outer header visible to the network (for instance in nvo3 we may way
>> to firewall based on VNI ID even if the payload is encrypted). On
>> possibility is to apply DTLS to the encapsulation payload. In this
>> model the protocol stack may be something like
>> IP|UDP|Encap|DTLS|encrypted_payload. The encapsulation and security
>> should be done together at an encapsulator and resolved at the
>> decapsulator. Since the encapsulation header is outside of the
>> security coverage, this may itself require security (like described
>> above)."
> OK
>>
>> In last paragraph of section 11.3 please scratch whole sentence "In
>> this case of security..."
> OK
>>
>> Section 13:
>>
>> Unnecessary colloquialism? "encaps"->"encapsulation method"
> OK - I took care of the other occurances of encaps and decaps as well.
>>
>> I think section 15.1 can be removed
> I wanted to check if it is all covered earlier in the document. I see 
> that e.g. ietf-tsvwg-port-use isn't referenced earlier.
> I'll see if I have some time to do this later - we can always fix it 
> once it is a WG document as well.
>>
>> Section 18:
>>
>> Would change "Avoid full packet checksums in encapsulation if
>> possible" to "Avoid full packet checksums in cases where necessary
>> devices cannot support them"
> I don't know what others think, but that seems to be confusing. It 
> seems to imply that some devices are sub-standard and can be fixed, 
> when in fact it is impossible to do a full packet checksum, where the 
> checksum is placed in the header, in a low-latency cut-through device.
>
> From an IETF standardization perspective it is quite hard to predict 
> how the protocols we define will be deployed. It might be that they 
> will be only deployed in hosts (with full packet buffering NICs), or 
> it might be that they will continue to be deployed in a mixture of 
> such hosts and routers/switches.
>
> We could point out that a full packet trailer checksum/CRC wouldn't 
> have the same concerns ...
>>
>> "if" -> "If" in same paragraph
> OK
>
>>
>> Section 22 Open issues, next protocol header. Joe Touch has been
>> arguing that IPv4 and IPv6 should not use separate protocol numbers by
>> the same one as IP encapsulation and differentiate by IP version
>> number. Don't know if we want to bring this up, but someone eventually
>> will. :-)
> Just because you decided to wake the sleeping bear doesn't mean I 
> intend to do the same thing.
> Joe is welcome to stand up and say that IPv6 over Ethernet should be 
> changed to use 0x800 ;-)
>
> Thanks,
>    Erik
>
>>
>> Tom
>>
>>
>> On Thu, May 14, 2015 at 11:00 AM, Erik Nordmark <[e-mail]> 
>> wrote:
>>> Attached is -02 of the document.
>>>
>>> Albert said he would check whether there are some additional text we 
>>> want to
>>> add about the control word, but I've completed the other edits we have
>>> discussed.
>>>
>>> https://docs.google.com/document/d/1OvGxiNTPuncHl1N-6JH-6MJvZ3D9PK1LpjwsRgArgJ8/ 
>>>
>>> is up to date with the issues, but doesn't have the exact same 
>>> proposed text
>>> changes as the I-D.
>>>
>>> I edited the attached diffs to remove the diffs related to the 
>>> change in
>>> pagination.
>>>
>>> Please review the changes, and check whether there are additional 
>>> things we
>>> should lift out to the "In summary" bulleted lists.
>>>
>>> It would be good to submit this next week - if anything 
>>> controversial shows
>>> up we can discuss it on the call next Thursday.
>>>
>>> Regards,
>>>     Erik
>>>
>>>
>>> _______________________________________________
>>> Rtg-dt-encap-considerations mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtg-dt-encap-considerations
>>>
>> _______________________________________________
>> Rtg-dt-encap-considerations mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtg-dt-encap-considerations
>>
>