See my comments inline
On 12/29/16, 6:23 PM, "sidr on behalf of Randy Bush" <[email protected] on
behalf of [email protected]> wrote:
>>> 1. It is common to use private ASNs in Confederations,
>> but the global RPKI can’t support that. draft-ietf-sidr-slurm seems
>> to address the issue of local management of private resources in the
>> RPKI. …
>the issue is not how the confed AS validates ROAs of the private ASs in
>the confed. that is trivial and supported by existing software. my
>questions revolve around path processing.
I believe the answer to your question is found in section 7, paragraph #8 and
following.
There I see explanation on how to process the path using private AS numbers,
etc.
>4.3 confuses me by using 'private' ambiguously. i have tried to read
>that section yet again and drowned in the mass of words. perhaps more
>coffee will help; but i am not optimistic. i pity the implementors.
>
>randy
Revisiting Section 4.3, I made the following observations:
In my opinion the second Paragraph explains clearly the process of the ingress
BGPSec
router at the confederation boundary. I believe the process described of adding
a
signature with pCount=0 will resolve the issue that Alvaro observed.
Said that, I feel that the explanations in paragraphs #3 and #4 are not very
helpful.
There I do agree with Randy's "mass of words" comment. I suggest to either
shorten
them or completely remove them. These two paragraphs are not needed, in
contrary
they might add unnecessary confusion.
When removed the following current paragraphs 5 and following do explain
clearly the
process in the intermediate AS-members and the egress BGPSec router of the
confederation.
In short I think paragraphs #3 and #4 disrupt the flow and are not so helpful,
so I propose to remove them.
To avoid unnecessary confusion with the ambiguity of the word private, I would
change
the wording of “the (private) Member-AS Number” to “the Member-AS Number” by
removing the wording of “(private)” within parenthesis.
This leaves the usage of private only for the signing parties private key which
I think
is well understood.
Oliver
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
