Job,
I agree. We'll do that.
The objective of this doc is to let operators figure out the issue, have
monitoring capable of detecting its occurrence, and show how difficult it is to
prevent these from happening in the first place.
The charging thing is from an operator telling me that that's what he would try
to do. I'm perfectly fine removing it.
Regards,
Pierre.
Sent from my iPhone
On Jun 25, 2015, at 1:45 AM, Job Snijders <job(_at_)instituut(_dot_)net>
wrote:
On Thu, Jun 25, 2015 at 08:35:35AM +0900, Randy Bush wrote:
Is the last paragraph of 4.1 an IETF consensus position on how operators
might charge one another? It would be good to find a way to word this
that look more like statements of fact and less like charging advice.
darn hard as there are no facts there and it is first class lawyer
bait.
Indeed.
It might be better to remove this part:
"It is possible that the behavior of the neighboring AS causing the
unexpected traffic flows opposes the peering agreement. In this case,
an operator could account the amount of traffic that has been subject to
the unexpected flows, using traffic measurement protocols such as IPFIX,
and charge the peer for that traffic. That is, the operator can claim
that it has been a provider of that peer for the traffic that transited
between the two ASes."
Instead something like:
"It is possible that the behavior of the neighboring AS causing the
unexpected traffic flows violates a contractual agreement between the
two networks."
And just leave it at that. It is worth noting that, although from a
technical perspective it is not always trivial to proactively prevent
these types of traffic flows, you could try and capture your intentions
in a contract and deal with fallout as said contract prescribed.
Kind regards,
Job
_______________________________________________
GROW mailing list
GROW(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/grow