> From: [email protected] [mailto:[email protected]] On Behalf Of > Matt Lepinski
> The -01 > version of the draft contains a mechanism (a field called pCount) > which attempts to address this issue by having route servers create > BGPSEC signatures without increasing the effective length of the AS- > PATH attribute. [WEG] where you explain the pCount field in both section 3 and 4.1, you never explicitly state anything about the route-server use case. In those sections, you only discuss the case where this is used to eliminate the need for duplicate signatures in the case of AS-path prepending. I think that section 3's explanation of the field definitely needs a reference to 4.1 and 4.2, and since 4.2 contains a backward reference to 4.1 explaining pCount>1, 4.1 should probably have a corresponding reference to 4.2 for pCount=0. It may also be appropriate to explicitly state in 4.1 that when a node sets the pCount to a value greater than 1, that value MUST correspond to the number of instances of the AS-path being represented in BGP's standard AS/AS4_path attribute. Some other general comments- as I noted in my review of the requirements document, I think that it's appropriate to note in this document an explicit requirement for 4-byte ASN support, including any discussion of how to handle 4-byte ASNs, as well as recommend explicit handling for occurrences of AS23456 in the path (eg, because we should be acting on the 4-byte ASN, we should never see the transition ASN in the path, and therefore those updates should always be seen as invalid). 4.2 - AS_SETs are deprecated. You should update your discussion accordingly, with a reference to whatever RFC draft-ietf-idr-deprecate-as-sets-06 became (I'm writing this offline, so I don't have the ability to find the number). 5.1 - Is the algorithm intended to be processed strictly in the order listed? Specifically, both in terms of the items preceded with "first, second, third, finally..." and within the multi-step subsection covering determining if updates are properly formed, it is unclear whether this is simply an arbitrary grammatical list grouping for ease of reading, or if it is an explicitly defined order. I would prefer that it either explicitly states that it requires the order listed (with justification/rationale as appropriate) or to explicitly note that the order is left to the implementation so that optimizations can be made based on the specific implementation. It may also be worth noting the places where there is no dependency between validation steps so that they can be processed in parallel on separate threads (such as when optimizing for multi-core applications). Also, shouldn't there be a reference to the origin validation documents instead of an explanation of how to do origin validation? Regarding confederations - what if one or more of the confeds is a private ASN? This is maybe a bit more straightforward if you're in the situation where AS1 learns the route originated from a private ASN in confederation, as it could simply originate/sign the route to its ebgp peers directly. It's more complicated (I think...) if the confed ASes are in the middle of the path (that is, the private ASN learns the route from a downstream ASN and then propagates it to the upstream confed peer) because there's not really a way to drop signatures from the middle of the path, yet the private ASNs are going to be stripped out of the BGP update messages as it leaves the confederation. Perhaps this is another case where the pCount should be 0? Is there any other special handling for confed? Alternatively, we may have to explicitly prohibit this setup similar to the way that we did with AS_Set. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
