Subject: Re: [mpls] [Fwd: Repeated WG last call on draft-ietf-mpls-in-udp]

From: Loa Andersson <[email-masked]>
Date: Wed, 24 Dec 2014 10:06:50 +0800

Gorry, Working Group, Authors,

We have received the the comments below from Gorry - tnx!

The document is in IETF Last Call, my suggestion (Shepherd cape on) is
that these comments are addressed together with other LC comments.

/Loa

On 2014-12-23 23:15, [email-masked] wrote:
> Forwarded: fixing typo in recipient address
>
> ---------------------------- Original Message ----------------------------
> Subject: Repeated WG last call on draft-ietf-mpls-in-udp
> From:    [email-masked]
> Date:    Tue, December 23, 2014 3:13 pm
> To:      [email-masked]'
>           [email-masked]
> Cc:      [email-masked]
> bcc: "david black"
> --------------------------------------------------------------------------
>
> Hi all,
>
> MPLS Chairs:: I'm OK with forwarding this message to the mailing list -
> normally I would have replied to the WGLC, but was somewhat overloaded
> this last month.
>
> Best wishes,
>
> Gorry
>
> ====
>
> Overall:
> I have read the latest version of draft-ietf-mpls-in-udp.
>
>   In many places the new text is much clearer, and seems to more clearly
> express what should be done. It also much more clearly captures the scope
> of deployment - which in my mind helps to justify the approach taken.
>
> I think with minor corrections this is ready to proceed.
>
> Comments follow:
>
> Abstract:
> - The deployment scenario for this protocol is very narrow, I think it is
> important that this should appear in the abstract:
> "The MPLS-in-UDP encapsulation technology must only be deployed within a
> Service Provider (SP) network or networks of an adjacent set of
> co-operating SPs where congestion control is not a concern, rather than
> over the Internet where congestion control is required."
>
> S1.1:
> - There is an entropy field in the IPv6 header (flow label) that can be
> used for this purpose. RFC6438 describes this, and should be cited as an
> existing mechanism for IPv6.
>
> S3:
> - RFC5405 states "SHOULD" use a UDP checksum for IPv4, in that case, it
> may be wise to simply provide a line or two to say why the current method
> was chosen.
>
> S3.1:
> Currently says:
> /c.  An MPLS-in-UDP receiver node SHOULD only allow the use of UDP
> zero-checksum mode for IPv6 on a single UDP port regardless of sender. /
> - but the UDP API defines port pairs, os this is confusing. I think it
> would be clearer to state:
> /c.  An MPLS-in-UDP receiver node SHOULD only allow the use of UDP
> zero-checksum mode for IPv6 on a single received UDP Destination Port
> regardless of the sender. /
>
> S5:
> Currently says:
> / For this reason, where MPLS-in-UDP tunneling is used to carry IP traffic
> that is known to be congestion controlled, the UDP tunnels MAY be used
> across any combination of a single service provider, multiple cooperating
> service providers, or across the general
> Internet. /
> - I disagree with this (without commenting on whether the argument holds
> for the general Internet). My main point of disagreement is that this sets
> a different applicability statement to that of section 1.3. If the
> statement here were to read as below, I would have no issue (if this
> directly followed 1.3):
> / For this reason, where MPLS-in-UDP tunneling is used to carry IP traffic
> that is known to be congestion controlled, the UDP tunnels MAY be used
> within
> a Service Provider (SP) network or networks of an adjacent set of
> co-operating SPs.  /
> - If a different scope is intended this would need careful consideration.
>
> S5:
> Currently says:
>
> /   b.  Deployment of packet filters that block the UDP ports assigned for
> MPLS-over-UDP.
> /
> - I agree, but I think actually it is wiser to state:
> /   b.  Deployment of packet filters that block the UDP Destination Ports
> used for MPLS-over-UDP.
> /
>
> S6:
> Discusses issues with IPsec, but I think could usefully point back at
> RFC6438 as an alternative that could be used.
>
> -- end --
>
>
>
>
>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: [email-masked]
Date: Wed, 24 Dec 2014 08:09:48 -0000

Thanks - look forward to seeing a reply or revised version then.

Gorry