comments on IPFRR drafts

[Pekka Savola <[e-mail]>]

I draft-ietf-ipfrr-spec-framework-05.txt, but I don't have anything to 
comment except that maybe [MICROLOOP] reference should be 
draft-ietf-rtgwg-microloop-analysis-01.txt instead of 
draft-bryant-shand-lf-conv-frmwk-02.txt.

I also read draft-ietf-ipfrr-spec-base-05.  It looked rather good, but there
seemed to be some omissions that should probably be addressed.

substantial
-----------

==> this document only mentions IS-IS and OSPF(v2).  Is it directly
applicable without any mods to OSPFv3 as well?  If so, refer to it as well;
if not, describe the differences.  I'm assuming IPv6 for IS-IS should work
without any issues as well.

Further than that, it seems that additional words are possibly needed about
multi-topology IS-IS (and maybe the multi-topology OSPF)?  I'm assuming the
regular OSPF/IS-IS TE extensions work without problems?


    This specification defines a form of SRLG protection limited to those
    SRLGs that include a link that the calculating router is directly
    connected to.  Information about local link SRLG membership is
    manually configured.  Information about remote link SRLG membership
    is dynamically obtained using [RFC4205] or [RFC4203].

==> the last sentence seems a bit assumptive.  Is it assumed that to be able
to use _IP_FRR with SRLG, you'll need to deploy GMPLS and TE extensions for
your IGP?  Maybe more leeway is needed here (e.g., the above references are
just examples of remote SRLG information sources).

Btw, is it feasible to use RFC4205 or RFC4203 on non-GPMLS, non-IGP-TE networks
in any case?  Are there alternatives?

7.  Security Considerations

    The mechanism described in this document does not modify any routing
    protocol messages, and hence no new threats related to packet
    modifications or replay attacks are introduced.  Traffic to certain
    destinations can be temporarily routed via next-hop routers that
    would not be used with the same topology change if this mechanism
    wasn't employed.  However, these next-hop routers can be used anyway
    when a different topological change occurs, and hence this can't be
    viewed as a new security threat.

==> Do the LDP usage case requirements set down by this spec cause security
considerations (they certainly cause propagation of information throughout
the domain)?  Maybe this needs a brief mention here, and possibly
appropriate pointers if these modes have been adequately described in an LDP
spec.


editorial
---------

       P_i.alt_next_hops = {}
       P_i.alt_type = NONE P_i.alt_link-protect = FALSE
       P_i.alt_node-protect = FALSE

==> the middle line should probably be split to two lines..

    It is possible to provide ASBR protection if BGP selected selected a
    set of IGP next-hops and allowed the IGP to determine the primary and

==> remove one "selected".

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Rtgwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rtgwg