Re: [Idr] Magnus Westerlund's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS)

[John Scudder <[e-mail]>]

Hi Magnus,

I’ve read your comments a few times and given them some thought. As best I can determine, your biggest concern is that there are assumptions made about the forwarding plane, that aren’t signaled. I can see that this might pose real problems with deployments running across the big-I Internet, traversing uncoordinated infrastructure. This is presumably the same as tunnel deployment across uncoordinated infrastructure now. It seems to me though, that in the scope we’ve restricted applicability to (see Section 11), it’s reasonable to assume that the infrastructure is NOT uncoordinated. We are trying to provide an incremental improvement over configuring tunnels by hand. I agree a “do no harm” principle is good, and I *think* we’ve done no harm compared to the status quo.

I sympathize with your goals here:

But, I think the document needs to go in
either of two directions here. The first is to be specific on combinations of
tunnel and outer encapsualtion and document the assumptions about capabilities
and requirements on the network deployment to use these zero-checksum as well as
ECN field processing. The other direction is to make this into a framework, but
then you are going to have to discuss these matters in the abstract and likely
need to have signalling indicate what the egress will do in regards.

But it seems to me that (if I understand you correctly) this is a big scope increase that’s likely to set us back quite a long time, and comes down to perfect being the enemy of good. :-/

However, I might well still be misunderstanding you. If so, I think a voice call might be a better way forward than continuing to iterate in email. If you’d like to go that route, please unicast me with some times that work for you? (I’m in U.S. Eastern Time.)

Thanks,

—John

On Dec 7, 2020, at 8:38 AM, Magnus Westerlund <[e-mail]<mailto:[e-mail]>> wrote:

On Fri, 2020-12-04 at 20:38 +0000, John Scudder wrote:
Hi Magnus,

For now I’d like to talk just about your zero-checksum point (quoted below but
I’ll top-post my comments). It seems to me that the expected deployment model
for tunnel-encaps, detailed in Section 11 and further strengthened after my
discussion with Roman, exactly corresponds with "single administrative
control” or "closely cooperating network administrations”. Here’s the Section
11 text from the current candidate version 21, after the modification:

  The Tunnel Encapsulation attribute is defined as a transitive
  attribute, so that it may be passed along by BGP speakers that do not
  recognize it.  However the Tunnel Encapsulation attribute MUST be
  used only within a well-defined scope, for example, within a set of
  Autonomous Systems that belong to a single administrative entity.

Whether it would be nice to add a “should we use UDP checksums or not” sub-TLV
anyway, as an additional bell and whistle, is up for discussion. But I don’t
think it’s mandated by RFC 7510.

The above text clarifies the scope of this document. I think there are ways of
avoiding a TLV for RFC 7510 usages, however, I think that this is in fact
through documenting the assumption in regards to this protocol usage.

My point is that this document do need per tunnel protocol sections where these
aspect can be considered in this context of this tunnel configuration mechanism.
I am a bit uncertain in my understanding about how this BGP attribute is used.
However, it looks to me that a decapsulator will basically tell those other
entities in the other AS that it cooperates with that you can establish a tunnel
to the decapsulator in relation to a set of routes. However, if that is the
correct understanding then a number of assumptions are made. I think in the
context of RFC7510 you are assuming that zero-checksum is either MAY or MUST be
used for this to work. If it is the later then you also put a requirement on the
receiver of these attributes to not establish a tunnel if it thinks the
requirements in RFC7510 for zero-checksum is not met.

To conclude I don't think you get away from discussing these aspects in the
document. However, it can be so that there exist no need for defining additional
sub-tlvs for the aspects I brought up. But, I think the document needs to go in
either of two directions here. The first is to be specific on combinations of
tunnel and outer encapsualtion and document the assumptions about capabilities
and requirements on the network deployment to use these zero-checksum as well as
ECN field processing. The other direction is to make this into a framework, but
then you are going to have to discuss these matters in the abstract and likely
need to have signalling indicate what the egress will do in regards.

From my perspective not discussing zero-checksum and ECN behavior leaves
implementors unaware of relevant implementation requirements. And if a missmatch
occurrs those who sees the downside is likely not the nodes that causes the
issue. For the wrong ECN behaviors this has just casued a change in end-to-end
network flow behaviors as CE marks might be dropped in the egress. For zero-
checksum tunnels usage where the underlying network is corrupting enough packets
these affects those endpoints that receives corrupt packets.

Cheers

Magnus



Thanks,

—John

On Dec 4, 2020, at 5:43 AM, Magnus Westerlund <
[e-mail]<mailto:[e-mail]>> wrote:

My impression for example when it comes to zero-checksum for IPv6/UDP is
used
widely with little consideration about the potential issues. However, this
work
is done in a WG for inter domain routing. Thus, the general context is inter
domain routing, and that pushes the zero-checkum usage from within a single
domain into multiple ones. Thus, the risk for errors that checksum would
detect
is different and also the potential impact of failure to verify is
different.
Thus, there might actually exist a configuraiton need for this if one
intended
to pay attention to what might be written into the user plane specification.
Here actually we do have an issue with RFC 7510:

So your document states:

 MPLS-in-UDP [RFC7510] is also supported, but an
 Encapsulation sub-TLV for it is not needed since there are no
 additional parameters to be signaled.

While if you go read Section 3.1 of RFC 7510 it states the following in
regards
to zero-checksum:

 The UDP checksum MUST be implemented and MUST be used in accordance
 with [RFC768] and [RFC2460] for MPLS-in-UDP traffic over IPv6 unless
 one or more of the following exceptions applies and the additional
 requirements stated below are complied with.  There are three
 exceptions that allow use of UDP zero-checksum mode for IPv6 with
 MPLS-in-UDP, subject to the additional requirements stated below in
 this section.  The three exceptions are:

 a.  Use of MPLS-in-UDP in networks under single administrative
     control (such as within a single operator's network) where it is
     known (perhaps through knowledge of equipment types and lower-
     layer checks) that packet corruption is exceptionally unlikely
     and where the operator is willing to take the risk of undetected
     packet corruption.

 b.  Use of MPLS-in-UDP in networks under single administrative
     control (such as within a single operator's network) where it is
     judged through observational measurements (perhaps of historic or
     current traffic flows that use a non-zero checksum) that the
     level of packet corruption is tolerably low and where the
     operator is willing to take the risk of undetected packet
     corruption.

 c.  Use of MPLS-in-UDP for traffic delivery for applications that are
     tolerant of misdelivered or corrupted packets (perhaps through
     higher-layer checksum, validation, and retransmission or
     transmission redundancy) where the operator is willing to rely on
     the applications using the tunnel to survive any corrupt packets.

 These exceptions may also be extended to the use of MPLS-in-UDP
 within a set of closely cooperating network administrations (such as
 network operators who have agreed to work together in order to
 jointly provide specific services).  Even when one of the above
 exceptions applies, use of UDP checksums may be appropriate when VPN
 services are provided over MPLS-in-UDP; see Section 6.

 As such, for IPv6, the UDP checksum for MPLS-in-UDP MUST be used as
 specified in [RFC768] and [RFC2460] for tunnels that span multiple
 networks whose network administrations do not cooperate closely, even
 if each non-cooperating network administration independently
 satisfies one or more of the exceptions for UDP zero-checksum mode
 usage with MPLS-in-UDP over IPv6.

So this indicate to me that there is a significant likelyhood that for the
intended usage of these tunnel encapsulations would not qualify for the
exceptions and should use checksums. If that needs signalling or not is the
next
question. That comes back to how the configuring node knows about
capabilities
and how one can resolve lack of a capability when signalled.