Re: [mpls] fwd: New Version Notification - draft-ietf-mpls-in-udp-05.txt

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Xuxiaohu writes:
 
> Hi all,
>  
> A new version (-05) has been submitted for draft-ietf-mpls-in-udp:
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-in-udp-05.txt 
>  
> Diff from previous version:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-in-udp-05
>  
> The comments and suggestions received during the Last Call has been
> incorporated in this revision, especially the rough consensus on
> congestion control and checksum. Thanks a lot for those people who
> have contributed their time and energy to review and help improving
> this doc.
>  
> Best regards,
> Xiaohu (on behalf of all co-authors)


Xiaohu,

It looks like I get to be the first to comment on the new version of
this draft, though there has been considerable noise^H^H^H^H^H
discussion tangentially related to this draft.

Substantive (though perhaps not major):

  Please consider this change to "UDP Checksum" in Section 3:

   OLD

      The usage of this field is in accordance with the current UDP
      specification [RFC768]. In the IPv4 UDP encapsulation case, this
      field is RECOMMENDED to be set to zero. In the IPv6 UDP
      encapsulation case, this field SHOULD NOT be set to zero. If the
      UDP checksum needs to be disabled for performance or
      implementation reasons, the considerations described in
      [RFC6935] [RFC6936] MUST be examined.

   NEW

      The usage of this field is as defined in the current UDP
      specification [RFC768].  UDP allows the UDP checksum to be set
      to zero indicating that no checksum was computed.  Except in
      extroidinary cases, non-zero UDP checksum SHOULD be used. The
      considerations described in detail in [RFC6935] [RFC6936] MUST
      be examined if UDP checksums need to be disabled for performance
      or implementation reasons.  UDP checksum should only be disabled
      on private networks or where MPLS in UDP encapsualation is added
      by a service provider with MPLS in UDP traffic entirely confined
      to the network of that service provider or within cooperating
      service providers with explicit permission.

      Where it is not possible to use full UDP checksum, and if using
      UDP-Lite [RFC3828] is feasible, UDP-Lite SHOULD be used rather
      than UDP with disabled checksums.

  The above is more palatable to some people who object to not using
  checksums but allows zero checksums if there is no other option.

  Also please change the "Congestion Considerations" wording.  The
  deletions and additions are highlighted with beginning of line
  markings similar to unified diffs.

   OLD

-     Since the MPLS-in-UDP encapsulation causes MPLS packets to be
-     forwarded through "UDP tunnels", the congestion control
      guidelines for UDP tunnels as defined in Section 3.1.3 of
      [RFC5405] SHOULD be followed. Specifically, as stated in Section
      3.1.3 of [RFC5405], "some bulk transfer applications may choose
      not to implement any congestion control mechanism and instead
      rely on transmitting across reserved path capacity. This might
      be an acceptable choice for a subset of restricted networking
      environments, but is by no means a safe practice for operation
      in the Internet."
-     Given the fact that the 
      MPLS-in-GRE and MPLS-in-IP [RFC4023]
-     encapsulation technologies
      have been successfully deployed
-     within a SP network or networks of an adjacent set of
-     co-operating SPs which is a restricted network environment
      without any congestion control mechanism
-     and the fact that the current MPLS technology couldn't provide
-     congestion control without major changes, the MPLS-in-UDP
-     encapsulation MUST only be deployed within a SP network or
-     networks of an adjacent set of co-operating SPs as well.

   NEW

+     MPLS-in-UDP is applicable in limited circumstances (See Section
+     1.3).  If deployed in a manner consistent with this
+     applicability statement, then
      guidelines for UDP tunnels as defined in Section 3.1.3 of
      [RFC5405] SHOULD be followed. Specifically, as stated in Section
      3.1.3 of [RFC5405]:

        "some bulk transfer applications may choose not to implement
        any congestion control mechanism and instead rely on
        transmitting across reserved path capacity. This might be an
        acceptable choice for a subset of restricted networking
        environments, but is by no means a safe practice for operation
        in the Internet."

+     This usage is consistent with
      MPLS-in-GRE and MPLS-in-IP [RFC4023]
+     which have been
      successfully deployed
+     in deployments consistent with the applicability of MPLS-in-UDP
+     defined in Section 1.3 and have been deployed
      without any congestion control mechanism.

      If MPLS-in-UDP is deployed in a manner that is not consistent
      with the applicability of MPLS-in-UDP defined in Section 1.3,
      then one of the following conditions SHOULD be met:

        1.  The traffic within the encapsulated MPLS payload is known
            to be predominantly either TCP dominated IP traffic which
            supports end-to-end congestion control, or another type of
            traffic which supports end-to-end congestion control.

        -- OR --

        2.  DCCP [RFC4340] SHOULD be used in place of UDP.  CCID 3 as
            defined in RFC 4340 is RECOMMENDED since it will provde
            better performance if the MPLS encapsulated payload is TCP
            dominated or is TCP-like in its response to congestion.

  The above text makes a recommendation for the type of congestion
  control to be used if the applicability statement is not adhered
  to.  This may be more palatable to those who have objected to the
  current statements on congestion in this document.  The change to
  the original text is mostly wording changes, but essetially says the
  same thing, but with an emphasis on meeting the applicability.

May be significant:

  This (in "Processing Procedures") doesn't make sense to me:

   OLD

     As for whether the top label in the MPLS label stack is
     downstream-assigned or upstream-assigned, it SHOULD be determined
     based on the tunnel destination IP address. That is to say, if
     the destination IP address is a multicast address, the top label
     SHOULD be upstream-assigned, otherwise if the destination IP
     address is a unicast address, it SHOULD be downstream-assigned.

  The encapsulator as an LSR (not LER) should be receiving MPLS
  packets with a MPLS label stack.  It should do a label operation,
  such as a label swap, and then put a IP and UDP encapsulation in
  front of the packet.  What MPLS operation to apply should be out of
  scope for this document since it will be the result of either 1) a
  long-distand LDP (T-LDP) session, or 2) a long distance RSVP-TE (no
  special name, just TTL>1) session, or some form of management magic
  that directly programs a label operation for a given inbound label.

  I suggest that you change this text to this and start a new
  paragraph.

     The encapsulator acting in an LSR role for some set of LSP is
     assumed to receive MPLS encapsulated traffic, perform some label
     operation, and forward the packet with MPLS-in-UDP IP and UDP
     encapsulation added.  The encapsulator acting in the LER role for
     some set of LSP is assumed to receive non-MPLS traffic, push MPLS
     labels and forward the packet with MPLS-in-UDP IP and UDP
     encapsulation added.  How the label operations to be carried out
     are determined is out of scope for this document but is expected
     to be most often determined through LDP or RSVP-TE signaling, or
     through management plane actions.

  Nit: Then in next paragraph s/As such, intermediate/Intermediate/

  Nit: Next paragraph s/As for other/For other/

Minor:

  There are two cases for setting the source port.

   OLD

     In the case where the tunnel does not need entropy, this field of
     all packets belonging to a given flow SHOULD be set to a randomly
     selected constant value so as to avoid packet reordering.

   NEW

     Where the tunnel needs entropy, the source port for all packets
     belonging to a given flow SHOULD be set to the same value to
     avoid reordering within a microflow.  Where the tunnel does not
     need entropy, the source port for all packets belonging to a
     given MPLS LSP SHOULD be set to a randomly selected per LSP
     constant value so as to avoid packet reordering within any given
     LSP.

  The above two sentences should probably start a new paragraph.

Nit:

  Drop "Note that" in the begginging of the second sentence of the
  abstract, but keep the sentence.
  s/the congestion control/congestion control/

  s/[RFC 6830]/[RFC6830]/

  Remove redundancy:
  /Currently, most existing routers/Currently, most routers/
  or
  /Currently, most existing routers/Most existing routers/

  s/where the congestion control is a must.
   /where the congestion control is required./

  s/so as to/to/

  Idnits will get you on a long line in "MPLS Label Stack" ending in
  lots of spaces and [RFC3032].  Don't use ms-word for RFCs and you'll
  have less of this sort of headache.

  Drop "as well" in the sentence that starts with "What algorithm is
  actually used " in "Source Port of UDP".

  Idnits will get you on a long line in RFC768 in references, also
  RFC3032, RFC6347, RFC6438, RFC6830.  You should check Idnits when
  you submit so you can pick up small easy to fix stuff like this.

Other:

  Security ADs will likely reword "Security Considerations".

Please reply and indicate whether you agree with the "substantive
changes" above so the WG can discuss this.

With any luck there will be no objection simply because everyone
already has mpls-in-udp in their procmail filters.  :-)

Regards,

Curtis