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

[Xuxiaohu <[e-mail]>]

Hi Eric,

> -----邮件原件-----
> 发件人: Eric Osborne (eosborne) [mailto:[e-mail]]
> 发送时间: 2012年11月28日 23:53
> 收件人: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> 抄送: [e-mail]
> 主题: 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.
> 
> 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.

This section has been simplified greatly in the -04 version according to your above comment. Please check whether it's OK now.

> #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.

Fixed.

> #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.

The draft is just intended to address the current problems. If load balancing based on the GRE key becomes a default capability of most core routers in the future, this draft can be discarded if necessary. Anyway, the market will make its wise choice according to the practical conditions.

> #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.

To avoid endless arguments on whether MPLS-based VPN technologies are applicable within data centers, another use case of transporting MPLS traffic across IP networks is described in the revision. That is: MPLS-based L2VPN or L3VPN technologies may be used for interconnecting geographically dispersed enterprise data centers or branch offices across IP Wide Area Networks (WAN) where enterprise own router devices are deployed as L2VPN or L3VPN PE routers. 

Please check whether all of your above comments have been well addressed in the -04 version. Many thanks.

Best regards,
Xiaohu

> 
> 
> eric