>>>>> On Tue, 5 Nov 2013 01:38:19 -0500, Matthew Lepinski
>>>>> <[email protected]> said:
MattL> I have submitted draft-ietf-sidr-bgpsec-protocol-08. My
MattL> apologies that I didn't get this version in the draft
MattL> repository before the IETF 88 cut-off.
MattL> The main change in this version of the document is that I
MattL> added a reference to draft-ietf-idr-error-handling. The text
MattL> now references this document with regards to errors in the
MattL> BGPSEC_Path attribute. Additionally, the document clearly
MattL> specifies that for any error in the BGPSEC_Path attribute,
MattL> the BGPSEC speaker MUST "treat-as-withdraw" (as defined in
MattL> draft-ietf-idr-error-handling).
MattL> Additionally, I made a small number of editorial changes
MattL> which I believe improve the clarity of the text in a couple
MattL> of places.
I agree with most of the error handling updates but I have several comments
on them as well. Mostly I think there should be more specific language
on how to handle the errors.
The first comment is editorial. At the bottom of page 24 (section 5.2),
it looks there is a cut/paste error and some text wasn't removed from
the previous draft that should have been:
an error in the BGPSEC_Path attribute, then the implementation should
notify the operator that an error has occurred and treat the update
in a manner consistent with other BGP errors (i.e., following RFC
4271 [2] or any future updates to that document).
Also in section 5.2, I think the language should more explicitly state
what do when an error occurs. This would include sending a NOTIFICATION
message with new error Subcode of Malformed BGPSEC Attribute. Suggested
text:
Current:
If any of these checks fail, it is an error in the BGPSEC_Path
attribute. Any of these errors in the BGPSEC_Path attribute are
handled as per RFC WXYZ [12]. BGPSEC speakers MUST handle these
errors using the "treat-as-withdraw" approach as defined in RFC WXYZ
[12].
Add:
The implementation should notify the operator that an error has
occurred and send a NOTIFICATION message with an Error Subcode set to
Malformed BGPSEC Attribute and an empty data field.
Also, of the 5 error types, the AS_PATH being included along with a
BGPSEC attribute in an UPDATE message is not really a Malformed BGPSEC
Attribute error. So I think this error should be handled otherwise the
same but with a different error Subcode in the NOTIFICATION.
e.g.
N. Check that the update message does not contain an AS_PATH
attribute.
If this check fail, it is an error in the UPDATE's attribute
list. This error is handled as per RFC WXYZ [12]. BGPSEC speakers
MUST handle this errors using the "treat-as-withdraw" approach as
defined in RFC WXYZ [12]. The implementation should notify the
operator that an error has occurred and send a NOTIFICATION message
with an Error Subcode set to Malformed Attribute List and an empty
data field
-Mike
--
Michael Baer
[email protected]
Senior Research Scientist
Parsons - Tislabs
C: 530.902.3131
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
