Hi Eric, > -----Original Message----- > From: Eric C Rosen [mailto:[email protected]] > Sent: Wednesday, July 29, 2015 12:35 AM > To: Xuxiaohu; [email protected]; [email protected]; BESS > Cc: [email protected]; [email protected]; > [email protected] > Subject: Re: [Idr] [bess] 2 week adoption call for > draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015) > > 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 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:) > > 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. If the Tunnel Encapsulation attribute associated with a labeled unicast route indicates UDP tunnels, should it be obvious that MPLS-in-UDP is supported by the originator of that labeled unicast route? Similarly, If the Tunnel Encapsulation attribute associated with a unlabeled IPvx unicast route indicates UDP tunnels, should it be obvious that IPvx-in-UDP is supported by the originator of that unlabeled unicast route? Best regards, Xiaohu > 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 [email protected] https://www.ietf.org/mailman/listinfo/bess
