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

From: <[email-masked]>
Date: Wed, 15 Jul 2015 16:29:42 +0200

Hi everyone,

This is "heads up" on draft-rosen-idr-tunnel-encaps-00 which is 
currently being called for adoption by the IDR working group.
The call lasts until July 20th, and you are encouraged to comment on IDR 
mailing-list as you find relevant.

Best,

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

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]>
To: 'idr wg list' <[email-masked]>
Cc: "'Keyur Patel (keyupate)'" <[email-masked]>
Date: Mon, 6 Jul 2015 21:07:34 -0400
List-Id: Inter-Domain Routing <idr.ietf.org>

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

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

---

From: <[email-masked]>
Date: Sat, 18 Jul 2015 15:36:43 +0000

Hi everyone,

IDR chairs have extended the ongoing call for adoption of draft-rosen-idr-tunnel-encaps by IDR, to let BESS participants who would have missed it,  comment on this call.

Please read this proposal tightly related to BESS work, and send comments to IDR mailing list.

-Thomas & Martin

---- Message original ----
Objet : Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015)
Envoyé : 18 juil. 2015 10:46
De : Susan Hares <[email-masked]>
À : 'idr wg list' <[email-masked]>
Cc : "'Keyur Patel (keyupate)'" <[email-masked]>

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

---

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: Ravi Shekhar <[email-masked]>
Date: Fri, 24 Jul 2015 17:27:57 +0000

I support adoption of draft so that newer IP fabric based encapsulation methods more commonly used in data-centers(VxLAN) can be applied for L3VPN signaling. Currently, a subset of L3VPN functionality can also be achieved using EVPN-based-prefix-distribution( over VxLAN/NvGRE). While EVPN has its place in L2 and L3 host route distribution, L3VPN is a widely deployed and mature technology for prefix distribution. As a result, a lot of customers would like to continue to use L3VPN signaling for prefix distribution, but over IP fabric based DCs. This draft fills that gap.

Thanks.

-        Ravi.

From: BESS [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Saturday, July 18, 2015 8:37 AM
To: [email-masked]
Subject: [bess] Extended adoption call in IDR for draft-rosen-idr-tunnel-encaps-00

Hi everyone,

-Thomas & Martin

---- Message original ----
Objet : Re: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015)
Envoyé : 18 juil. 2015 10:46
De : Susan Hares <[email-masked]<mailto:[email-masked]>>
À : 'idr wg list' <[email-masked]<mailto:[email-masked]>>
Cc : "'Keyur Patel (keyupate)'" <[email-masked]<mailto:[email-masked]>>

Sue Hares

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

Thank you.

---

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,

> -----Original Message-----
> From: Eric C Rosen [mailto:[email-masked]]
> 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.