On 7/24/2015 4:40 AM, Xuxiaohu wrote:
Now it seems that the above rationale has been shaken by this draft.
The argument in favor of the Encapsulation-SAFI doesn't seem to have
been as persuasive to everyone else as it was to the authors of RFC 5512 ;-)
Futhermore, since it allows to attach BGP Encap attributes to routes
now, the BGP encapsulation extended community can now be safely
replaced by BGP Encap attribute. Therefore, I wonder whether RFC5512
would be obsoleted by this draft in the end.
Quite a few people have suggested that RFC5512 should be obsoleted by
the tunnel encaps draft; this is worth considering.
However, I think we need to maintain compatibility with the parts of
RFC5512 that have actually been implemented, such as the encapsulation EC.
Since BGP encapsulation attributes are now attached to routes, the
AFI/SAFI of the NLRI is already capable of indicating the payload
type of the advertised tunnel protocol.
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.
it seems unnecessary to allocate two additional type codes for
MPLS-in-UDP and IP-in-UDP.
I think I could argue this point either way:
- On the one hand ... When you are about to sending a particular payload
packet through a tunnel, you know whether the packet is MPLS or IP, so
you know enough to form the encapsulation correctly.
- On the other hand ... if you want the control plane to form the
rewrite string in advance, you might want to form a different rewrite
string for MPLS-in-GRE than for IP-in-GRE.
I would be good if we had some general rules for when it is good to
define a new tunnel type and when it is good to reuse an existing tunnel
type. Of course, we still need to maintain compatibility with the
tunnel types that are already defined.
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
