> -----Original Message-----
> From: Pradosh Mohapatra [mailto:[email protected]]
> Sent: Tuesday, March 13, 2012 4:07 PM
> To: George, Wes
> Cc: [email protected]; [email protected]; [email protected]
> 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
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
