[Eric] I don't think the payload type can necessarily be inferred
from the AFI/SAFI of the UPDATE that is carrying the Tunnel
Encapsulation attribute. Consider, for instance, a case where the
next hop is not of the same address family as the NLRI, but the
route to the next hop is the route carrying the Tunnel
Encapsulation attribute.
[Xiaohu] It seems that the example that you had mentioned is the
usage of the Tunnel Encapsulation attribute e as described in
RFC5512, rather than the usage of the Tunnel Encapsulation attribute
as proposed by this draft:)
No; see section 5 ("Recursive Next Hop Resolution") of the new draft.
I think there are other examples where one might not be able to infer
the type of the payload from the AFI/SAFI of the route. Suppose you use
BGP as your only routing algorithm, and you use only the unlabeled
address families (AFI/SAFI = 1/1 or 2/1). But you use LDP (or SDN or
something else) to assign labels to prefixes. In this case, your data
traffic might be MPLS, but there is no use of the labeled address
families (AFI/SAFI = 1/4, 2/4, 1/128, or 2/128). If you use the Tunnel
Encapsulation attribute to specify a GRE tunnel for some route, you
could end up having to do an MPLS-in-GRE encapsulation.
I'm not sure whether there is a real use case for this, but I'm not also
not sure that we want to rule it out.
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
