Re: [Softwires] softwires-encaps-safi

["Pradosh Mohapatra (pmohapat)" <[e-mail]>]

Hi Yakov,

| From 4.3:
| 
|    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.

Are you referring to nexthop validation or nexthop resolution in this
context? I consider these as different: nexthop validation is what
triggers the BGP speaker to accept the received prefixes or reject them.
Nexthop resolution is what triggers the BGP speaker to install the
prefixes
in forwarding table for active lookups. If the nexthop is not resolved,
the prefixes are put in unresolved state.

The nexthop resolution itself takes various forms and is heavily
dependent
on whether the packet needs to be tunneled or sent in native encoding
format. If the application is to send the packet tunneled, just checking
nexthop reachability (e.g. IGP information) is not sufficient and it
would
in fact be incorrect to resolve the nexthop & prefixes just based on
that
(An example is the MPLS VPN case where we need to have MPLS encaps be
available for the BGP nexthops).

Coming back to encaps SAFI discussion, I think there are two scenarios
where I sense a concern:
(1) No encaps-safi for a nexthop,
(2) encaps-safi for a nexthop, but there is no match for prefix color

Let's take the first case. We agreed before that encaps-safi is not a
MUST (e.g. GRE tuneling), at which point, it becomes a local
configuration
on how to encap.

If there is no local configuration, I still maintain that having no 
encaps-safi for a nexthop means that nexthop is unresolved. This is
because
signaling information is propagated asynchronously in the network. If
a PE receives a VPN-IPv4 UPDATE with nexthop N1 and there is no
encaps-safi
information about N1, it does not necessarily mean N1 is to be resolved
in a certain different way. It could very well mean that the encaps-SAFI
update for N1 is in transit -- so the prefixes need to be kept in
unresolved
state till N1's encap information is available. There could, of course,
be
a local config to assume a certain default encap, but in the absense of
that config, it is better to put it in unresolved state.

I consider the second to be a "special case" of the first. Local
configuration can override to derive encap information for N1, but in
the absense of that, it would be unresolved. May be the color could
carry
a notion of "strict" match vs. a "loose" match in that, if it is
signaled
as a 'loose' match, then even if the prefixes are not colored, the
nexthop is considered to be resolved for those prefixes?

- Pradosh 
_______________________________________________
Softwires mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/softwires