Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt

["George, Wes" <[e-mail]>]

> -----Original Message-----
> From: Pradosh Mohapatra [mailto:[e-mail]]
> Sent: Tuesday, March 13, 2012 4:07 PM
> To: George, Wes
> Cc: [e-mail]; [e-mail]; [e-mail]
> 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.