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

[Manav Bhatia <[e-mail]>]

Hi,

The new draft looks good. It will help to work with the RFC-editor team to
rewrite some parts of the draft to make it clearer.

Thanks, Manav

On Sat, Feb 25, 2017 at 1:38 AM, Stewart Bryant <[e-mail]>
wrote:

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