The prefix-to-AS mappings used by the BGP speaker are expected to be
updated over time. When a mapping is added or deleted, the
implementation MUST re-validate any affected prefixes. An affected
prefix is any prefix that was matched by a deleted or updated
mapping, or could be
-Original Message-
From: Randy Bush [mailto:ra...@psg.com]
Sent: Tuesday, March 13, 2012 5:03 PM
you want the inclusive or, if any one matches it's Valid. otherwise,
you can not do a make-before-break provider switch, for example.
as to the matching rules, i have extracted a few
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
-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
sorry I normally follow sidr on the archive...
To: sidr wg list sidr at ietf.org
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt
From: Randy Bush randy at psg.com
Date: Tue, 13 Mar 2012 08:35:57 +0900
Delivered-to: sidr at ietfa.amsl.com
In-reply
On Mar 13, 2012, at 2:27 AM, Randy Bush wrote:
o a prefix against which validation has not been run (no validation
at all or some knob turned off) should not be marked Valid. that
would be a lie. it should be marked NotFound.
FWIW - the JUNOS implementation has got this 4th state,
Unverified is the default state for all prefixes … so if you do fall
off the end then the system will set it to its default values.
the only problem i see with this is that, if i do not test for it in
policy, i will fall off the end.
term unknown {
from {
Not replying to a specific message, since I'm replying to several issues
simultaneously.
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
On Tue, Mar 13, 2012 at 08:16:42PM +0900, Randy Bush wrote:
| Unverified is the default state for all prefixes … so if you do fall
| off the end then the system will set it to its default values.
| the only problem i see with this is that, if i do not test for it in
| policy, i will fall off
Hi Wes,
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
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
I also have some problems with aspects of the
draft-ietf-sidr-pfx-validate-04.txt draft, particularly this bit from
Section 2:
When a BGP speaker receives an UPDATE from one of its EBGP peers,
it SHOULD perform a lookup as described above for each of the
Routes in the UPDATE message.
i have two serious disagreements with this draft.
o a prefix against which validation has not been run (no validation at
all or some knob turned off) should not be marked Valid. that would
be a lie. it should be marked NotFound.
o routes learned by ibgp and routes originated on
-Original Message-
From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of Randy
Bush
Sent: Monday, March 12, 2012 4:36 PM
To: sidr wg list
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt
i have two serious disagreements with this draft.
o a prefix
On Mar 13, 2012, at 12:35 AM, Randy Bush wrote:
o a prefix against which validation has not been run (no validation at
all or some knob turned off) should not be marked Valid. that would
be a lie. it should be marked NotFound.
FWIW - the JUNOS implementation has got this 4th state,
o a prefix against which validation has not been run (no validation
at all or some knob turned off) should not be marked Valid. that
would be a lie. it should be marked NotFound.
FWIW - the JUNOS implementation has got this 4th state, called
Unverified.
the only problem i see with
16 matches
Mail list logo
