Early Review of draft-ietf-mpls-flow-ident-02

Request Review of draft-ietf-mpls-flow-ident-02
Requested rev. 02 (document currently at 06)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2017-03-06
Requested 2017-01-22
Requested by Loa Andersson
Other Reviews Rtgdir Last Call review of -05 by Manav Bhatia (diff)
Secdir Last Call review of -06 by Daniel Franke
Document is currently in wglc, which ends Feb 6, if a reviewer needs a few extra days that is fine, but the wg chairs would need to know.
PS - I sent a mail also
Review State Completed
Reviewer Manav Bhatia
Review review-ietf-mpls-flow-ident-02-rtgdir-early-bhatia-2017-02-02
Posted at https://mailarchive.ietf.org/arch/msg/rtg-dir/xQNUfEwR7CcpjKmiHj7Uve3Abbs
Reviewed rev. 02 (document currently at 06)
Review result Has Nits
Draft last updated 2017-02-02
Review completed: 2017-02-02


Dear Authors,

I have been asked to do Routing Area Directorate QA review
of draft-ietf-mpls-flow-ident-02


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

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