[email protected]
[Top] [All Lists]

comments on IPFRR drafts

Subject: comments on IPFRR drafts
From: Pekka Savola
Date: Wed, 3 May 2006 10:49:30 +0300 EEST
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
[email protected]
https://www1.ietf.org/mailman/listinfo/rtgwg

<Prev in Thread] Current Thread [Next in Thread>
  • comments on IPFRR drafts, Pekka Savola <=