Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 as IDR WG document?

[Shane Amante <[e-mail]>]

If this draft is adopted as a WG doc, I would like to see some refinements wrt the following:
1)  IIUC, the draft alludes to a situation where one can either send regular IGP Cost in the NH_SAFI attribute -or- "(not necessarily IGP cost, but whatever has been chosen to be carried in NH SAFI)".  See also Appendix A.2.  Although I see the "simplicity" of wanting to go with this latter direction (non-IGP cost in NH_SAFI), I think it has the potential to create some significant operational (and/or, implementation) hazards and thus should be considered for removal.  Unless, someone can convince us that it is, after all, "safe".  More specifically, I think:
    a)  If a node -- let's say it's another RR client in the same cluster -- does not understand (hasn't implemented) NH_SAFI, then how is it supposed to receive the NH value + "special cost", which presumably is needed at a bare minimum for routes to pass BGP's NEXT_HOP reachability check?  
        i)  At the very least, this makes an assumption and puts a burden on the RR client to have, at the very least, a less specific route for the NH in it's IGP (or traditional BGP) for that purpose, which should get documented in a Operational Considerations section.
        ii) What's potentially more concerning is that if RR clients in the same cluster are configured to be fully iBGP meshed, (not using client-to-client reflection on their RR), then if one of those RR clients can't see the NH_SAFI, then it could fall back on the IGP metric and make an inconsistent path selection and lead to forwarding loops.
    b)  Can an operator stick any value he/she wants for NEXT_HOP in that field of the NH_SAFI?  Or, must the implementation only send a NEXT_HOP in NH_SAFI, when it has a valid match (IPv4 /32 or IPv6 /128?) for that NEXT_HOP in their IGP routing table?
    c)  Is the NH_SAFI + "special cost" only supposed to be configured on the RR or on the RR-clients and sent to the RR?  (I think it's the latter).  Regardless, it should be recommended that the RR-client must always send a consistent NH_SAFI + "special cost" to it's redundant set of (upstream) RR's -- or, the RR's must be configured identically with the same NH_SAFI + "special cost" -- in order to ensure consistent path selection at the redundant set of RR's.

2)  I think the document could benefit from an "Applicability Statement" section, which:
    a)  More clearly articulates that this solution is primarily intended to be used in networks whose RR's don't have full visibility to IGP costs from the perspective of each of its clients due to well-known issues with lack of IGP visibility due to Inter-Area or Inter-Level summarization.
    b)  I don't think this draft is aimed at Inter-AS use, since presumably MED's are still sufficient in that case?  Either way, that should get clarified.

3)  I also think the document could benefit from an "Operational Considerations" section, which:
    a)  Discusses whether changes to "Administrative Distance" are needed at the RR's, specifically for the NH_SAFI addresses.  Are these going to be required (manually) by Operators or automatically through the implementators of NH_SAFI so that NH_SAFI are consistently selected for NH resolution compared to traditional IGP metric costs.  For example, on Cisco iBGP AD is 200 vs. IGP's such as OSPF or ISIS that are at 110 and 115, respectively.  (There is a very brief discussion already in Section 3 that talks about using NH_SAFI instead of IGP cost, but it's not clear if this is enforced through the implementation of NH_SAFI or if it will be required of the operator to manually tune AD's to get this 'right').
    b)  Recommendations that it would probably be advisable for operators to enable and tune SPF throttling in their networks and, more importantly, that implementations of NH_SAFI only flood "new" NH_SAFI information _after_ an SPF has occurred.  This would hopefully mitigate a vicious feedback loop from the IGP cranking through lots of SPF's and shoving that info into BGP toward an, already very busy, RR.

Thanks,

-shane


On Nov 16, 2011, at 2:06 AM, John Scudder wrote:
> Folks,
> 
> We have received a request from the authors to adopt draft-varlashkin-bgp-nh-cost-02 as an IDR WG document.  Please send your comments to the list.  The deadline for comments is December 5, 2011 at noon EST.
> 
> Thanks,
> 
> --John
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr