>>>>> On Fri, 4 Jul 2014 18:16:17 -0400, Matthew Lepinski
>>>>> <[email protected]> said:
ML> I submitted a new version of the bgpsec protocol document. This
ML> revision includes a fair number of editorial changes but does
ML> not include any normative changes.
ML> Now that the BGPSEC requirements document is essentially done, I
ML> look forward to discussing the protocol document again in
ML> Toronto. In particular, between now and the Toronto meeting I
ML> will write up (and send to the list) a brief comparison between
ML> the requirements in the final version of the reqs draft and what
ML> we deliver in the protocol document.
ML> The only open issue in the protocol document that I am aware of
ML> is the following:
ML> * It was suggested in a review that we should explicitly specify
ML> (when we discuss error handling) that an implementation send a
ML> BGP NOTIFICATION message when an error occurs.
ML> Personally, I don't think this is necessary. (In particular, my
ML> reading of draft-ietf-idr-error-handling-13 is that in the
ML> "treat as withdrawal" case that a NOTIFICATION message is not
ML> required.
I'm working on a BGPSEC implementation and I've made some comments on
error handling in the past. If it is my comment you are mentioning,
then that wasn't quite what I meant.
In any case, I agree that not all errors should behave the same. I do
think that for a specific error case, the error handling description
should explicitly state whether or not a notification should be sent for
that type of error. E.g., when 'A' happens a notification SHOULD (or
SHOULD NOT) be sent.
I think the previous update together with the reference to the
idr-error-handling draft answered the issues I had. Looking through the
09 draft's version of UPDATE message error handling, the edits have only
made it clearer.
One minor thing I think is missing is a description of how to handle
multiple BGPSEC_Path attributes. Without it, I believe the default
response would be a session reset, but a treat-as-withdraw would be more
consistent. My reading of idr-error-handling is that 2+ AS_PATH
attributes, or an AS_PATH and BGPSEC_PATH attribute in an UPDATE message
would indicate a treat-as-withdraw. But without a description of the
handling of multiple BGPSEC_PATH attributes in the bgpsec-protocol doc,
2+ BGPSEC_PATH attributes would indicate a session-reset.
ML> That being said, I am very willing to defer to the BGP experts
ML> in the group on this issue. In particular, does anyone know if
ML> the intention of draft-ietf-idr-error-handling is for a
ML> NOTIFICATION to be sent when an error is "treat as withdrawal"?
ML> (I am concerned that sending a NOTIFICATION message in a case
ML> where we are not closing the session is not a good idea, but I
ML> am certain that others know more about these details than I do.)
I'm not sure about the intention of idr-error-handling draft. But FWIW,
my reading of the draft is that a session-reset MUST send a
notification. A treat-as-withdraw would not normally send a
notification, but could for a specific case. I'm using that
interpretation when reading the bgpsec-protocol draft. I.e., A
treat-as-withdraw indicates no notification is sent unless otherwise
specified.
-Mike
--
Michael Baer
[email protected]
Senior Software Engineer
Parsons Global Shared Services, Cyber Security Division
C: 530.902.3131
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
