[RTG-DIR] Rtgdir early review of draft-ietf-mpls-rmr-09

[Susan Hares <[e-mail]>]

Reviewer: Susan Hares
Review result: Not Ready

This is a routing directorate review.  As such, it should be considered the
same as other later WG LC review.

overall-comment: Well-written and an exciting new direction.  I appreciate
Kireeti and Luis work on this topic.

major concerns:
1) security (section 8),
2) long-term stability of architecture discussion,
3) FRR/Protection sections (3.6/3.7), and
4) amount of traffic that auto-discovery will place on the network.

caveat:  I have not been an WG participant for these discussions.   As such, I
am a "fresh" pair of eyes to read the current specification.

Major concerns
=======

1) Section 8 - Security considerations.

"This section states 'It is not anticipated that either the notion of MPLS rings
or the extensions to various protocols to support them will cause security
loopholes."

This statement provides an opinion of the authors without any reasoning behind
it.  As such, it provide no utility to the reader.  Inquiring minds would like
to know "why" the authors feel this true and on what basis.   Launching a new
type of structure within the MPLS cloud that auto-configures it self with a
great deal of message exchange does not appear to have these qualities. 
Surely, these authors have considered or tried these issues.

2) Long-term stability of document - in the face of repeated statements of a
future version of this document.

If this is just an interim document, then why is it being standardized.  In a
specification that is going to include an RFC track, the sttaements of scope
seem inappropriate in sections 1, 3.3, 4.5,  5, 7.1, and 7.2).  This scope
should be gathered to a particular place and stated in another.

I agree with the concept of deployment and then refinement of the protocol
mechanisms.  However, this document seems to anticipate quick refinement of the
basic architeture.  If this is really true, then why is this document going ot 
the IESG.  If this is not true, then the scoping in above sections needs to be
refined.

3)  Fast re-routing installation puts details (3.6) before concepts of
protection. Only after I read section 3.7, did section 3.6 start to make sense.
  If you re-ordered the sections, perhaps you could provide additonal depth to
section 3.6.

4) paragraph 4.3, last sentence  "The nodes that set their M bit should be
extra careful in advertising their M Bit in subsequent tries".

As an engineering, I find this description to avoid many of the problems about
how long the bidding for master will take.  Is there a potential for the
bidding to repeat over and over.  If so, how does the operator detect it.  Can
something drop the nodes into membership phase or re-identification phase
repeated?   While the ring announcement and ring identification cycle become a
denial-of-service attack on the IGPs announcing the information?  I suspect the
authors have investigated these points, but the architeture document is the
place to indicate why the architecture prevents these problems.

As an editor, I find the anthropomorphism to be unwarranted in the text.  While
it took me to flights of fantasy where the nodes became intelligent silicon
life forms, I suspect that is not what the authors wanted.   Perhaps after
clarifying the engineering point, the authors can rewrite the sense of the text.

brief editorial nits:

1) page 4, node index linke
/upto/ to /up to/

2) page 5 (Q_jk): - not define earlier, please define it.

3) page 5, section 3 paragraph 2, sentence file

sentence:
current: /The default is to send traffic along the shortest path./
new:  /The default policy is to send traffic along the shortest path./

4) page 6, section 3.3 sentences 2

current:/ The last attribute means/
new: /The "auto-bundled" attribute means/

While the authors first formi is current, the change makes a specification
clear.

5) page 3.5 - please spell out the first use of UHP
6) section 3.6/3.7 - could use a diagram.
7) page 11, section 4.3, paragraph 2, sentence 2 (spelling) -

old/exaclty one;/
new/exactly one/