Re: [mpls] AD review of draft-ietf-mpls-in-udp

["Carlos Pignataro (cpignata)" <[e-mail]>]

Xiaohu,

On Nov 1, 2013, at 2:23 AM, Xuxiaohu <[e-mail]> wrote:

> Hi Carlos,
> 
>> -----邮件原件-----
>> 发件人: Carlos Pignataro (cpignata) [mailto:[e-mail]]
>> 发送时间: 2013年11月1日 1:53
>> 收件人: Adrian Farrel
>> 抄送: Xuxiaohu; [e-mail]; distinguished MPLS chairs;
>> [e-mail]
>> 主题: Re: AD review of draft-ietf-mpls-in-udp
>> 
>> Hi,
>> 
>> On Oct 16, 2013, at 12:14 PM, Adrian Farrel <[e-mail]> wrote:
>> 
>>> Hello,
>>> 
>>> Just cutting down to the conversation...
>>> 
>>>>> Abstract
>>> [snip]
>>>>> "...applicable in some circumstances" says nothing, of course.
>>>>> Either don't say this, or explicitly state the circumstance. Since
>>>>> (see below) the applicability is very specific and there is a clear
>>>>> use case that is the target of your work, I strongly suggest that
>>>>> you call out this case in the Abstract.
>>>> 
>>>> Is it ok for you if the above sentence is changed to"... applicable
>>>> in some circumstances where IP-based encapsulation for MPLS is
>>>> required and fine- grained load-balancing of IP tunneled MPLS packets is
>> required as well..."?
>>> Or can
>>>> you suggest any text on this point?
>>> 
>>> That helps a lot.
>>> Thanks.
>> 
>> I do not think adding the proposed text is the best fix. Saying "circumstances
>> where IP-based encapsulation for MPLS is required and fine-grained
>> load-balancing of IP tunneled MPLS packets is required as well" implies
>> potentially that existing IP-based encapsulation for MPLS are not appropriate
>> for fine-grained load-balancing of IP tunneled MPLS packets, and that's not
>> necessarily the case, since fields in other encapsulations can be used (and are
>> used) for that (e.g., GRE Key, L2TPv3 Session ID).
> 
>> Also, this proposal contradicts your (Adrian's) point below about the inability to
>> know what's encapsulated in MPLS (the proposed text says "of IP tunneled
>> MPLS packets").
> 
> I have changed it to "load-balancing of MPLS packet over IP networks".
> 
>> Additionally, please note that RFC 4023 says in the abstract "Each of these is
>> applicable in some circumstances." which sets the expectation that it will be
>> answered in the doc as applicability.
>> 
>> I'd propose just removing the "...applicable in some circumstances" or be even
>> more specific about the applicability.
> 
> The abstract is changed to: 
> 
> "This document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP (User Datagram Protocol), which is applicable in some circumstances where IP-based encapsulation for MPLS is required and further fine-grained load-balancing of MPLS packets over IP networks is required as well. Although other IP-based encapsulations for MPLS can improve the load-balancing as well by using some fields in the encapsulation headers, one major benefit of MPLS-in-UDP comparing to other IP-based encapsulations for MPLS is that the former can improve the load-balancing without any requirement on the core of the IP networks."

I do not think this is accurate either. It does most definitely impose requirements on core routers. Those requirements include the use of UDP ports in the hash function for ECMP. I believe what you are trying to say is that every IP router and every IP network already does this for UDP ports without any penalty, but not for GRE Keys or for the IPv6 flow label field. I'm not sure how to best approach this in the absence of any pointer that would substantiate the statement. Do you know of any paper that studies this? Perhaps one approach is to be explicit about the assumptions.

> 
> [snip]
> 
>>> If I am correct and it is never appropriate, it would be better to say that
>>> "using zero checksum is NOT RECOMMENDED because of..."   and then point
>> to the
>>> text you quoted.
>>> 
>>> if I am incorrect then please discuss with me further.
>> 
>> A further point that does not imply you are incorrect, but I will note that other
>> MPLS-in-IP encapsulations do not have a checksum in the transport, and
>> perhaps that's what needs to be added to the document.
> 
> I have added "... note that other MPLS-in-IP encapsulations do not have a checksum in the transport header..." to the doc.
> 

Ack.

Thanks,

Carlos.

> Best regards,
> Xiaohu
> 
>> Thanks,
>> 
>> -- Carlos.
>> 
>>> 
>>>>> Section 4
>>>>> 
>>>>>  As for other common processing procedures associated with tunneling
>>>>>  encapsulation technologies including but not limited to Maximum
>>>>>  Transmission Unit (MTU) and preventing fragmentation and reassembly,
>>>>>  Time to Live (TTL) and differentiated services, the corresponding
>>>>>  "Common Procedures" defined in [RFC4023] which are applicable for
>>>>>  MPLS-in-IP and MPLS-in-GRE encapsulation formats SHOULD be
>> followed.
>>>>> 
>>>>> I think it is probably important to consider PMTU in the presence of
>>>>> ECMP (probably not necessary in the case of LAG). How does the
>>>>> source know the PMTU for each different value of the source port
>>>>> that it might apply?
>>>> 
>>>> IMHO, it is a common issue for any load-balancing mechanism. Would it
>>>> be
>>> better
>>>> to write a separate doc to address this common issue?
>>> 
>>> That is a really good question.
>>> I think discovering PMTU is technology dependent, but the general
>>> issue of discovery in ECMP doesn't appear to be well discussed.
>>> 
>>>>> As far as I can see Section 5 is not ECN-friendly and says that when
>>>>> the payload protocol of the MPLS packet is not "TCP-friendly" the
>>>>> application generating the packets must use magic to avoid swamping
>>>>> the network.
>>>>> 
>>>>> We will see what the TSV area congestion experts have to say, but I
>>>>> think we will find that the approach here is simplistic unless the
>>>>> network across which the UDP tunnel runs is used for no other
>>>>> traffic except UDP tunnels carrying MPLS packets.
>>>> 
>>>> We originally just intented to mention this issue to the same extent
>>>> as MPLS
>>> over
>>>> L2TPv3 [rfc4817]. BTW, it seems that MPLS in IP or GRE [RFC4023]
>>>> doesn't mention this point at all. We would like to see what the TSV
>>>> area congestion experts have to say as well on this point.
>>> 
>>> Yeah, this is fine. I am not an expert in this stuff and we will need
>>> their opinions. Perhaps they won't say anything :-)
>>> 
>>>>> Section 6 seems to indicate a major draw-back of this scheme. You
>>>>> have to note that MPLS networks are able to get away with having
>>>>> very little security because it is very hard to inject MPLS packets into a
>> network.
>>>>> But MPLS-in-(foo-in-)IP encapsulation provides a way to inject
>>>>> packets just like any packet can be injected into an IP network.
>>>> 
>>>> Sure. It's the same issue with any other IP-based encapsulations for MPLS.
>>> 
>>> Indeed, hence my point about security, below...
>>> 
>>>>> Security (such as IPsec) provides a way to ensure that rogue packets
>>>>> do not have their headers stripped and their payload MPLS packets
>>>>> added to an LSP.
>>>> 
>>>>> You are making a clear statement that using IPsec means that there
>>>>> is no point in doing MPLS-in-UDP encapsulation. You need to follow up on
>> this!
>>>>> 
>>>>> The first thing to do is to enhance the applicability text in
>>>>> Section 1 to say where you would deploy this such that security is not an
>> issue.
>>>> 
>>>>> The second thing is to talk about the security mechanisms that can
>>>>> be applied at the edges of the network to reduce the likelihood of
>>>>> such attacks being possible.
>>>>> 
>>>>> Lastly (or probably firstly!) you need to describe the attack vector
>>>>> and the implications of such an attack so that the
>>>>> implementer/deployer is clear what the risks are.
>>>> 
>>>> Will fix it.
>>> 
>>> OK. I also wonder whether you looked at DTLS.
>>> 
>>> Thanks for all the work.
>>> 
>>> Adrian
>>> 
>