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

[Xuxiaohu <[e-mail]>]

> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]] 代表
> Xuxiaohu
> 发送时间: 2013年11月1日 14:24
> 收件人: Carlos Pignataro (cpignata); Adrian Farrel
> 抄送: [e-mail]; distinguished MPLS chairs;
> [e-mail]
> 主题: [mpls] 答复: AD review of draft-ietf-mpls-in-udp
> 
> 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."

s/by using some fields in the encapsulation headers/by using some special field in the encapsulation header as an entropy field/

Xiaohu

> [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.
> 
> 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
> > >
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls