RE: Stephen Farrell's No Objection on draft-ietf-rtgwg-mrt-frr-architecture-09: (with COMMENT)

[Chris Bowers <[e-mail]>]

Stephen,

Thanks for the feedback.  Responses are inline below with [CB].

They are incorporate in this latest version.
https://tools.ietf.org/html/draft-ietf-rtgwg-mrt-frr-architecture-10
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-mrt-frr-architecture-10

Thanks,
Chris


-----Original Message-----
From: Stephen Farrell [mailto:[e-mail]] 
Sent: Thursday, February 04, 2016 5:44 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; Janos Farkas <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Stephen Farrell's No Objection on draft-ietf-rtgwg-mrt-frr-architecture-09: (with COMMENT)

Stephen Farrell has entered the following ballot position for
draft-ietf-rtgwg-mrt-frr-architecture-09: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mrt-frr-architecture/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- abstract: "IP/LDP" is a bit ambiguous - it could be read as "IP over LDP," "IP and LDP" or "IP or LDP" not all of which make sense I guess:-) Be better if the abstract said "IP and LDP" I think.
===========
[CB]  Changed abstract to "IP and LDP"

========
- section 3: the definitions are very dense - would re-ordering them help maybe? Not sure myself, but maybe think about it.
==========
[CB]  I actually reordered them between -08 and -09.  Current order tries to build up from basic graph theory terminology, then terminology about MRTs , then terminology related to calculating MRTs using other constructs like GADAGs, then terminology related to computing paths for destinations outside of an MRT island.

==========

- Section 8: with so many parameters, why choose an 8-bit profile ID? That seems to be a bit short-sighted maybe? 
========
[CB] 8-bits seems like a reasonable starting place.  I think it is unlikely that we will exhaust this 8-bit space.  However, if we get to the point where we are creating a large number of profiles based on different combinations of the parameters that make up an MRT profile, I think we would do better to assign standard values to each of the profile parameters, and have routers advertise one or more sets of profile parameters.  We would then require that all of the profile parameter values to match in order for the two routers to be in the same MRT island.  At that point, we would actually understand what is needed based on deployment experience. 

========
- 12.2: The sequence presented here has the look of something that might be a potential DoS vector, but maybe the computation isn't that significant, not sure.  Did you consider a potential attack where the bad actor takes down then re-instates one or more links so as to increase the computation to the max? (Perhaps you did and the max is still not a big deal.)
===========
[CB]  We estimate the computation for MRT to be roughly 3 times that of a standard SPF.  In current deployments using LFA and Remote LFA, there are quite a lot more SPFs being done, so I don't think this is a concern. 
===========

- As noted by the secdir review [1] this is highly acronym laden. I'd encourage an editing pass to try reduce that where possible. I'll also bet a beer that not every acronym used is either expanded or else present in the list of "well known"
acronyms (which is of course pretty outdated). 

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06344.html
============
[CB]  OK. You win.  I found and expanded four.  
SPF
LFA
FIB
OAM
============