Re: [mpls] Routing directorate review of draft-ietf-mpls-rfc3107-bis

[Jonathan Hardwick <[e-mail]>]

Hi Eric

Thanks for making these changes.  This resolves my concern.

Best regards
Jon


-----Original Message-----
From: Eric C Rosen [mailto:[e-mail]] 
Sent: 09 May 2017 16:04
To: Jonathan Hardwick <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: Routing directorate review of draft-ietf-mpls-rfc3107-bis

Hi Jon,

I've made some modifications to section 5 in response to your comments.  
While I don't want to get into a lot of details about the implementation differences, I do think it is fair to ask that section 5 point out more clearly that there can be interoperability problems, and that it might not be possible to achieve a desired set of local policies with some implementations or some combinations of implementation.  See below for the proposed new contents of Section 5.

Eric
----------------------
5.  Relationship Between SAFI-4 and SAFI-1 Routes

    It is possible that a BGP speaker will receive both a SAFI-1 route 
for prefix P and a SAFI-4 route for prefix P.  Different implementations 
treat this situation in different ways.

    For example, some implementations may regard SAFI-1 routes and 
SAFI-4 routes as completely independent, and may treat them in a "ships 
in the night" fashion.  In this case, bestpath selection for the two 
SAFIs is independent, and there will be a best SAFI-1 route to P as well 
as a best SAFI-4 route to P.  Which packets get forwarded according to 
the routes of which SAFI is then a matter of local policy.

    Other implementations may treat the SAFI-1 and SAFI-4 routes for a 
given prefix as comparable, such that the best route to prefix P is 
either a SAFI-1 route or a SAFI-4 route, but not both.  In such 
implementations, if load-balancing is done among a set of equal cost 
routes, some of the equal cost routes may be SAFI-1 routes and some may 
be SAFI-4 routes.  Whether this is allowed is again a matter of local 
policy.

    Some implementations may allow a single BGP session to carry UPDATES 
of both SAFI-1 and SAFI-4; other implementations may disallow this.  
Some implementations that allow both SAFIs on the same session may treat 
the receipt of a SAFI-1 route for prefix P on a given session as an 
implicit withdrawal of a previous SAFI-4 route for prefix P on that 
session, and vice versa.  Other implementations may have different behavior.

    A BGP speaker may receive a SAFI-4 route over a given BGP session, 
but may have other BGP sessions for which SAFI-4 is not enabled.  In 
this case, the BGP speaker MAY convert the SAFI-4 route to a SAFI-1 
route and then propagate the result over the session on which SAFI-4 is 
not enabled.  Whether this is done is a matter of local policy.

    These differences in the behavior of different implementations may 
result in unexpected behavior or lack of interoperability.  In some 
cases, it may be difficult or impossible to achieve the desired policies 
with certain implementations or combinations of implementations.