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

[Magnus Westerlund <[e-mail]>]

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]> 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. 
> 
>