Re: comments on IPFRR drafts

[Alex Zinin <[e-mail]>]

Pekka,

Thanks a lot for reviewing the documents!

> 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.

Yes, neither OSPFv3 nor IS-IS for v6 should require any special provisions,
as next-hop calculations are the same.

> Further than that, it seems that additional words are possibly needed about
> multi-topology IS-IS (and maybe the multi-topology OSPF)?

Unless someone would like to suggest actual text, I wouldn't go after this
as an important goal. We can always address this in a separate document.

> I'm assuming the
> regular OSPF/IS-IS TE extensions work without problems?

Yes, they are not affected by the FRR.


>     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).

We can say "may be obtained".

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

There's nothing that stipulates that GMPLS extensions can't be used in a
pure-IP network. It's a question of enabling the announcement in the
domain.

> 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.

Could you be more specific as to what you think may become a new security
consideration?

Editorial below are fine.

--
Alex


> 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".



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