Keyur,
Thank you for taking the time to read and offer comments.
I find the comments very insightful and helpful.
My comments are marked with [Sriram] below.
>From: Keyur Patel ke...@arrcus.com
>Sent: Wednesday, January 4, 2017 5:53 PM
>The document is well written, easy to read and follow.
>Some minor comments are listed below:
>1) Section 4.1 “The BGPsec Path attribute and the AS_PATH attribute are
>mutually exclusive. That is, any update message containing the BGPsec Path
>attribute MUST NOT contain the AS_PATH attribute”. For any restarting
>speakers in a GR mode, where the bgp capability is not exchanged, the existing
>stale routes won’t have an AS_PATH attribute. We could add some clarifying
>that helps to indicate that such routes should be considered valid in stale
>mode (till they get refreshed)?
[Sriram] As you have clarified for me on the phone, what you are saying here
is that the two BGPsec peers lost the BGPsec session and now restarting in GR
mode, but they have not exchanged BGPsec capability this time. Hence, they are
now simple BGP (non-BGPsec) peers in GR mode. RFC4271 considers update message
received without a well-known AS_PATH attribute as an error, and unfortunately
in this case the cached BGPsec updates do not have AS_PATH (albeit they have
BGPsec_Path). So you are saying "the router should not panic" and instead
simply treat each cached update as NOT-IN-ERROR even though it is missing
AS_PATH attribute. This way the GR can work properly. Of course, shortly the
updates will have AS_PATH (and not considered in error) when they get refreshed
(over the new simple BGP session). Per your suggestion, I will include new text
in Section 7 to describe this required behavior for the GR mode.
>2) 4.1 4th paragraph: "Note also that new signatures are only added to a
>BGPsec update message when a BGPsec speaker is generating an update message to
>send to an external peer (i.e., when the AS number of the peer is not equal to
>the BGPsec speaker's own AS number). Therefore, a BGPsec speaker who only
>sends BGPsec update messages to peers within its own AS does not need to
>possess any private signature keys." This text doesn't seem to apply to confed
>peers? If so, it would be nice to clarify that this text doesn't apply to any
>confed peers.
[Sriram] You have clarified in our phone conversation that you consider the
inter-AS-member sessions as "iBGP" since they are all within a confederation AS
domain. The BGPsec document considers the inter-AS-member sessions as "eBGP"
(not "iBGP") and intra-Member-AS sessions as "iBGP". You also clarified that
you may call inter-AS-member sessions as "confederation-eBGP" sessions.
Obviously, private key is required to sign over such
"confederation-eBGP/BGPsec" sessions. I understand your point. I will put in
new text (notes) to clarify this in the document.
>3) Section 5 and Section 5.2, 1st paragraph: RFC4271 considers update message
>received without a well-known AS_PATH attribute as an error. We need some
>text to clarify the (error handling if any) behavior when an update message is
>received without a bgpsec and an aspath attribute. The current draft text
>seems unclear about generation of bgpsec attribute as well (in a ibgp
>scenario). Is it a requirement to generate an empty bgpsec attribute?
[Sriram] As you have clarified for me over the phone, RFC 4271 (page 26) says
the following :
"When a BGP speaker originates a route then:
b) the originating speaker includes an empty AS_PATH attribute in
all UPDATE messages sent to internal peers. (An empty AS_PATH
attribute is one whose length field contains the value zero)."
[Sriram] So what needs to be said in the BGPsec document is the following:
The BGPsec_Path attribute is not attached in updates originated inside an AS
and propagated to BGPsec capable internal peers. However, when a route is
originated inside an AS and propagated to non-BGPsec internal peers, an empty
AS_PATH attribute is included in the update (see [RFC 4271], page 26).
>4) With an AS_PATH attribute in 4271 there was loop detection in place.
>With BGPSec I don’t see that being called explicitly other than a passing
>remark in section 5. Section 5.2 should have a check that allows a BGPsec
>speaker to bail out of a validation procedure when a aspath loop is detected.
[Sriram] I agree. I will include loop detection in the list of error checks in
Section 5.2.
Sriram
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
