Re: [Sidrops] rfc7607 & multiple ROAs covering same resource

John,

> 在 2017年3月22日，02:26，John G. Scudder <jgs@juniper.net> 写道：
> 
> To add to this, there's a fairly obvious use case for having two extant ROAs, one for AS 0 and one for another ASN -- make-before-break. I'm not sure why you'd persistently have both of them, but it seems harmless. Or at least "mostly harmless" to quote D. Adams.
> 

Agreed. “Make-before-break”  is making sense here  :-)

> As for 7606 itself, I think nothing needs to be changed. The text related to ROAs is only there to provide motivation -- the only normative language in the RFC is in section 2, and it doesn't talk about ROAs or route validation. I just reread the section and it seems clear to me. In short: don't put AS 0 on the wire in a BGP message. The conversation we’re now having is evidence no good deed goes unpunished -- if the motivating text had been omitted and only section 2 published, we'd be good I guess.
> 
> The 6483 section 4 language trips over itself a bit -- if it were still in draft I'd suggest removing the "by convention" language since it's nonsense. But it’s harmless nonsense (or at least "mostly harmless") since in the very next clause it says "this is not a strict requirement".
> 
> Doesn’t seem like there's a problem in need of fixing.

Right. It also seems to me there is no need of fixing. 

I comprehended “by convention” as a sort of suggestion, while “not a strict requirement” do leaves it to operator to do at its discretion. 

Huh, one is free to have multiple ROAs existence with ROA 0 included. Yet I believe the very implication is quite conspicuous. 

Declan (Di)

> 
> --John
> 
>> On Mar 21, 2017, at 1:56 PM, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
>> 
>> RFC 7607 does use the word "only":
>> 
>>  This allows a resource holder to signal
>>  that a prefix (and the more specifics) should not be routed by
>>  publishing a ROA listing AS 0 as the only origin.
>> 
>> 
>> https://tools.ietf.org/html/rfc6483
>> 
>>  In an environment of a collection of valid ROAs, a route's validity
>>  state is considered to be "valid" if any ROA provides a "valid"
>>  outcome.  It's validity state is considered to be "invalid" if one
>>  (or more) ROAs provide an "invalid" outcome and no ROAs provide a
>>  "valid" outcome.
>> 
>> The ROA for AS 0 provides an "invalid" outcome.
>> However, the other ROA provides a "valid" outcome.
>> Therefore, the final outcome is "valid".
>> 
>> Thanks,
>> Jakob.
>> 
>> 
>>> -----Original Message-----
>>> From: Sidrops [mailto:sidrops-bounces@ietf.org] On Behalf Of Declan Ma
>>> Sent: Tuesday, March 21, 2017 9:00 AM
>>> To: Job Snijders <job@ntt.net>
>>> Cc: sidrops@ietf.org
>>> Subject: Re: [Sidrops] rfc7607 & multiple ROAs covering same resource
>>> 
>>> Job,
>>> 
>>>> 在 2017年3月21日，23:50，Job Snijders <job@ntt.net> 写道：
>>>> 
>>>> Hi Declan,
>>>> 
>>>> On Tue, Mar 21, 2017 at 11:22:36PM +0800, Declan Ma wrote:
>>>>> [RFC6483] states “A ROA with a subject of AS 0 (AS 0 ROA) is an
>>>>> attestation by the holder of a prefix that the prefix described in the
>>>>> ROA, and any more specific prefix, should not be used in a routing
>>>>> context.”
>>>>> 
>>>>> I believe this issue bears relevance with how RP software responds to
>>>>> multiple ROAs existence with ROA 0 included.
>>>>> 
>>>>> As for the example you provide, if both ROAs have been validated
>>>>> successfully, it is up to RPs to generate output to BGP speakers.
>>>>> 
>>>>> Even a ROA with AS 0 doesn’t preclude other valid ROAs, we should not
>>>>> encourage this operation.
>>>> 
>>>> How and why would you discourage this, if it is a valid mode of
>>>> operation? Clarity is king. There may be legitimate use cases for doing
>>>> this.
>>>> 
>>> 
>>> There MAY be legitimate use cases for doing this.
>>> 
>>> These cases should be justified before the WG discuss how to update RFC 7607.
>>> 
>>> I am open to this operation, hoping to see more detailed context in which you said the owner of the ROAs was
>>> intentional to do that.
>>> 
>>> Declan (Di)
>>> 
>>> _______________________________________________
>>> Sidrops mailing list
>>> Sidrops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sidrops
>> 
>> _______________________________________________
>> Sidrops mailing list
>> Sidrops@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidrops
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops