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
[email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/bess
