Thanks for the great discussion Brian. I think we’re all in sync now?

Dino

> On Aug 30, 2018, at 8:46 AM, Brian Trammell (IETF) <[email protected]> wrote:
> 
> 
> 
>> On 30 Aug 2018, at 16:55, Dino Farinacci <[email protected]> wrote:
>> 
>>> On Aug 30, 2018, at 2:57 AM, Brian Trammell (IETF) <[email protected]> wrote:
>>> 
>>> hi Dino,
>>> 
>>> Almost. How about:
>>> 
>>> 
>>> OLD:
>>> 
>>> When the UDP and LISP headers require integrity protection, the
>>> methods of using UDP checksums in [RFC8085] can be considered.
>>> 
>>> NEW:
>>> 
>>> Implementors are encouraged to consider UDP checksum usage guidelines in 
>>> section 3.4 of [RFC8085]. Specifically, when the UDP, LISP, and outer IPv6 
>>> headers require protection against corruption, the use of non-zero UDP 
>>> checksums is RECOMMENDED.
>> 
>> Well if we recommend it and when describing the UDP header in the packet 
>> format section we don’t that woudl be a contracdiction.
> 
> I think my point here is that the packet format section probably shouldn't do 
> that. :) Yes, I understand the disconnect between the reality of the 
> situation and the
> 
>> And note the IPv6 outer header cannot be protected with a UDP checksum. The 
>> link-layer CRC will do that.
> 
> Eh, this makes assumptions about the underlying link layer's corruption 
> characteristics that may not hold. But yeah, for most packets in most 
> realistic situations this is the case, and I guess we've learned to live with 
> the underlying phy error rate * 1e-10 in any case.
> 
>> NEWNEW:
>> 
>> Implementors are encouraged to consider UDP checksum usage guidelines in 
>> section 3.4 of [RFC8085] when
>> it is desirable to protect UDP and LISP headers against corruption.
>> 
>> What do you think?
> 
> This seems like a fine compromise to me.
> 
> Thanks, cheers,
> 
> Brian
> 
>> 
>> Dino
>> 
>> _______________________________________________
>> Tsv-art mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/tsv-art
> 

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

Reply via email to