On Tue, Jan 14, 2014 at 6:38 PM, Sriram, Kotikalapudi <[email protected]> wrote: > I support publication of this document as an RFC.
As do I. W > I have some comments listed below that are meant to help improve clarity. > > 3.2 (current) A BGPsec design must allow the receiver of a BGP announcement > to determine, to a strong level of certainty, that the received PATH > attribute accurately represents the sequence of eBGP exchanges that > propagated the prefix from the origin AS to the receiver, particularly if an > AS has added or deleted any AS number other than its own in the path > attribute. This includes modification to the number of AS prepends. > > 3.2 (suggested rewording) A BGPsec design must allow the receiver of a BGP > announcement to determine, to a strong level of certainty, that the received > PATH attribute accurately represents the sequence of eBGP exchanges that > propagated the prefix from the origin AS to the receiver. Specifically, if an > AS has deleted any ASN from the AS PATH it received or added an ASN other > than its own then the verification of the update (if propagated) MUST fail at > its neighboring BGPsec routers. This includes modification to the number of > AS prepends, i.e. an AS in the path MUST NOT be able to modify the AS > prepends (if any) of preceding ASs in the AS PATH. > > 3.4 (current) A BGPsec design MUST be amenable to incremental deployment. > This implies that incompatible protocol capabilities MUST be negotiated. > > "Negotiating incompatible protocol" -- the phrase doesn't sound right to me. > > 3.4 (suggested rewording) A BGPsec design MUST be amenable to incremental > deployment. This implies that a BGPsec capable router MUST be backward > compatible and MUST negotiate BGP-4 protocol with a BGP-4 only neighbor, and > MUST interoperate with the BGP-4 only neighbor. > > 3.4 and 3.13 are related (overlapping). You may consider combining them. > > In 3.14, this statement "Such mechanisms SHOULD conform with > [I-D.ietf-sidr-ltamgmt]" seems a bit abrupt. You should state what in > [I-D.ietf-sidr-ltamgmt] is relevant here to "best path and other routing > decisions." Note: You do speak about [I-D.ietf-sidr-ltamgmt] more > specifically again in 3.17. > > Sriram > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
