[no subject]

   Additionally, the Encapsulation SAFI UPDATE message can contain a
   community or extended-community as a way to color the corresponding
   tunnel TLV(s).  The same community or extended community can then be
   attached to the UPDATE messages that contain payload prefixes. This
   way, the BGP speaker can express the fact that it expects the packets
   corresponding to these payload prefixes to be received with a
   particular tunnel encapsulation header.

With this in mind consider a scenario where a PE receives an
encaps-safi update for a tunnel destined to address A1, and this
update is "colored" with a particular community C. The PE also
receives an VPN-IPv4 update that carries the same community C, but
its next hop is not A1, but A2.

What should the PE do when resolving the next hop towards VPN-IPv4
routes ?

One could argue that if the nexthop address in a VPN-IPv4 update
does not match any of the addresses from an encaps-safi update, the
nexthop can not get resolved. In other words, this should be treated
as a misconfig -- i.e.  there is no way to reach that nexthop using
a tunnel encap (unless there is some local config forcing to use
an encap).

However, this argument is incorrect, as just because the nexthop
address in the VPN-IPv4 update does not match any of the addresses
from an encap-safi update does not really mean that "the next hop
can not get resolved".  In other words, just because there is no
way to reach the nexthop using the tunnel carried in the encap-safi,
does not mean that there is no way to that nexthop.

Another alternative could be as follows:

1. Next hop resolution is done as usual, with no regard to color.
 
2. If  the next hop corresponds to  two encaps-safis, one red  and one blue,
then:

    - if the destination address matches a red prefix, use the red encaps
 
    - if the destination address matches a blue prefix, use the blue encaps
 
    - if the  destination prefix  is not colored,  and there is  no uncolored
      encaps-safi,  then  we have  a  config error  and  the  packet will  be
      dropped.

In this alternative the last item seems incorrect - it should be up to 
the ingress PE to decide whether to forward or to drop (it is a matter 
of policy).

Moreover, there is a case that is not covered by the above. Namely,
where the Next Hop does not match any of the addresses from the
encap-safi updates.  In this case one can not say that the next hop
can not get resolved; it can not get resolved *only* via available
encap-safi. 

With all this in mind perhaps the spec should say that if after the next
hop resolution, the next hop does not have any encaps info, or does
not have encaps info that matches the color of the prefix, then
disposition of the packet is a matter of policy on the ingress PE.

Of course, the next question to ask is what is the default policy
that every vendor SHOULD support. Here is a strawman proposal for
such default policy:

1. Perform the usual procedures for finding the next hop, call it N.
 
2. If no next hop is found, drop the packet and exit.

3. If the policy is that there must be a color-matching encaps-safi, then
 
    a. If there is none, remove from consideration all routes whose next hop
       is N, and go to 1.
 
    b. If there is a color-matching encaps-safi, tunnel the packet according-
       ly and exit.

4. If the  policy  is  that there  does  not need  to  be a  color-matching
   encaps-safi, then do whatever the policy says.

Yakov.
_______________________________________________
Softwires mailing list
Softwires at ietf.org
https://www.ietf.org/mailman/listinfo/softwires