Hi all, The major rationale of the BGP Encap SAFI is as follows:
"Since the encapsulation information is coded as an attribute, one could ask whether a new SAFI is really required. After all, a BGP speaker could simply attach the tunnel encapsulation attribute to each prefix (like Q in our example) that it advertises. But with that technique, any change in the encapsulation information would cause a very large number of updates. Unless one really wants to specify different encapsulation information for each prefix, it is much better to have a mechanism in which a change in the encapsulation information causes a BGP speaker to advertise only a single update. Conversely, when prefixes get modified, the tunnel encapsulation information need not be exchanged."---RFC5512 Now it seems that the above rationale has been shaked by this draft. 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. 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. For example, if a BGP encapsulation attribute indicating the UDP tunnel is attached to a labeled route, it would be obvious that MPLS-in-UDP is supported by the originator of that route. If that particular attribute is attached to a unlabeled route, it obviously indicates that IP-in-UDP is supported. As such, it seems unnecessary to allocate two additional type codes for MPLS-in-UDP and IP-in-UDP. Best regards, Xiaohu ________________________________________ 发件人: BESS [bess-boun...@ietf.org] 代表 thomas.mo...@orange.com [thomas.mo...@orange.com] 发送时间: 2015年7月23日 22:45 收件人: i...@ietf.org; BESS 抄送: draft-ietf-bess-evpn-over...@tools.ietf.org; draft-rosen-idr-tunnel-enc...@tools.ietf.org 主题: Re: [bess] [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015) Hi, I think this draft will be a very useful tool to address different topics, in particular topics related to we integrate encapsulations over an IP transit with BGP VPNs, and I support its adoption by IDR. That said, I have the following comments that need to be addressed: * to allow multicast support in the context of RFC6514/6513, RFC7117, and RFC7432 with a consistent way of advertising the encapsulations, I think that draft-rosen-idr-tunnel-encaps-00 section 2.4 should also consider as a "labelled address family" an AFI/SAFI that may be associated to a PMSI Tunnel attribute, in which case the "embedded label" is the Label in the PMSI Tunnel Attribute * consistently with the above, 1/5 and 25/8 should also be added as authorized families in section 3 * draft-ietf-bess-evpn-overlay currently relies on the Tunnel Encap Extended Community to advertise the use of MPLS-over-GRE or VXLAN or NVGRE, and section 5.1.3 of that draft specifies that the VNI to use is the value in the Label field of the route -- this is I believe /nearly/ inline with draft-rosen-idr-tunnel-encaps, but the devil is in the details: if I read correctly draft-rosen-idr-tunnel-encaps-01 Section 7.2, the behavior consisting in using the embedded label as the VNI requires advertising a BGP Tunnel Encap Attribute with an Embedded Label Handling Sub-TLV with value 2, or not advertising a BGP Tunnel Encap at all (nor using the Tunnel Encapsulation ExtendedCommunity which is made semantically equivalent by section 6) --- it thus seems to me that one of the two drafts needs something to allow proper compatibility With a lesser priority, I have a few other comments as well: * I think the intent of the MPLS codepoint 10 for tunnel type, as defined in draft-ietf-bess-evpn-overlay, intends to indicate the ability to receive plain MPLS in a context where other encaps are advertised (if you advertise only one non-MPLS encap, it means you support this encap but not MPLS) -- this I think would be nice to capture in draft-rosen-idr-tunnel-encaps * about the Remote Endpoint sub-TLV: why allow that an AF of 0 means "use next-hop address", but still require the presence of the TLV ? it seems that its absence could conveniently be interpreted as "use next-hop address", like what's done for the Tunnel Encap EC in section 6 * section 6 should say that, associated to a labelled address family, the Tunnel Encap EC of value GRE (2) means the same as MPLS-in-GRE (value 11) (like section 2.2.5 does for the attribute) And my second head, the one trying to fill my BESS co-chair hat, can't help adding that addressing some of the above will require keeping the BESS working group involved all along the life of this draft. Best, -Thomas Susan Hares: > Based on the BESS chairs request this adoption call will be extended 2 weeks > to 7/31 for BESS WG membesr to comment. > > Sue Hares > > _______________________________________________ > Idr mailing list > i...@ietf.org > https://www.ietf.org/mailman/listinfo/idr _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
