Re: [mpls] Martin Stiemerling's Discuss on draft-ietf-mpls-rfc6374-udp-return-path-04: (with DISCUSS)

[Stewart Bryant <[e-mail]>]

On 13/01/2016 09:39, Martin Stiemerling wrote:
> Hi Steward,
>
> Am 06.01.16 um 18:10 schrieb Gmail:
>> Martin
>>
>> It is  a fundamental tenet of MPLS is that the network is well
>> managed with the operators paying significant attention to traffic
>> planning, I therefore think that it is reasonable to assume that they
>> would also pay adequate attention to their UDP management traffic.
>>
>> Loss is so light in these networks that the interval between loss
>> measurements needs to be long to see any loss at all, thus I would
>> normally expect us to be talking packets per minute or packets per
>> hour rather than packets per second, and this would be on links with
>> GB+ capacity. Similarly it makes little sense to make delay
>> measurements very frequently.
>>
>> In both cases the amount of traffic will be minuscule compared to the
>> IPFIX over UDP traffic that that many operators will already will
>> running.
>>
>> I thus fear that you raise the congestion daemon without proper
>> regard to the practicalities of this type of application.
>
> I fully understand that this type of protocol is used usually in a 
> fully managed network. But congestion can also happen there, and 
> congestion is by the way not a daemon, but a natural consequence of a 
> best effort network even if it is managed

Martin

If a basic monitoring protocol such as this, drives a network over the 
edge through congestion, then there is so much else wrong with that the 
network that it would be unable perform it primary mission. My concern 
is that by always highlighting congestion concerns, even when the risk 
is minor, you dilute the importance of the message when there is a real 
need for caution.

>
> And even in fully managed networks traffic can accumulate at one point 
> causing congestion.

Again, if this type of protocol pushes it over the edge, I would be 
concerned that there were much more significant issues with that network.

>
> I do not see the need to work through all details of RFC 5405, but I 
> want to see text that reflects about using an not congestion 
> controlled protocol and possible consequences and guidances for 
> operators using this.
> One way to handle this, to make operators aware of the need to monitor 
> the rate of UDP traffic and that any excess of this rate is worth 
> noting to the network operator.
>
> By the way, your argument above about the managed environment would 
> also make Section 5 superfluous, isn't it?

I will willingly delete section 5 if that is the consensus of the IESG.

The following text inserted as a new section between section 4 and 5 
will hopefully address your congestion concerns.

5. Congestion Considerations

This protocol MUST be run in accordance the guidance provided in 
[RFC5405]. As advised in  section 3.2.1 of RFC5405, operators that wish 
to run this protocol at rates in excess of one packet per three seconds 
need to ensure that the MPLS path being monitored and any IP path that 
may be used to carry the response are provisioned such that there is a 
negligible chance of this protocol causing congestion. Additionally, if 
a significant number of response packets are lost, the querier MUST 
reduce the sending rate to a point where there is a negligible chance 
that this protocol is contributing to network congestion. The operator 
should also take precautions that response packets do not leak out of 
the network domain being used and cause congestion elsewhere. If a 
default IP address is configured by the equipment vendor, this MUST be 
an address known to contain the response packet within the responder, 
such as the IPv4 localhost address [RFC5735] or the IPv6 loopback 
address [RFC4291]. A responder receiving a query specifying this as a 
return  address, and not being configured to expect such a return 
address*, SHOULD notify the operator in a suitably rate limited manner.

Add refs to RFC5405 (normative), RFC 5735 (informational) and RFC 4291 
(informational)


*Not part of RFC text - this might occur if the operator wanted a data 
collector co-located on the responder, so it's better to specifically 
allow it than have confusion as to whether it is allowed or not.

- StewarT



>>
>> Sent from my iPad
>>
>>> On 5 Jan 2016, at 21:47, Martin Stiemerling <[e-mail]>
>>> wrote:
>>>
>>> Martin Stiemerling has entered the following ballot position for
>>> draft-ietf-mpls-rfc6374-udp-return-path-04: Discuss
>>>
>>> When responding, please keep the subject line intact and reply to
>>> all email addresses included in the To and CC lines. (Feel free to
>>> cut this introductory paragraph, however.)
>>>
>>>
>>> Please refer to
>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for more
>>> information about IESG DISCUSS and COMMENT positions.
>>>
>>>
>>> The document, along with other ballot positions, can be found
>>> here:
>>> https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-udp-return-path/ 
>>>
>>>
>>>
>>>
>>>
>>>
> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>>
>>>
> I am in favour of publishing this document, but I have two major points
>>> that are not addressed in the document by now:
>>>
>>> 1) It is not clear for anybody what the expected size and sending
>>> frequency of such MPLS-PLDM over IP/UDP responses are. This will
>>> influence any measures an operator has to take in order to assure
>>> that there is no congestion caused by these messages. I can
>>> understand that this cannot be foreseen, but a few words
>>> considering this fact are excellent to have in the document.
>>>
>>> 2) This leads to my second point: the lack of any reference to RFC
>>> 5405 "Unicast UDP Usage Guidelines for Application Designers" and
>>> the content out of this RFC that is applicable for this draft.
>>> There is no discussion about this at all. Please note well that
>>> this is BCP 145.
>>>
>>> With regard to point 2): I can try to find some help from the
>>> transport area, in case you need help.
>>>
>>>
>>>
>>>
>>> _______________________________________________ mpls mailing list
>>> [e-mail] https://www.ietf.org/mailman/listinfo/mpls