Subject: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-over-udp-ip-07: (with DISCUSS)

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Wed, 02 Dec 2020 07:47:06 -0800

Magnus Westerlund has entered the following ballot position for
draft-ietf-detnet-mpls-over-udp-ip-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-over-udp-ip/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

So there might be something missing here in regards to zero-checksum in UDP
when using IPv6. So Section 3.1 in RFC 7510 discusses this for MPLS over UDP
and have some considerations that needs to be done if one are intending to use
zero checksum. To me it appears that DETNET flows can not be guaranteed to
always fulfill these, and in case you think you can motivate it should probably
be stated explicitly and normatively allow it. So if it can't be guaranteed to
fulfill these requirements then the next question exists: Do the possibility to
use zero-checksum for this flow become something the control plane needs to
signal it?

---

From: Balázs Varga A <[email-masked]>
Date: Wed, 2 Dec 2020 17:24:38 +0000

Hi,

Chapter 5. of draft-ietf-detnet-mpls-over-udp-ip provides a _non-exhaustive_ list of control and management plane information. 
DetNet does not changes rules of rfc7510: if the exceptions listed in 3.1 of rfc7510 applies, then using zero checksum is allowed; 
otherwise not. 

A possible solution can be to add an additional information element to the list in chapter 5, which allow or not the usage of
zero-checksum.

Thanks & Cheers
Bala'zs

-----Original Message-----
From: detnet <[email-masked]> On Behalf Of Magnus Westerlund via Datatracker
Sent: Wednesday, December 2, 2020 4:47 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-over-udp-ip-07: (with DISCUSS)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

So there might be something missing here in regards to zero-checksum in UDP when using IPv6. So Section 3.1 in RFC 7510 discusses this for MPLS over UDP and have some considerations that needs to be done if one are intending to use zero checksum. To me it appears that DETNET flows can not be guaranteed to always fulfill these, and in case you think you can motivate it should probably be stated explicitly and normatively allow it. So if it can't be guaranteed to fulfill these requirements then the next question exists: Do the possibility to use zero-checksum for this flow become something the control plane needs to signal it?

_______________________________________________
detnet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/detnet

---

From: "Black, David" <[email-masked]>
Date: Wed, 2 Dec 2020 22:40:18 +0000

Hi Balazs,

Digging in a little deeper, I concur with Magnus's underlying concern that this draft ought to say something about UDP checksums with IPv6.  There's a useful starting point at the end of the Introduction (Section 1):

   As specified in [RFC7510]: "MPLS-in-UDP MUST NOT be used over the
   general Internet, or over non-cooperating network operators, to carry
   traffic that is not congestion controlled."  This does apply to
   DetNet networks as this document focuses on solutions for networks
   that are under a single administrative control or within a closed
   group of administrative control.

That suggests that the first two exceptions (a & b)  in Section 3.1 of RFC 7510 (both of which involve single administrative control) are more likely to apply to DetNet than the third one (c, based on higher layer recovery and/or error tolerance).  It could be helpful to say that in an added paragraph on UDP checksums (for both v4 and v6) at the end of Section 4 in this draft.

I would also suggest aligning the text quoted above (from the end of Section 1) with the text used in exceptions a. & b. in Section 3.1 of RFC 7510, as I think roughly the same scope is intended.  In particular, it appears to me that this draft's notion of "closed group of administrative control" would fall under the notion of "single administrative control" in RFC 7510 (FWIW, I'm an author of RFC 7510).

The suggestion to add use/non-use of UDP checksum to the list of management and control information in Section 5 is a good idea - that addition ought to cite Section 3.1 of RFC 7510 for the conditions under which the UDP checksum may be disabled for IPv6 (per RFC 7510, UDP checksum for IPv6 "MUST be implemented" for MPLS-in-UDP).

Thanks, --David

> From: detnet <[email-masked]> On Behalf Of Balázs Varga A
> Sent: Wednesday, December 2, 2020 12:25 PM
> To: Magnus Westerlund; The IESG
> Subject: Re: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-over-
> udp-ip-07: (with DISCUSS)
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi,
> 
> Chapter 5. of draft-ietf-detnet-mpls-over-udp-ip provides a _non-exhaustive_ list of
> control and management plane information.
> DetNet does not changes rules of rfc7510: if the exceptions listed in 3.1 of rfc7510
> applies, then using zero checksum is allowed; otherwise not.
> 
> A possible solution can be to add an additional information element to the list in
> chapter 5, which allow or not the usage of zero-checksum.
> 
> Thanks & Cheers
> Bala'zs
> 
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> when using IPv6. So Section 3.1 in RFC 7510 discusses this for MPLS over UDP and
> have some considerations that needs to be done if one are intending to use zero
> checksum. To me it appears that DETNET flows can not be guaranteed to always
> fulfill these, and in case you think you can motivate it should probably be stated
> explicitly and normatively allow it. So if it can't be guaranteed to fulfill these
> requirements then the next question exists: Do the possibility to use zero-checksum
> for this flow become something the control plane needs to signal it?
> 
> 
> 
> 
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 3 Dec 2020 09:13:17 +0000

Hi,

David's suggestions is definitely the direction I was considering to resolve
this.

Cheers

Magnus

On Wed, 2020-12-02 at 22:40 +0000, Black, David wrote:
> Hi Balazs,
> 
> Digging in a little deeper, I concur with Magnus's underlying concern that
> this draft ought to say something about UDP checksums with IPv6.  There's a
> useful starting point at the end of the Introduction (Section 1):
> 
> That suggests that the first two exceptions (a & b)  in Section 3.1 of RFC
> 7510 (both of which involve single administrative control) are more likely to
> apply to DetNet than the third one (c, based on higher layer recovery and/or
> error tolerance).  It could be helpful to say that in an added paragraph on
> UDP checksums (for both v4 and v6) at the end of Section 4 in this draft.
> 
> I would also suggest aligning the text quoted above (from the end of Section
> 1) with the text used in exceptions a. & b. in Section 3.1 of RFC 7510, as I
> think roughly the same scope is intended.  In particular, it appears to me
> that this draft's notion of "closed group of administrative control" would
> fall under the notion of "single administrative control" in RFC 7510 (FWIW,
> I'm an author of RFC 7510).
> 
> The suggestion to add use/non-use of UDP checksum to the list of management
> and control information in Section 5 is a good idea - that addition ought to
> cite Section 3.1 of RFC 7510 for the conditions under which the UDP checksum
> may be disabled for IPv6 (per RFC 7510, UDP checksum for IPv6 "MUST be
> implemented" for MPLS-in-UDP).
> 
> Thanks, --David
> 
> > Subject: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-
> > over-udp-
> > ip-07: (with DISCUSS)
> > 
> > and

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 3 Dec 2020 17:25:34 +0000

I am not sure I understand why any additional text is needed.

We agree that Detnet fulfils the requirements to run with no c/s, and adding a c/s is going to degrade performance since forwarders in routers cannot see the whole of the packet in the fast path and so using a c/s is actually going to degrade the detent performance in many cases by adding latency.

So if we are going add text I think we need to add a warning not to use the c/s unless you have special h/w to support its calculation automatically.

On the other hand we could without risk remain silent and leave this to the implementors & operators to agree since there is no interoperability issue.

- Stewart

> On 2 Dec 2020, at 22:40, Black, David <[email-masked]> wrote:
> 
> Hi Balazs,
>

---

From: "Black, David" <[email-masked]>
Date: Thu, 3 Dec 2020 20:58:53 +0000

Stewart,

> We agree that Detnet fulfils the requirements to run with no c/s.

I'm not sure whether you and Balazs are aligned on what to do.  Anyhow ... attempting to explain ...

The additional text would (briefly) describe how DetNet/MPLS/UDP/IPv6 fulfills RFC 7510's requirements for not using the UDP checksum (NB: the UDP checksum considerations for IPv4 are very different and do not need this level of attention, see RFC 7510, Section 3 [not 3.1]).  The text might be a brief explanation of why most (all?) DetNet/MPLS/UDP/IPv6 implementations satisfy exception a or b in Section 3.1 of RFC 7510.

Thanks, --David

> From: Stewart Bryant <[email-masked]>
> Sent: Thursday, December 3, 2020 12:26 PM
> To: Black, David
> Cc: Stewart Bryant; Balázs Varga A; Magnus Westerlund; The IESG;
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> We agree that Detnet fulfils the requirements to run with no c/s, and adding a c/s is
> going to degrade performance since forwarders in routers cannot see the whole of
> the packet in the fast path and so using a c/s is actually going to degrade the detent
> performance in many cases by adding latency.
> 
> So if we are going add text I think we need to add a warning not to use the c/s
> unless you have special h/w to support its calculation automatically.
> 
> On the other hand we could without risk remain silent and leave this to the
> implementors & operators to agree since there is no interoperability issue.
> 
> - Stewart
> 
> > Digging in a little deeper, I concur with Magnus's underlying concern that this
> draft ought to say something about UDP checksums with IPv6.  There's a useful
> starting point at the end of the Introduction (Section 1):
> >
> > That suggests that the first two exceptions (a & b)  in Section 3.1 of RFC 7510
> (both of which involve single administrative control) are more likely to apply to
> DetNet than the third one (c, based on higher layer recovery and/or error
> tolerance).  It could be helpful to say that in an added paragraph on UDP checksums
> (for both v4 and v6) at the end of Section 4 in this draft.
> >
> > I would also suggest aligning the text quoted above (from the end of Section 1)
> with the text used in exceptions a. & b. in Section 3.1 of RFC 7510, as I think roughly
> the same scope is intended.  In particular, it appears to me that this draft's notion
> of "closed group of administrative control" would fall under the notion of "single
> administrative control" in RFC 7510 (FWIW, I'm an author of RFC 7510).
> >
> and control information in Section 5 is a good idea - that addition ought to cite
> Section 3.1 of RFC 7510 for the conditions under which the UDP checksum may be
> disabled for IPv6 (per RFC 7510, UDP checksum for IPv6 "MUST be implemented"
> for MPLS-in-UDP).
> >
> > Thanks, --David
> >
> >> Cc: [email-masked]; [email-masked];
> >> draft-ietf-detnet-mpls-over-udp- [email-masked]; [email-masked]
> >> Chapter 5. of draft-ietf-detnet-mpls-over-udp-ip provides a
> >> _non-exhaustive_ list of control and management plane information.
> >> DetNet does not changes rules of rfc7510: if the exceptions listed in
> >> 3.1 of rfc7510 applies, then using zero checksum is allowed; otherwise not.
> >>
> >> A possible solution can be to add an additional information element
> >> to the list in chapter 5, which allow or not the usage of zero-checksum.
> >>
> >> Thanks & Cheers
> >> Bala'zs
> >>
> >>
> >> Cc: [email-masked]; [email-masked];
> >> draft-ietf-detnet-mpls-over-udp- [email-masked]; [email-masked]
> >> Subject: [Detnet] Magnus Westerlund's Discuss on
> >> draft-ietf-detnet-mpls-over-udp-
> >> ip-07: (with DISCUSS)
> >>
> >> email addresses included in the To and CC lines. (Feel free to cut
> >> this introductory paragraph, however.)
> >>
> >>
> >> Please refer to
> >> https://www.ietf.org/iesg/statement/discuss-criteria.html
> >> So there might be something missing here in regards to zero-checksum
> >> in UDP when using IPv6. So Section 3.1 in RFC 7510 discusses this for
> >> MPLS over UDP and have some considerations that needs to be done if
> >> one are intending to use zero checksum. To me it appears that DETNET
> >> flows can not be guaranteed to always fulfill these, and in case you
> >> think you can motivate it should probably be stated explicitly and
> >> normatively allow it. So if it can't be guaranteed to fulfill these
> >> requirements then the next question exists: Do the possibility to use zero-
> checksum for this flow become something the control plane needs to signal it?
> >>
> >>
> >>
> >>
> >>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 10 Dec 2020 13:17:25 +0000

Dn needs to run in a well managed network to fulfil its loss delay obligations. If the quality of the network is such that the packets may get corrupted then that will have as significant an impact on the DN service, because failure to deliver is as significant an issue as failure to deliver correct packets. In other words whilst the UDP c/s will save the receiving node from receiving a corrupt packet, that failure to deliver also causes applications issues. The only satisfactory way to address this is to ensure the quality of the network is such that rate of corruption is trivial, and thus the rate of c/s error detection would  also be trivial.

It should also be noted that most routers that are capable of high-speed low jitter packet deliver do not have the h/w capability to compute a whole packet c/s on the fly and hence would have to punt the packet to the slow path, which in turn is contra to the requirements of deterministic delivery of the packet.

- Stewart

> On 9 Dec 2020, at 22:53, Black, David <[email-masked]> wrote:
> 
> Suggestion ...
> 
> Stewart - could you write a brief explanation of this statement (from your email to the list)?:
> 
>>> We agree that Detnet fulfils the requirements to run [over IPv6] with no [UDP] c/s,
> 
> The rest of us could then look at that explanation and figure out whether the situation is "always fulfills" (would be nice if true) or "almost always fulfills" (might have to deal with that).
> 
> Thanks, —David

---

From: Balázs Varga A <[email-masked]>
Date: Thu, 10 Dec 2020 15:17:33 +0000

Hi Magnus,

We have discussed the update with the authors + DavidB with the result below.
One more bullet added + clarification text to the paragraph after the list.

OLD TEXT
5.  Management and Control Information Summary
   The following summarizes the set of information that is needed to
   configure DetNet MPLS over UDP/IP:
   o  Label information (A-labels, S-labels and F-labels) to be mapped
      to UDP/IP flow.  Note that for example, a single S-Label can map
      to multiple sets of UDP/IP information when PREOF is used.
   o  IPv4 or IPv6 source address field.
   o  IPv4 or IPv6 destination address field.
   o  DSCP Field in either IPv4 Type of Service or IPv6 Traffic Class
      Fields.
   o  UDP Source Port.
   o  UDP Destination Port.
   This information MUST be provisioned per DetNet flow via
   configuration, e.g., via the controller [RFC8655] or management
   plane.
 
NEW TEXT
5.  Management and Control Information Summary
   The following summarizes the minimum set of information that is needed to
   configure DetNet MPLS over UDP/IP:
   o  Label information (A-labels, S-labels and F-labels) to be mapped
      to UDP/IP flow.  Note that for example, a single S-Label can map
      to multiple sets of UDP/IP information when PREOF is used.
   o  IPv4 or IPv6 source address field.
   o  IPv4 or IPv6 destination address field.
   o  DSCP Field in either IPv4 Type of Service or IPv6 Traffic Class
      Fields.
   o  UDP Source Port.
   o  UDP Destination Port.
   o  use/non-use of UDP checksum.
   This information MUST be provisioned per DetNet flow via
   configuration, e.g., via the controller [RFC8655] or management
   plane. Not using the UDP checksum has to be evaluated on a
   case-by-case basis for a given network scenario based on the
   exception criteria’s defined in [RFC7510], particularly when 
   IPv6 is used.
END

I hope that has resolved your concerns, please confirm.

Many thanks
Bala'zs

-----Original Message-----
From: Magnus Westerlund <[email-masked]> 
Sent: Thursday, December 3, 2020 10:13 AM
To: [email-masked]; balazs.a.varga=[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-over-udp-ip-07: (with DISCUSS)

Hi,

Cheers

Magnus

On Wed, 2020-12-02 at 22:40 +0000, Black, David wrote:
> > checksum

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 Dec 2020 08:33:32 +0000

Hi

Thanks for your work. Yes, what you propose do solve my discuss. Please publish
and I will clear.

Cheers

Magnus

On Thu, 2020-12-10 at 15:17 +0000, Balázs Varga A wrote:
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> > > Subject: Re: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-
> > > mpls-
> > > over-
> > > Chapter 5. of draft-ietf-detnet-mpls-over-udp-ip provides a _non-
> > > exhaustive_ 
> > > list of
> > > DetNet does not changes rules of rfc7510: if the exceptions listed in 3.1
> > > of
> > > rfc7510
> > > email
> > > fulfill these, and in case you think you can motivate it should probably
> > > be
> > > stated
> > > explicitly and normatively allow it. So if it can't be guaranteed to
> > > fulfill
> > > these