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

[Erik Nordmark <[e-mail]>]

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
>