Re: [RTG-DIR] QA review of draft-ietf-mpls-flow-ident-02

[Stewart Bryant <[e-mail]>]

Manav

Thank you for your review comments.

I have uploaded version 4.


On 01/02/2017 17:12, Manav Bhatia wrote:
>
> Dear Authors,
>
>
> I have been asked to do Routing Area Directorate QA review 
> of draft-ietf-mpls-flow-ident-02
>
>
> Summary:
>
>
> Its an informational draft that discusses “desired capabilities for 
> MPLS flow identification”. I am not sure what this means — is this 
> alluding to the capabilities on the routers, or some protocol? I think 
> the authors meant to discuss the aspects that must be considered when 
> developing a solution for MPLS flow identification. However, it takes 
> quite a bit of reading to get there.
>

I used your words

>
> I found the document quite hard to parse initially. After a couple of 
> passes, it became somewhat better and I could understand the points 
> that the authors were trying to make. I have no concerns on the 
> technical content.
>
>
> Major Comments:
>
>
> Please work on the readability aspects of the draft.
>

I am obviously not the right person to do that. I just re-read it after 
a long time, and I could understand it. I am not entirely sure how to 
address your comment, without further details. Maybe this is a 
discussion to have with Deborah when she sees the draft?

>
> Minor Comments:
>
>
> 1. Section  3 - I would resist the urge to make a sweeping statement 
> that packets dont get dropped in “modern networks” unless the network 
> is oversubscribed. I work for a large vendor and I see packets 
> dropping all the time.
>

This now says*:
*
Modern networks, if not oversubscribed, potentially drop relatively few
packets, thus packet loss measurement is highly sensitive to the
common demarcation of the exact set of packets to be measured for loss.
>
>
> 2. Section 3 - What is a counter error?
>

See above

>
> 3. Section 3 - “Thus where accuracy better than the data link loss 
> performance of a modern optical network is required, it may be 
> economically advantageous ..”. I had a very hard time trying to parse 
> this.
>

This now says:

Thus where accurate measurement of packet loss is required,
it may be economically advantageous, or even a technical requirement, to
include some form of marking in the packets to assign each packet to
a particular counter for loss measurement purposes.

To fully understand the text the reader should look at the reference.

>
> 4. Section 4 - “Also, for injected test packets, these may not be 
> co-routed with the data traffic due to ECMP”. Also include LAG and 
> MC-LAG. Additionally the data path for the test traffic could be 
> different from the regular IP traffic.
>
This now says:

Also, for injected test packets, these may not be co-routed
with the data traffic due to ECMP, or various link aggregation technologies
all of which distribute flows across a number of paths at the
network, or data-link and hence at the physical layer.
>
>
> 5. Section 5 - “Such fine grained resolution may be possible by deep 
> packet inspection, .. “. How can you do deep packet inspection at the 
> LSR.
>
> How will you know the label stack size in the packet?
>

Er, we get past the label stack all the time to do 5 tuple load 
balancing which is the standard method of at least one major vendor.

The S bit is set at BoS!

> I am not sure if the LSR needs to deep inspect these packets?
>

So how else do you identify a flow? Of course your view of "deep" may 
vary, but inspecting to the depth of the transport layer port number is 
standard.

> But based on text in Sec 8, LSRs appear to be processing these packets.
>

I am not sure I understand the point here.

- Stewart

>
> Cheers, Manav
>