* 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
In the particular case where (a) the PMSI Tunnel attribute specifies
"Ingress Replication", and (b) the PMSI Tunnel attribute carries an MPLS
label, then I think it might well make sense to include a Tunnel
Encapsulation attribute. This would allow one to use an
MPLS-in-something-else encapsulation to do ingress replication.
In other cases, I don't really know what it would mean to have both a
PMSI Tunnel attribute and a Tunnel Encapsulation attribute on the same
route. Suppose the PMSI Tunnel attribute specifies an mLDP-created P2MP
LSP, and the Tunnel Encapsulation attribute specifies a VXLAN tunnel.
What would that mean?
Another issue is the following. In MVPN the transmitter specifies the
tunnel type, but the Tunnel Encapsulation attribute is most useful in
scenarios where the receiver needs to specify the tunnel type. (Ingress
replication is an exception, since it requires both a multipoint tunnel
and a set of unicast tunnels, as is discussed in draft-ietf-bess-ir. So
in that particular case, it makes sense for the transmitter to specify
the former and the receivers to specify the latter.)
It's also worth noting that except for ingress replication, a label is
specified in the PMSI Tunnel attribute only if traffic from multiple
VPNs is going to share the same multicast tunnel; this is not really
analogous to the label that is embedded in the case of SAFI 4 ("Labeled
IP Unicast") or SAFI 128 ("Labeled VPN-IP unicast").
* 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
Right now the Tunnel Encaps draft specifies that omitting the Embedded
Label Handling Sub-TLV is equivalent to including an Embedded Label
Handling Sub-TLV with value 1. The simplest fix would be to change this
so that omitting the Sub-TLV is equivalent to including a Sub-TLV with
value 2. Or would this introduce an incompatibility with some other
EVPN draft? ;-)
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
I think that makes sense.
* 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
Some folks have expressed the opinion that the BGP procedures for
handling errors in this attribute will be simplified if the Remote
Endpoint Sub-TLV is always required to be present. I don't have a
strong opinion about that myself.
* 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)
Makes sense.
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.
No problem.
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
