Re: [sidr] request for agenda items for interim meeting 6 Jun

[Matt Lepinski <[e-mail]>]

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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sidr
>
>
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr