Hi Eric,
2015-07-28, Eric C Rosen:
* 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.
Or even a payload-in-something-else, but yes, we agree: covering ingress
replication with the BGP Tunnel Encap makes sense (and will actually be
required by draft-ietf-bess-evpn-overlay).
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?
For sake of simplicity I omitted that aspect in my initial comment, but
yes indeed, not everything does make sense.
I think that in the case where the Tunnel Type is an IP Multicast tree
*without* the PMSI Tunnel Attribute Label field being set, jointly
advertising a BGP Tunnel Encap attribute could be defined, for the
MPLS-in-UDP or VXLAN types, as meaning "I will send PMSI traffic as
MPLS-in-UDP or VXLAN" (rather than the GRE default).
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").
A possibility would be to state that if Tunnel Type is an IP Multicast
tree *with* the PMSI Tunnel Attribute Label field set, jointly
advertising a BGP Tunnel Encap attribute could be used to allow
MPLS-in-GRE (or UDP, or VXLAN) and hence allow carrying the multicast
traffic of multiple VPNs in one IP multicast tree.
These proposals would allow to give a meaningful semantic to the BGP
Tunnel Encap attribute with mVPN or E-VPN PMSI routes, independently of
any consideration on how relevant these encapsulations would be.
* 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.
I think this is a good idea.
Or would this introduce an incompatibility with some other EVPN
draft? ;-)
None that I'm aware of.
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.
Ok.
* 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.
This does not seem consistent with allowing that the use of the Tunnel
Encap EC with a semantic of an implicit BGP Tunnel Encap attribute with
w.y.z TLVs/sub-TLVs.
* 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.
Ok.
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.
Thank you,
-Thomas
_________________________________________________________________________________________________________________________
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
