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

From: Manav Bhatia <[email-masked]>
Date: Wed, 1 Feb 2017 22:42:24 +0530

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 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.

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.

2. Section 3 - What is a counter error?

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.

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.

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? I am not sure if the LSR
needs to deep inspect these packets? But based on text in Sec 8, LSRs
appear to be processing these packets.

Cheers, Manav

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 24 Feb 2017 20:08:54 +0000

Manav

Thank you for your review comments.

I have uploaded version 4.

On 01/02/2017 17:12, Manav Bhatia wrote:
> 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

> 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:
>
>

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

> 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