Subject: [Idr] I-D Action: draft-rosen-idr-tunnel-encaps-03.txt

From: [email-masked]
Date: Thu, 06 Aug 2015 12:17:37 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

        Title           : Using the BGP Tunnel Encapsulation Attribute without the BGP Encapsulation SAFI
        Authors         : Eric C. Rosen
                          Keyur Patel
                          Gunter Van de Velde
	Filename        : draft-rosen-idr-tunnel-encaps-03.txt
	Pages           : 29
	Date            : 2015-08-06

Abstract:
   RFC 5512 defines a BGP Path Attribute known as the "Tunnel
   Encapsulation Attribute".  This attribute allows one to specify a set
   of tunnels.  For each such tunnel, the attribute can provide
   additional information used to create a tunnel and the corresponding
   encapsulation header, and can also provide information that aids in
   choosing whether a particular packet is to be sent through a
   particular tunnel.  RFC 5512 states that the attribute is only
   carried in BGP UPDATEs that have the "Encapsulation Subsequent
   Address Family (Encapsulation SAFI)".  This document updates RFC 5512
   by deprecating the Encapsulation SAFI (which has never been used),and
   by specifying semantics for the attribute when it is carried in
   UPDATEs of certain other SAFIs.  This document also extends the
   attribute by enabling it to carry additional information needed to
   create the encapsulation headers additional tunnel types not
   mentioned in RFC 5512.  Finally, this document also extends the
   attribute by allowing it to specify a remote tunnel endpoint address
   for each tunnel.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-rosen-idr-tunnel-encaps/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-rosen-idr-tunnel-encaps-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-rosen-idr-tunnel-encaps-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 7 Aug 2015 01:50:51 +0000

Hi co-authors,

Thanks for this update which looks much better.

I still have three questions as follows:

1. This draft assumes that NVGRE adopts the same approach to carrying IP traffic as VXLAN. However, NVGRE has a protocol field and therefore it could directly carry IP traffic w/o adding the fake Ethernet header between the IP payload and the GRE header (see https://www.ietf.org/mail-archive/web/nvo3/current/msg01520.html and http://tools.ietf.org/html/draft-yong-l3vpn-nvgre-vxlan-encap-03#page-3.) Hence, how about considering the simpler layer3 overlay for NVGRE?

2. It said "...Note that if none of the TLVs specifies the MPLS tunnel type, a Label
   Switched Path SHOULD NOT be used." IMO, since the LSP is signaled by label distribution protocols such as LDP, RSVP-TE or L-BGP, why is it still necessary to specify the tunnel encapsulation attribute to indicate whether or not an LSP should be used.

3. Since this draft has mentioned the encapsulation of MPLS over VXLAN/NVGRE, would you please give any clue to the scenario of this special encapsulation?

Best regards,
Xiaohu

> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Friday, August 07, 2015 3:18 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Idr] I-D Action: draft-rosen-idr-tunnel-encaps-03.txt
> 
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 17 Aug 2015 14:12:48 -0400

On 8/6/2015 9:50 PM, Xuxiaohu wrote:
> 1. This draft assumes that NVGRE adopts the same approach to carrying
> IP traffic as VXLAN. However, NVGRE has a protocol field and
> therefore it could directly carry IP traffic w/o adding the fake
> Ethernet header between the IP payload and the GRE header (see
> https://www.ietf.org/mail-archive/web/nvo3/current/msg01520.html and
> http://tools.ietf.org/html/draft-yong-l3vpn-nvgre-vxlan-encap-03#page-3.)
> Hence, how about considering the simpler layer3 overlay for NVGRE?

Our reference for the NVGRE encapsulation was 
draft-sridharan-virtualization-nvgre-08.txt, which is now on the RFC 
Editor's queue for publication as an Informational draft in the 
"Independent Submissions" stream.  That RFC-to-be only discusses the use 
of NVGRE to carry ethernet frames.  Draft-yong-l3vpn-nvgre-vxlan-encap 
discusses the use of NVGRE to carry IP packets (analogous to VXLAN-GPE), 
but that draft is expired.

I have no objection to incorporating the idea of draft-yong into the 
tunnel-encaps draft, if that's what the relevant WGs support, but it 
would be nice to see some further discussion first.

>
> 2. It said "...Note that if none of the TLVs specifies the MPLS
> tunnel type, a Label Switched Path SHOULD NOT be used." IMO, since
> the LSP is signaled by label distribution protocols such as LDP,
> RSVP-TE or L-BGP, why is it still necessary to specify the tunnel
> encapsulation attribute to indicate whether or not an LSP should be
> used.

If the tunnel encapsulation attribute is present, identifying one or 
more tunnel types, the semantics are that one should try to send packets 
through one of the identified tunnel types (if possible).  So if MPLS is 
not specified as one of the tunnel types, the use of an MPLS LSP for 
transport would have to be avoided.  The presence of a TLV identifying 
an MPLS tunnel type would indicate that the use of an MPLS transport 
tunnel is one of the permissible options for transmitting the packets.

> 3. Since this draft has mentioned the encapsulation of MPLS over
> VXLAN/NVGRE, would you please give any clue to the scenario of this
> special encapsulation?

Any IP-based overlay should be able to pass an MPLS packet with an 
arbitrary label stack.