Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

[<[e-mail]>]

Lars has primarily vigorously commented on congestion, not checksums.

RFC6935 is standards track, for convenience of tunnel implementers.
RFC6936 is standards track, filled with indications of the dire things that
happen when you follow RFC6935.

I'm fine with SHOULD implement checksums. Checksums are
RECOMMENDED. Leaving off UDP checksums for tunnel implementation
reasons(performance, not seeing whole packets) in private networks is an
exception that needs to be explicitly called out.


Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Curtis Villamizar [[e-mail]]
Sent: 24 January 2014 04:25
To: Wood L  Dr (Electronic Eng)
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

In message <[e-mail]>
[e-mail] writes:

> RFC6935 was written from a tunnelling perspective, to allow tunnelling
> to use zero checksums for performance, and analysed risks to the
> tunnel traffic - but not to other users.
>
>    "While the methods do
>    not guarantee correctness, they can reduce the risks of relaxing the
>    UDP checksum requirement for a tunnel application using IPv6."
>
> Risks to other applications are not assessed, and not stated.
>
> Lloyd Wood
> http://about.me/lloydwood


Help me out here Lloyd.  Previously on this thread Lars was vigorously
arguing that we needed to follow years of IETF consensus about UDP
checksums.

Do you disagree with Lars on that point about following IETF consensus
or are you saying there was no IETF consensus in this particular RFC.

[ Life if tough for people who try to deal in absolutes. ]

In any case, both UDP checksums and congestion control are SHOULD in
various document with conflicting SHOULD and SHOULD NOT some cases.
We have met the criteria for not going along with SHOULD with a very
tight applicability statement establishing a extroidinary circumstance
and that the decision and consequences have been thought about.

Could we *please* review proposed wording changes (on list).

Curtis



> ________________________________________
> From: Xuxiaohu [[e-mail]]
> Sent: 24 January 2014 00:34
> To: Wood L  Dr (Electronic Eng); [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: ´ð¸´: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
>
> It seems that you are against RFC6935 and RFC6936, right?
>
> Xiaohu
>
> > -----ÓʼþÔ­¼þ-----
> > ·¢¼þÈË: [e-mail] [mailto:[e-mail]]
> > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ24ÈÕ 1:18
> > ÊÕ¼þÈË: Xuxiaohu; [e-mail]; [e-mail]
> > ³­ËÍ: [e-mail]; [e-mail]
> > Ö÷Ìâ: RE: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS
> > in UDP) to Proposed Standard
> >
> > the text is not satisfactory. never recommend setting to zero, as that poses a risk
> > to your and to other traffic. Suggested text:
> > ***
> > The UDP checksum SHOULD be used to protect the payload and ensure correct
> > demultiplexing and delivery to the tunnel, and not to other UDP destinations, by
> > protecting the UDP pseudoheader.
> > Use of a zero UDP checksum is NOT RECOMMENDED, even when desired for
> > performance or necessitated by implementation reasons, for the reasons
> > outlined in [RFC6936] section 3.
> >
> > UDP-Lite [RFC3828] can provide a demultiplexing check and MPLS stack
> > integrity check while avoiding the overhead of computing an integrity check
> > over a tunnelled frame that has its own integrity check.
> > ***
> >
> > Lloyd Wood
> > http://about.me/lloydwood
> > ________________________________________
> > From: Xuxiaohu [[e-mail]]
> > Sent: 23 January 2014 12:35
> > To: Wood L  Dr (Electronic Eng); [e-mail];
> > [e-mail]
> > Cc: [e-mail]; [e-mail]
> > Subject: re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS
> > in UDP) to Proposed Standard
> >
> > > -----ÓʼþÔ­¼þ-----
> > > ·¢¼þÈË: [e-mail] [mailto:[e-mail]]
> > > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ23ÈÕ 12:44
> > > ÊÕ¼þÈË: Xuxiaohu; [e-mail]; [e-mail]
> > > ³­ËÍ: [e-mail]; [e-mail]
> > > Ö÷Ìâ: RE: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt>
> > > (Encapsulating MPLS in UDP) to Proposed Standard
> > >
> > > Sasha
> > >
> > > > - UDP checksums (or lack thereof) is a non-issue because native MPLS
> > > > does not have anything like that. And yes, there are cases where
> > > > packets are corrupted within the routers)
> > >
> > > So you admit that packets can be corrupted within the routers - a
> > > check that can only be caught by an end-to-end check, a corruption
> > > that can lead to the problems detailed in RFC 6936 section 3 - and
> > > then you say it's a non-issue because this doesn't affect native MPLS. But we're
> > not doing native MPLS here.
> > > We're doing MPLS over UDP.
> > >
> > > draft-ietf-mpls-in-udp-04.txt is about tunnelling MPLS in UDP. It's an issue.
> > > Please read the other 150 messages that you refer to.
> >
> > Hi Lloyd,
> >
> > The draft doesn't require the IPv6 UDP checksum to be set to zero regardless.
> > See the following text quoted from that draft:
> >
> > UDP Checksum
> >
> > The usage of this field is in accordance with the current UDP specification
> > [RFC768]. To simplify the operation on the decapsulator, this field is
> > RECOMMENDED to be set to zero in IPv4 UDP encapsulation case. In the IPv6
> > UDP encapsulation case, if appropriate according to the requirements defined in
> > [RFC6935] [RFC6936], this field is also RECOMMENDED to be set to zero.
> > Specifically, if the MPLS payload is Internet Protocol (IPv4 or IPv6) packets, it is
> > RECOMMENDED to be set to zero when the inner packet integrity checks is
> > available. In addition, if the MPLS payload is non-IP packet which is specifically
> > designed for transmission over a lower layer that does not provide a packet
> > integrity guarantee, it is RECOMMENDED to be set to zero as well. Otherwise,
> > using zero checksum is NOT RECOMMENDED. Note that other IP encapsulations
> > for MPLS do not have a checksum in the tunnel header.
> >
> > If you still believe the above text is not satisfactory, please provide your text.
> >
> > Best regards,
> > Xiaohu
> >
> > > Lloyd Wood
> > > http://about.me/lloydwood
> > > ________________________________________
> > > From: mpls [[e-mail]] On Behalf Of Xuxiaohu
> > > [[e-mail]]
> > > Sent: 23 January 2014 03:16
> > > To: Alexander Vainshtein; Eggert, Lars
> > > Cc: Joel Jaeggli; [e-mail]
> > > Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt>
> > > (Encapsulating MPLS in UDP) to Proposed Standard
> > >
> > > Hi
> > >
> > > > -----ÓʼþÔ­¼þ-----
> > > > ·¢¼þÈË: Alexander Vainshtein [mailto:[e-mail]]
> > > > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ22ÈÕ 19:05
> > > > ÊÕ¼þÈË: Eggert, Lars
> > > > ³­ËÍ: Joel Jaeggli; [e-mail]; Xuxiaohu
> > > > Ö÷Ìâ: RE: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt>
> > > > (Encapsulating MPLS in UDP) to Proposed Standard
> > > >
> > > > Lars and all,
> > > > Last time I've counted the IETF LC thread on this draft has more
> > > > than
> > > > 150 messages in it, and it seems that on some issues (congestion
> > > > control and UDP
> > > > checksums) we are going round the mulberry bush.
> > > >
> > > > IMHO and FWIW:
> > > > - UDP checksums (or lack thereof) is a non-issue because native MPLS
> > > > does not have anything like that. And yes, there are cases where
> > > > packets are corrupted within the routers), but so far it did not
> > > > prevent MPLS deployment. There is, e.g., RFC 4720 for FCS retention
> > > > in PWs, but I doubt it is widely implemented and deployed (would be
> > > > nice to
> > > know).
> > > > - E2E congestion control (regardless of its implications) simply
> > > > cannot be added to this protocol without some major changes. A short
> > > > applicability statement explaining that should suffice IMO.
> > >
> > > Hi Sasha,
> > >
> > > I fully agree with your points.
> > >
> > > Best regards,
> > > Xiaohu
> > >
> > > > My 2c,
> > > >        Sasha
> > > > Email: [e-mail]
> > > > Mobile: [phone]
> > > >
> > > > > -----Original Message-----
> > > > > From: mpls [mailto:[e-mail]] On Behalf Of Eggert,
> > > > > Lars
> > > > > Sent: Wednesday, January 22, 2014 12:23 PM
> > > > > To: Xuxiaohu
> > > > > Cc: Joel Jaeggli; [e-mail]
> > > > > Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt>
> > > > > (Encapsulating MPLS in UDP) to Proposed Standard
> > > > >
> > > > > Hi,
> > > > >
> > > > > On 2014-1-22, at 11:12, Xuxiaohu <[e-mail]> wrote:
> > > > > > I wonder whether the following text is OK to you:
> > > > > >
> > > > > > Since the MPLS-in-UDP encapsulation causes MPLS packets to be
> > > > > forwarded through "UDP tunnels", the congestion control guidelines
> > > > > for UDP tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be
> > > followed.
> > > > > Specifically, MPLS can carry a number of different protocols as payloads.
> > > > > When an UDP tunnel is used for MPLS payload traffic that is known
> > > > > at configuration time to be IP-based and congestion-controlled,
> > > > > the UDP tunnel SHOULD NOT employ its own congestion control
> > > > > mechanism, because congestion losses of tunneled traffic will
> > > > > trigger an congestion response at the original senders of the tunneled
> > traffic.
> > > > > When an UDP tunnel is used for MPLS payload traffic that is known
> > > > > at configuration time not to be IP-based and
> > > > > congestion-controlled, the UDP tunnel SHOULD employ an appropriate
> > > > > congestion control mechanism as described in [RFC3985]. Note that
> > > > > it STRONGLY RECOMMENDED to deploy such encapsulation technology
> > > > > only within a SP network or networks of an adjacent set of
> > > > > co-operating SPs, rather than over the
> > > Internet.
> > > > > Furthermore, packet filters should be added to block traffic with
> > > > > the UDP port number for MPLS over UDP to prevent MPLS over UDP
> > > > > packets to escape from the service provider networks due to
> > > > > misconfiguation or packet
> > > > errors.
> > > > >
> > > > > I think it would be better to describe the OAM control loop in
> > > > > (some) more detail, rather than pointing to RFC3985, which doesn't
> > > > > have a whole lot of detail either. Also because the adding of
> > > > > firewall rules requires an OAM hook.
> > > > >
> > > > > Since STRONGLY RECOMMENDED is not an RFC2119 term and
> > > > RECOMMENDED is
> > > > > too weak, I'd suggest to change this to MUST.
> > > > >
> > > > > Finally, the applicability statement should be prominently made in
> > > > > the abstract, introduction, etc.
> > > > >
> > > > > Lars