Re: [mpls] Martin Duke's No Objection on draft-ietf-mpls-rfc6374-sfl-09: (with COMMENT)

[Stewart Bryant <[e-mail]>]

Thank you for the review Martin.

> On 24 Feb 2021, at 17:50, Martin Duke via Datatracker <[e-mail]> wrote:
> 
> Martin Duke has entered the following ballot position for
> draft-ietf-mpls-rfc6374-sfl-09: No Objection
> 
> 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-sfl/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> - In Section 6, I understand the intent of #5 ("The duration of a second delay
> (D in Figure 1 batch must be such
>       that all packets from the packets belonging to a first delay
>       batch (C in Figure 1)will have been received before the second
>       delay batch completes.")
> 
> But given that this is a delay measurement, how can we ensure this property? Is
> this better formulated as "the sender will not stop sending for D until it
> receives feedback for C", or something to that effect?

This is the so called coloured marking scheme invented by Telecom Italia quite a number of years ago and now an RFC.

You set up red and blue packet counters.

You colour a group of packets red, the receiver will count red packets and blue packets but there are no blue packets to count yet.

Then at some time later you change the color to blue. The receiver counts the stray red packets and also the blue packets. This allows the system to cope with the effects of ECMP and to avoid the difficulty of synchronisation at these timescales.

Some time later the sender stops sending blue and reverts to red packets etc.

So long as the duration of batch is long compared to likely delays in the network and the router line card to measurement co-ordinator (tuned by operational experience) the scheme works nicely and deals with what previously had been an impossible problem.

Remember this needs to scale to circa 10^9 pps with receivers co-ordinated between different line cards on the receiving router and with an expected packet loss of less than 1 packet in several minutes.

I believe that the text is correct as it stands.

This ID is about applying the technology in a slightly different environment.

> 
> - Sec 9.1: What does it mean that SPL Index is an "optional convenience"? Is
> the sender required to set it properly, but the receiver is free to ignore it
> if unneeded? Or is this optional for the sender somehow as well?
> 

It is assumed that the use of this feature is agreed between the two parties during configuration. It is not required, but is a convenience for the receiver if both parties support the facility,

Best regards

Stewart

> 
>