Subject: [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Wed, 28 Nov 2012 15:53:26 +0000

I  have reviewed this document.  Like the other reviewers, I agree that it clearly describes what it wants and should be progressed to the WG as a potential WG document.

That said, I have some concerns and comments.

#1: I'm not sure if Section 4 does more harm than good.  If an application is going to receive packets to an 'MPLS' UDP port, it seems like a good idea for a node to announce that it has the capability to receive things on this port.  This is not mandatory, so it should be discussed on the list.  I note that rfc4023 (MPLS in GRE) does not provide such a function.

The document suggests one way that this might be achieved using BGP.  It comes pretty close to specifying how it should work, but the whole section is apparently just an example or a placeholder for a future document.  This seems dangerous, as an implementor may implement the function as described in this section despite it explicitly being an example and a placeholder.

If there is consensus that advertising (or negotiating?) this capability is required, then this capability should be standardized at the same time as the actual encapsulation.  If this capability is not required then this section should be removed from the document.

#2: rfc4023 touches on a number of IP encapsulation details (TTL, QoS, MTU, etc) that this draft does not.  Is the intent for MPLS-in-UDP to use the same behavior as MPLS-in-GRE, but with a UDP encap?  It may be worth spelling out that if there is a question about how certain IP fields should be filled in that rfc4023 procedures should be followed.  I'd hate to end up with an MPLS-in-UDP encap that did different IP TTL things than an MPLS-in-IP encap.

#3: I share Shahram's concern that this is Yet Another Way to solve the same problem.  It is true that not all nodes may be able to load-balance on the GRE key as specified in rfc4023, but the practice of defining new methods to replace slightly older methods due to current hardware limitations seems sketchy.  Most modern hardware is field-programmable, and adding a packet field to a forwarding hash should not require anything more than a software update; coming up with new standards to avoid upgrading software is a bad idea.

For implementations which are not software-upgradable, good standards last a lot longer than a given generation of hardware, and there are a number of advances in the industry which never would have made it if they were ignored because current hardware couldn't do them.  Examples include IPv6 and MPLS.  However, I'm not sure it's within my purview as a RT reviewer to make this argument, so I'll make it again when the WG poll comes up.

#4: The intro says "in most cloud data
   center network environments, data center operators tend to enable IP
   forwarding capability, rather than MPLS forwarding capability in the
   underlying data center networks due to certain reasons."

In line with my point #3, standards last longer than many current practices.  Will this be true in 2025?  What are 'certain reasons'?  I think this sentence would be better off as:

"in current deployments, data center operators tend to enable IP
   forwarding capability, rather than MPLS forwarding capability"

or something less murky and time-bound.

eric

---

From: Lucy yong <[email-masked]>
Date: Wed, 28 Nov 2012 17:10:31 +0000

Hi Eric,

Thank you for your support on this. Please see inline.

> -----Original Message-----
> From: Eric Osborne (eosborne) [mailto:[email-masked]]
> Sent: Wednesday, November 28, 2012 9:53 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: MPLS-RT review of draft-xu-mpls-in-udp-03
> 
> I  have reviewed this document.  Like the other reviewers, I agree that
> it clearly describes what it wants and should be progressed to the WG
> as a potential WG document.
> 
> #1: I'm not sure if Section 4 does more harm than good.  If an
> application is going to receive packets to an 'MPLS' UDP port, it seems
> like a good idea for a node to announce that it has the capability to
> receive things on this port.  This is not mandatory, so it should be
> discussed on the list.  I note that rfc4023 (MPLS in GRE) does not
> provide such a function.
[Lucy] Please see rfc5512. It specifies the need to signal the encapsulation attributes.
> 
> The document suggests one way that this might be achieved using BGP.
> It comes pretty close to specifying how it should work, but the whole
> section is apparently just an example or a placeholder for a future
> document.  This seems dangerous, as an implementor may implement the
> function as described in this section despite it explicitly being an
> example and a placeholder.
> 
> If there is consensus that advertising (or negotiating?) this
> capability is required, then this capability should be standardized at
> the same time as the actual encapsulation.  If this capability is not
> required then this section should be removed from the document.
[Lucy] Thank you for the suggestion. As the last sentence in section 4 stated, authors has a plan to specify the udp based tunnel encapsulation in another document because it can apply not only mpls but also others for example L2TP. We will tweak the text to make it more clear in next version.
> 
> #2: rfc4023 touches on a number of IP encapsulation details (TTL, QoS,
> MTU, etc) that this draft does not.  Is the intent for MPLS-in-UDP to
> use the same behavior as MPLS-in-GRE, but with a UDP encap?  It may be
> worth spelling out that if there is a question about how certain IP
> fields should be filled in that rfc4023 procedures should be followed.
> I'd hate to end up with an MPLS-in-UDP encap that did different IP TTL
> things than an MPLS-in-IP encap.
[Lucy] Thank you for the catching. We will state out in next version.
> 
> #3: I share Shahram's concern that this is Yet Another Way to solve the
> same problem.  It is true that not all nodes may be able to load-
> balance on the GRE key as specified in rfc4023, but the practice of
> defining new methods to replace slightly older methods due to current
> hardware limitations seems sketchy.  Most modern hardware is field-
> programmable, and adding a packet field to a forwarding hash should not
> require anything more than a software update; coming up with new
> standards to avoid upgrading software is a bad idea.
[Lucy] I have to argue this back. GRE based encapsulation has been standardized while ago (rfc4023). However, it has not been widely deployed on the networks because SPs use the MPLS implementation, i.e. label switching. As the result, a lot of devices do not support GRE based encapsulation (edge nodes) as well as GRE based load balance (transit nodes). Mpls-in-udp achieve the same purpose without upgrading the existing transit nodes. Therefore, this is more advance than GRE in rfc4023. 
> 
> For implementations which are not software-upgradable, good standards
> last a lot longer than a given generation of hardware, and there are a
> number of advances in the industry which never would have made it if
> they were ignored because current hardware couldn't do them.  Examples
> include IPv6 and MPLS.  However, I'm not sure it's within my purview as
> a RT reviewer to make this argument, so I'll make it again when the WG
> poll comes up.
[Lucy] Agree with your statement. Thus using some existing and less deployed standard to argue the new advanced mechanism does not stand well. As time moving forward, some new and more advance technique may be adopted before some standards get a chance to be used. 
> In line with my point #3, standards last longer than many current
> practices.  Will this be true in 2025?  What are 'certain reasons'?  I
> think this sentence would be better off as:
> 
[Lucy] We will revise the text. 

Thanks,
Lucy