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

[Magnus Westerlund <[e-mail]>]

Hi,

I understand that you are considering this an improvements. However, from my
perspective this document fails massively the alone on an island test. No one
can implement this without having the specification from an operator for what
they actually want to establish. 

This in its turn makes it impossible to answer if there are issues or not and
additional configuration are needed for things like UDP zero-checksum, ECN, ICMP
processing etc. All these nitty gritty details that can make a tunnel work good
or not from an upper layer protocol perspective. 

So after some discussion with the rest of the IESG I have decided to go to
Abstain on this document. 

Cheers

Magnus Westerlund


On Tue, 2021-01-12 at 16:21 +0000, John Scudder wrote:
> 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]> 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]> 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. 
> 
>