Subject: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015)

From: "Susan Hares" <[email-masked]>
Date: Mon, 6 Jul 2015 21:07:34 -0400

This begins a 2 week adoption call on draft-rosen-idr-tunnel-encaps-00.txt
(7/6 to 7/20/2015).

The draft can be found at: 

https://www.ietf.org/internet-drafts/draft-rosen-idr-tunnel-encaps-00.txt

In your response, discuss why this draft proposal for encapsulation:

a)      [operators] will help deployed networks, 

b)      Solves know problems with other tunnel encapsulation, and 

c)       Provides a way to manage the matrix of tunnels.

We will have a status report at IDR on 7/20 on this Working group adoption
call. 

Sue Hares and John Scudder

---

From: John E Drake <[email-masked]>
Date: Tue, 7 Jul 2015 13:55:57 +0000

Support

Yours Irrespectively,

John

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, July 06, 2015 9:08 PM
To: 'idr wg list'
Cc: 'Keyur Patel (keyupate)'
Subject: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015)

This begins a 2 week adoption call on draft-rosen-idr-tunnel-encaps-00.txt (7/6 to 7/20/2015).
The draft can be found at:

We will have a status report at IDR on 7/20 on this Working group adoption call.

---

From: "Gaurav Dawra (gdawra)" <[email-masked]>
Date: Tue, 7 Jul 2015 14:18:26 +0000

Support

Regards,

On Jul 7, 2015, at 6:56 AM, John E Drake <[email-masked]<mailto:[email-masked]>> wrote:

Support

Yours Irrespectively,

John

Sue Hares and John Scudder
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 7 Jul 2015 14:28:05 +0000

I support this work as it provides a generalized solution for providing any BGP advertised service over all the common underlay technologies.
Thanks,
Acee

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 6, 2015 at 9:07 PM
To: 'idr wg list' <[email-masked]<mailto:[email-masked]>>
Cc: "Keyur Patel (keyupate)" <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015)

---

From: Haoweiguo <[email-masked]>
Date: Thu, 9 Jul 2015 11:55:40 +0000

Hi co-authors,

I think this work is useful to support more tunnel types among BGP PEs. For NVO3 network, VXLAN,NVGRE,VXLAN-GPE tunnel types are included in this draft.

There are also other candidate tunnel encapsulation such as GENEVE and GUE which are in progress. I am wondering why these tunnel types are not included in this draft?

Thanks,

weiguo

________________________________
From: Idr [[email-masked]] on behalf of Acee Lindem (acee) [[email-masked]]
Sent: Tuesday, July 07, 2015 22:28
To: Susan Hares; 'idr wg list'
Cc: Keyur Patel (keyupate)
Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015)

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 9 Jul 2015 11:10:11 -0400

On 7/9/2015 7:55 AM, Haoweiguo wrote:
> There are also other candidate tunnel encapsulation such as GENEVE and
> GUE which are in progress. I am wondering why these tunnel types are not
> included in this draft?

The set of tunnel types mentioned in the draft is not meant to be 
exhaustive; it really just reflects the interests of the authors and/or 
their customers.

No matter how many encapsulations one includes, there are always more 
;-)  But they don't all have to be described in the same draft.

---

From: Lucy yong <[email-masked]>
Date: Thu, 9 Jul 2015 22:16:05 +0000

Support WG adoption! This is very useful work. The need for BGP next hop and tunnel EP separation has been talked for a while.

The draft is quite new. We need think more on the mechanism and rules.

For example, is it necessary to require specifying a sub-TLV for each encapsulation type?

Comments:
Why does VXLAN encapsulation sub-TLV contain a MAC address, isn't the MAC carried by the NLRI?
It should support tunnel stitching at a router, i.e. the tunnel endpoint; upon receiving a UPDATE, the router removes the tunnel encapsulation TLV and/or sub-TLV on the UPDATE and inserts a new one prior to sending it out.
In the case of recursive next hop, does it require tunnel ingress router have the reachable for all the remote end points? IMO: it shouldn't.

Cheers,
Lucy

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, July 06, 2015 8:08 PM
To: 'idr wg list'
Cc: 'Keyur Patel (keyupate)'
Subject: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015)

---

From: Haoweiguo <[email-masked]>
Date: Fri, 10 Jul 2015 02:00:26 +0000

As for the MAC address advertisement mode, this draft seems to be conflicted with EVPN draft-ietf-bess-evpn-inter-subnet-forwarding-00. In the EVPN draft, if VXLAN/NVGRE tunnel is used, the remote NVE advertises its MAC through Router's MAC Extended Community, the MAC will be used as inner destination MAC for inter-subnet traffic forwarding.

Thanks,

weiguo

________________________________
From: Idr [[email-masked]] on behalf of Lucy yong [[email-masked]]
Sent: Friday, July 10, 2015 6:16
To: Susan Hares; 'idr wg list'
Cc: 'Keyur Patel (keyupate)'
Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015)

Comments:
Why does VXLAN encapsulation sub-TLV contain a MAC address, isn’t the MAC carried by the NLRI?
It should support tunnel stitching at a router, i.e. the tunnel endpoint; upon receiving a UPDATE, the router removes the tunnel encapsulation TLV and/or sub-TLV on the UPDATE and inserts a new one prior to sending it out.
In the case of recursive next hop, does it require tunnel ingress router have the reachable for all the remote end points? IMO: it shouldn’t.

Cheers,
Lucy

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Fri, 10 Jul 2015 08:02:56 +0000

I agree that we need some clarification on VXLAN encapsulation since the MAC does not make sense depending on the scenario. E.g. In most EVPN you don’t want any MAC encoding in this new attribute. In other scenario’s it might make more sense to include it

From: Idr on behalf of Lucy yong
Date: Friday 10 July 2015 00:16
To: Susan Hares, 'idr wg list'
Cc: Keyur Patel
Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015)

Comments:

Cheers,
Lucy

---

From: John E Drake <[email-masked]>
Date: Fri, 10 Jul 2015 13:53:27 +0000

Weiguo,

A number of the EVPN drafts use the RFC 5512 extended community and they will continue to do so.  As I'm sure you're aware, there is not a lot of room in an extended community, and this draft is intended to be used for future applications, e.g.,  EVPN, L3VPN, or Softwires, that need more room or more capabilities.

This is the same positioning that we used with the previous remote next hop draft which this draft replaces.

Yours Irrespectively,

John

From: Idr [mailto:[email-masked]] On Behalf Of Haoweiguo
Sent: Thursday, July 09, 2015 10:00 PM
To: Lucy yong; Susan Hares; 'idr wg list'
Cc: 'Keyur Patel (keyupate)'
Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015)

Thanks,

weiguo

Comments:

Cheers,
Lucy

---

From: Eric C Rosen <[email-masked]>
Date: Fri, 10 Jul 2015 16:12:45 -0400

> [Lucy] is it necessary to require specifying a sub-TLV for each
> encapsulation type?

No, it's not necessary for every tunnel type to have an encapsulation 
sub-TLV.

> [Lucy] Why does VXLAN encapsulation sub-TLV contain a MAC address, isn’t the
> MAC carried by the NLRI?

Consider the case where the application is L3VPN, but one wants to use 
VXLAN tunnels instead of MPLS tunnels.  You could signal this by 
attaching a Tunnel Encapsulation attribute to a VPN-IP route, where the 
attribute contains a TLV specifying a VXLAN tunnel.  But the NLRI of the 
VPN-IP route does not contain a MAC address.

>  [Wim] In most EVPN you don’t want any MAC encoding in this new attribute

There is a provision for omitting the MAC address in the VXLAN 
Encapsulation sub-TLV.   However, the text saying what to do if this MAC 
address is omitted seems to need correction.

> [Weiguo] As for the MAC address advertisement mode, this draft seems
> to be conflicted with EVPN
> draft-ietf-bess-evpn-inter-subnet-forwarding-00. In the EVPN draft,
> if VXLAN/NVGRE tunnel is used, the remote NVE advertises its MAC
> through Router's MAC Extended Community, the MAC will be used as
> inner destination MAC for inter-subnet traffic forwarding.

If I understand correctly, that draft uses the "Tunnel Type extended 
community" to signal that a VXLAN tunnel is needed, and then uses the 
"Router's MAC extended community" to signal the inner MAC DA.  If one 
attaches the Tunnel Encapsulation attribute to a particular UPDATE, one 
doesn't really need to also attach either of those two extended 
communities.  However, the tunnel encapsulation draft should say 
something about the case where both the Tunnel Encapsulation attribute 
(specifying a VXLAN tunnel) and the Router's MAC extended community are 
present.

Whether a particular application uses one way of signaling or the other 
is outside the scope of the tunnel encapsulation draft.

> [Lucy] It should support tunnel stitching at a router, i.e. the tunnel
> endpoint; upon receiving a UPDATE, the router removes the tunnel
> encapsulation TLV and/or sub-TLV on the UPDATE and inserts a new one
> prior to sending it out.

If some router is the receiving endpoint of one tunnel and the 
transmitting endpoint of another, I don't think anything in the draft 
prevents it from doing this sort of stitching.  Do you think additional 
mechanisms are needed?

> [Lucy] In the case of recursive next hop, does it require tunnel ingress router
> have the reachable for all the remote end points? IMO: it shouldn’t.

Do you have a particular scenario in mind?  I think the only requirement 
imposed by the draft is that you shouldn't try to use a particular 
tunnel if its remote endpoint is not reachable.

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Sat, 11 Jul 2015 07:42:58 +0000

<snip>

WH> this is the part that I am talking about indeed and we need to clarify a bit the scenario’s here such that we are clear what to do. Thx

<snip>

---

From: Haoweiguo <[email-masked]>
Date: Mon, 13 Jul 2015 01:11:57 +0000

Hi John,

I agree with you, the MAC extended community doesn't have sufficient room to carry more tunnel information. For current VXLAN and NVGRE tunnel encapsulation, the MAC extended community solution is applicable. Just as Eric points out, in the future, if both the Tunnel Encapsulation attribute (specifying a VXLAN tunnel) and the Router's MAC extended community  are present in a UPDATE, how to tackle this situation should be clearly defined in this draft, eg. the MAC extended community has more preference, or other recommendations.

Thanks,

weiguo

________________________________
From: John E Drake [[email-masked]]
Sent: Friday, July 10, 2015 21:53
To: Haoweiguo; Lucy yong; Susan Hares; 'idr wg list'
Cc: 'Keyur Patel (keyupate)'
Subject: RE: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015)

Weiguo,

A number of the EVPN drafts use the RFC 5512 extended community and they will continue to do so.  As I’m sure you’re aware, there is not a lot of room in an extended community, and this draft is intended to be used for future applications, e.g.,  EVPN, L3VPN, or Softwires, that need more room or more capabilities.

Yours Irrespectively,

John

Thanks,

weiguo

Comments:

Cheers,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Mon, 13 Jul 2015 15:28:45 +0000

Hi Eric,

Please see inline below.

-----Original Message-----
From: Eric C Rosen [mailto:[email-masked]] 
Sent: Friday, July 10, 2015 3:13 PM
To: Lucy yong; Susan Hares; 'idr wg list'; Haoweiguo; Henderickx, Wim (Wim)
Cc: [email-masked]; 'Keyur Patel (keyupate)'
Subject: Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015)

> [Lucy] is it necessary to require specifying a sub-TLV for each 

No, it's not necessary for every tunnel type to have an encapsulation sub-TLV.
[Lucy] Will each potential used encapsulation need a sub-TLV? If not, why some are required and some are not, do we need a code point for these that are not required?

> [Lucy] Why does VXLAN encapsulation sub-TLV contain a MAC address, 
> isn't the MAC carried by the NLRI?

Consider the case where the application is L3VPN, but one wants to use VXLAN tunnels instead of MPLS tunnels.  You could signal this by attaching a Tunnel Encapsulation attribute to a VPN-IP route, where the attribute contains a TLV specifying a VXLAN tunnel.  But the NLRI of the VPN-IP route does not contain a MAC address.
[Lucy] I see. Do we want to open the door for this or require using other encapsulation type for L3VPN?

>  [Wim] In most EVPN you don't want any MAC encoding in this new 
> attribute

There is a provision for omitting the MAC address in the VXLAN 
Encapsulation sub-TLV.   However, the text saying what to do if this MAC 
address is omitted seems to need correction.
[Lucy] yes. If the flag is clear, the corresponding field MUST NOT be present.

> draft-ietf-bess-evpn-inter-subnet-forwarding-00. In the EVPN draft, if 
> VXLAN/NVGRE tunnel is used, the remote NVE advertises its MAC through 
> Router's MAC Extended Community, the MAC will be used as inner 
> destination MAC for inter-subnet traffic forwarding.

If I understand correctly, that draft uses the "Tunnel Type extended community" to signal that a VXLAN tunnel is needed, and then uses the "Router's MAC extended community" to signal the inner MAC DA.  If one attaches the Tunnel Encapsulation attribute to a particular UPDATE, one doesn't really need to also attach either of those two extended communities.  However, the tunnel encapsulation draft should say something about the case where both the Tunnel Encapsulation attribute (specifying a VXLAN tunnel) and the Router's MAC extended community are present.
[Lucy] Should we consider deprecate "Tunnel Type extended community"?

Whether a particular application uses one way of signaling or the other is outside the scope of the tunnel encapsulation draft.

> encapsulation TLV and/or sub-TLV on the UPDATE and inserts a new one 

If some router is the receiving endpoint of one tunnel and the transmitting endpoint of another, I don't think anything in the draft prevents it from doing this sort of stitching.  Do you think additional mechanisms are needed?
[Lucy] There are two scenarios: 1) if the receiving endpoint of a tunnel has the capability for overlay routing/forwarding, the endpoint can set itself as transmitting endpoint of another; 2) if the receiving endpoint of a tunnel does not have capability for overlay routing/forwarding, in order to set itself as transmitting endpoint of another, it needs to allocate an IP address that is associated to the previous tunnel transmitting endpoint and insert this IP address as the transmitting endpoint of another. Please see draft-hao-bess-inter-nvo3-vpn. It is good for the draft to describe these mechanisms at a router.  

> [Lucy] In the case of recursive next hop, does it require tunnel 
> ingress router have the reachable for all the remote end points? IMO: it shouldn't.

Do you have a particular scenario in mind?  I think the only requirement imposed by the draft is that you shouldn't try to use a particular tunnel if its remote endpoint is not reachable.
[Lucy] This can be applied to the case as of Inter-AS option C. But use one BGP protocol to establish tunnels instead of two BGPs (EBGP and MP-BGP). Let's talk more offline.

Thanks,
Lucy

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 18 Jul 2015 04:45:53 -0400

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

---

From: <[email-masked]>
Date: Thu, 23 Jul 2015 16:45:50 +0200

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:
> [email-masked]

_________________________________________________________________________________________________________________________

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.

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 24 Jul 2015 08:40:17 +0000

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 [[email-masked]] 代表 [email-masked] [[email-masked]]
发送时间: 2015年7月23日 22:45
收件人: [email-masked]; BESS
抄送: [email-masked]; [email-masked]
主题: Re: [bess] [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015)

Hi,

Best,

-Thomas

_______________________________________________
BESS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bess

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 28 Jul 2015 12:08:18 -0400

> and RFC7432 with a consistent way of advertising the encapsulations,I

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").

> 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? ;-)
> draft-rosen-idr-tunnel-encaps

I think that makes sense.
> 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.

> (value 11) (like section 2.2.5 does for the attribute)

Makes sense.

> BESS working group involved all along the life of this draft.

No problem.

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 28 Jul 2015 12:35:29 -0400

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 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.

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.

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 29 Jul 2015 02:59:59 +0000

Hi Eric,

> Sent: Wednesday, July 29, 2015 12:35 AM
> To: Xuxiaohu; [email-masked]; [email-masked]; BESS
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [Idr] [bess] 2 week adoption call for
> draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015)
> 
> 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 ;-)
> 
> Quite a few people have suggested that RFC5512 should be obsoleted by the
> tunnel encaps draft; this is worth considering.
> 
> > 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:)

> - 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.

---

From: <[email-masked]>
Date: Wed, 29 Jul 2015 11:44:24 +0200

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
>
> "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

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.

>> 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
>

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
>

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

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 29 Jul 2015 11:27:19 -0400

>> [Eric] 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.

> [Xiaohu] 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:)

No; see section 5 ("Recursive Next Hop Resolution") of the new draft.

I think there are other examples where one might not be able to infer 
the type of the payload from the AFI/SAFI of the route.  Suppose you use 
BGP as your only routing algorithm, and you use only the unlabeled 
address families (AFI/SAFI = 1/1 or 2/1).  But you use LDP (or SDN or 
something else) to assign labels to prefixes.  In this case, your data 
traffic might be MPLS, but there is no use of the labeled address 
families (AFI/SAFI = 1/4, 2/4, 1/128, or 2/128).  If you use the Tunnel 
Encapsulation attribute to specify a GRE tunnel for some route, you 
could end up having to do an MPLS-in-GRE encapsulation.

I'm not sure whether there is a real use case for this, but I'm not also 
not sure that we want to rule it out.