Re: [Idr] AD Review of draft-ietf-idr-bgp-prefix-sid-07

[Alvaro Retana <[e-mail]>]

On December 22, 2017 at 10:50:25 AM, Eric C Rosen ([e-mail])
wrote:

Hi!

On 12/21/2017 4:52 PM, Alvaro Retana wrote:

I don't think the following point is correct.

After thinking about it some more, Eric's right...for the MPLS dataplane
where the attribute contains the index.

But for IPv6 the attribute contains the SID itself — see more below.

(2) Error Handling

The error handling (in Section 6) specifies that “attribute discard”
(rfc7606) should be used if the attribute is malformed.  I think that
behavior has a direct effect on the path used to forward the traffic, which
puts it then in conflict with rfc7606 because it clearly says that
"Attribute discard...MUST NOT be used except in the case of an
attribute that has no effect on route selection or installation.”  Please
see M9 below.


M9.  If the attribute is malformed then the index or SID in it won’t be
used by the receiver (attribute discard) as specified in Section 6.
Section 4.1 explains how a local label is assigned if the BGP Prefix-SID
attribute is unacceptable.

M9.1. I’m assuming that the local label assignment in 4.1 includes the case
when the attribute is malformed (i.e. not just the unacceptable case).  Is
that true?   Using a local label would result in successfully delivering
the traffic to the destination, but not using the intended SR path, right?
If that is true, then the malformed attribute case would have an effect on
route selection/installation and could result (among other things) in the
traffic taking an unwanted path due to policy, a path that is congested,
etc.…and that is explicitly the case where rfc7606 specifies that attribute
discard MUST NOT be used.  It seems that any action beyond attribute
discard may be too harsh given that a local label can be assigned…but the
current specification ("MUST treat the path as if it came without a
Prefix-SID attribute...MUST assign a local (also called dynamic) label”) is
in conflict with rfc7606.   I would be ok if the document explained the
potential issues and made the local label behavior optional (pending a
discussion in the WG and maybe an update to rfc7606).  BTW, was this
discussed in the WG (I couldn’t find a related discussion in the archive)?


The presence of absence of the prefix-SID attribute is not taken into
account in any way by the BGP bestpath selection process, so it has no
effect on "route selection or installation".  Thus I don't see any conflict
between this draft and RFC 7606.

If I understand correctly, the intention of the prefix-SID attribute on a
BGP-LU route is the following.  When a router receives a BGP-LU route for
prefix X with label L1, it propagates that that route with a locally
assigned label L2.  The prefix-SID attribute tells the router what the
value of L2 should be.  But if the router uses a different value of L2,
that doesn't change the path followed by the data.  Thus "treat as
withdraw" does not seem like the proper response to a malformed prefix-SID
attribute, whereas "attribute-discard" seems appropriate.

I'm less sure what the impact of a malformed prefix-SID attribute is when
the dataplane is not MPLS.

Using the example in Section 5. (Applying Segment Routing in the DC with
IPv6 dataplane) of draft-ietf-spring-segment-routing-msdc [1].  If the BGP
Prefix-SID attribute is malformed (“attribute discard”) in the
advertisement from Node5, then (as currently written in the document) the
rest of the network wouldn’t know which SID to use…this means that the
expected result of the example: "HostA which needs to send traffic to HostZ
via only Node5 (spine node) can do so by sending IPv6 packets with a SRH
extension header” can’t be realized.  The result would then be that the
traffic could be delivered to Node11, but maybe not through Node5.

While the attribute is not taken into account in the BGP selection process,
it is clear to me that the resulting paths are impacted because not all
the expected routes are installed as a result of a malformed attribute.  I
found this related text in Section 8. (Guidance for Authors of BGP
Specifications) of rfc7606:

   For any malformed attribute that is handled by the "attribute
   discard" instead of the "treat-as-withdraw" approach, it is critical
   to consider the potential impact of doing so.  In particular, if the
   attribute in question has or may have an effect on route selection or
   installation, the presumption is that discarding it is unsafe unless
   careful analysis proves otherwise.  The analysis should take into
   account the tradeoff between preserving connectivity and potential
   side effects.

I think this is one of those cases where the combination of a policy (“send
traffic via Node5”) and a discarded attribute (resulting in no SID for
Node5) could result in an unanticipated effect…yes, not directly related to
the selection process, but to the paths that can be installed and used.  In
line with the text above, I would be happy if some analysis was written
into the text:  Just like in the MPLS case, there could be an alternate
procedure that could be used to still be able to instantiate the desired
path…or simply making operators aware of the potential effect of discarding
the attribute would be enough.

Thanks!

Alvaro.

[1]
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-05#section-5