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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Xuxiaohu writes:
 
> Hi Curtis,
>  
> Thanks a lot for your review and comments. Please see my response inline.

I think we have agreement and are discussing only minor wording
changes to improve clarity.  See inline.

> > -----ÓʼþÔ­¼þ-----
> > ·¢¼þÈË: Curtis Villamizar [mailto:[e-mail]]
> > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ31ÈÕ 9:38
> > ÊÕ¼þÈË: Xuxiaohu
> > ³­ËÍ: [e-mail]
> > Ö÷Ìâ: Re: [mpls] fwd: New Version Notification - draft-ietf-mpls-in-udp-05.txt
> > 
> > 
> > In message
> > <[e-mail].
> > huawei.com>
> > 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 change looks fine to me. Thanks.
>  
> >   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.
>  
> The above change looks fine to me. Thanks.
>  
> >       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.
> > 
>  
> It has been said in the applicability statement that " The
> MPLS-in-UDP encapsulation technology MUST only be deployed
> ...". In other word, this technology MUST ONLY be deployed in a
> restricted network environment. Hence I wonder whether it's still
> necessary to specify guidelines for the deployment case which is
> not in accordance with that applicability statement. 

If no one else objects, I'm fine with leaving this out.  The one or
two people making all the noise have not commented on the change.

> >   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 above description is intended to be consistent with the
> corresponding specification in the MPLS-in-GRE and MPLS-in-IP
> cases. Since the outermost LSP tunnel is now replaced with the
> IP-based tunnel (i.e., the UDP tunnel here), whether the top
> label in the MPLS label stack is downstream-assigned or
> upstream-assigned should be identified according to the
> destination IP address of the IP-based tunnel. 

To be honest, I never paid much attention to MPLS-in-GRE and
MPLS-in-IP.

Whether downstream-assigned or upstream-assigned doesn't really depend
on whether the dest IP is unicast or multicast.

> >   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.
>  
> The encapsulator could also be a PE router. In this case, the top
> label in the MPLS label stack could be a VPN label which may be
> downstream-assigned or upstream-assigned. 

So what?  The point is that the label allocation is done be 1) RSVP-TE
PTP, 2) RSVP-TE P2MP, 3) LDP PTP, LDP P2MP, and the new LDP MP2MP used
to support <*,G>.  It doesn't matter to the tunnel functionality which
end does the label allocation.

In any case, I don't think this is clearly written, but if it was good
enough for MPLS-in-GRE and MPLS-in-IP, then I'm fine with leaving it
in as-is.

> >   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/
>  
> Fixed, thanks.
>  
> >   Nit: Next paragraph s/As for other/For other/
>  
> Fixed, thanks.
>  
> > 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
>  
> Has the meaning of the above sentence been expressed by the following one:
>  
> "This field contains a 16-bit entropy value that is
>                 generated by the encapsulator to uniquely identify a
>                 flow."
>  
> >      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.

I think the suggested rewording is more clear, but I'm OK with you not
accepting this change.

> > 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.
>  
> All the above nits would be fixed, thanks.
>  
> > 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.
>  
> Most of your proposed changes look fine to me. Thanks a lot again
> for your detailed review and comments.
>  
> > With any luck there will be no objection simply because everyone already has
> > mpls-in-udp in their procmail filters.  :-)
>  
> I hope so too;)
>  
> Best regards,
> Xiaohu
>  
> > Regards,
> > 
> > Curtis

The only changes still discussed above are for clarity only and I'm OK
with you not accepting those changes.  Thanks for considering thosee
suggestions as well as making the few changes and nit fixes that you
have agreed to so far.  Since I'm OK with you not accepting the
remaining "just for clarity" changes, I think we're done.

Curtis