Roque,
Yes, there has been some confusion about AS4_Path, I think my text in
the protocol draft (both the current version, but especially in previous
versions) is in part responsible for this.
I agree that even if we included AS_Path in BGPSEC update messages
BGPSEC speakers MUST support 4-byte AS numbers and so there would never
be any reason to include AS4_Path. My apologies for lack of clarity in
the spec, I'll attempt to remove any lingering ambiguity in the next
update to the draft.
- Matt Lepinski
On 5/24/2012 5:07 AM, Roque Gagliano (rogaglia) wrote:
Randy,
well, actually, the discussion in april was walking around many of the
implications thereof. it is hard to discuss "do we keep/replace
AS[4]_PATH" as it is abstract and draws deep philosophical discourse
with no hard handles on technical decision points.
I think you should remove the [4] from the discussion. 4 bytes ASN is mandatory
for BGPSEC speakers. So, there should be no AS4_PATH attributes between BGPSEC
routers to keep/replace.
Roque
otoh, i would be really interested in hearing/discussing if anyone sees
any show-stoppers to the current draft doing so.
i am amused that the current draft says, in the intro,
2. Every AS listed in the AS_Path attribute of the update explicitly
authorized the advertisement of the route to the subsequent AS in
the AS_Path.
when there is no bgpsec as_path. :)
The absence of the AS_PATH did come up in discussing other topics (see
the minutes), but we did not discuss it directly.
see above
(2) router private key provisioning.
In the interim in San Diego, there were requests (from operators) that
guidance to operators of how to provision a router with the needed
keys would be a good idea. We had some discussion in the Paris
meeting of two drafts discussing provisioning the routers with their
needed private keys. There's also been a recent flurry of discussion
on the list.
no comments on the new version of draft-ietf-sidr-rtr-keying-00.txt.
would appreciate some now or we can ask for wglc.
there have been no comments on list to confed and aliasing. may we call
them done?
randy
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
