> -----Original Message----- > From: Pradosh Mohapatra [mailto:pmoha...@cisco.com] > Sent: Tuesday, March 13, 2012 4:07 PM > To: George, Wes > Cc: internet-dra...@ietf.org; i-d-annou...@ietf.org; sidr@ietf.org > Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt > > > In section 2: > > "No ROA can match an origin > > AS number of "NONE". No Route can match a ROA whose origin AS > > number is zero." > > > > I'm wondering if there should be a 2119 normative or two in there? > > This sounds like a validation instruction. (eg MUST/SHOULD declare > > prefixes covered by an origin AS number of none/zero invalid) > > > Could you suggest text with 2119 language?
[WEG] Originally I stopped short of fully suggesting text because I didn't think that I had a complete grasp of what the authors are suggesting should happen here based on the combination of the text above. In rereading the surrounding text to make another attempt at it, I don't think that this sentence belongs in the definition for Route Origin ASN at all, because it's not really part of the definition. This is instructional about a special case of match/cover, and should probably be moved down a few sentences to where you talk about valid/invalid/unknown. The same is also true for the following from the definition of Matched. "keeping in mind that a ROA ASN of zero can never be matched, nor can a route origin AS number of "NONE"." So I would strike the references to ASN 0 and origin AS NONE from the definitions altogether, and then reword the next section as follows: CURRENT TEXT " Given these definitions, any given BGP Route will be found to have one of the following "validation states": o NotFound: No ROA Covers the Route Prefix. o Valid: At least one ROA Matches the Route Prefix. o Invalid: At least one ROA Covers the Route Prefix, but no ROA Matches it." NEW TEXT "Given these definitions, any given BGP route MUST [SHOULD?] be found to have one of the following "validation states": o NotFound: No ROA Covers the Route Prefix. o Valid: At least one ROA Matches the Route Prefix. o Invalid: At least one ROA Covers the Route Prefix, but no ROA Matches it. It should be noted that a ROA ASN of zero or a route origin AS number of "NONE" MUST NOT ever be considered matches. This means that routes with a covering ROA ASN of zero MUST be declared Invalid, and routes with a route origin AS number of "NONE" and one or more covering ROAs MUST be declared Invalid." Is that a reasonably accurate interpretation of the intent? > > > Lastly: > > "We observe that a Route can be Matched or Covered by more than one > > ROA. This procedure does not mandate an order in which ROAs must be > > visited; however, the "validation state" output is fully > > determined." > > Is there guidance on this in one of the other documents? If so, > > please reference it here. Does longest-match still apply? This seems > > a fairly big question to simply leave open to implementation. > > Please apply cluebrick liberally if I'm being thick. > > > I looked around in sidr-usecases and origin-ops, but couldn't find an > example. May be we should add one. But is there anything that you are > specifically worried about? All that the text says is that ordering is > not relevant. It's a classic OR operation for the match. [WEG] I didn't get "ordering not relevant" from the current text, but now that you say it, I see how it could be interpreted that way. See my suggested change as a reply to Randy's explanation. Thanks 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 sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr