Subject: [Idr] 答复: draft-rosen-tunnel-encaps-00.txt

From: Lizhenbin <[email-masked]>
Date: Fri, 3 Jul 2015 17:32:40 +0000

Hi Eric,

I think the draft is useful in many application scenarios. In fact, we have proposed the draft draft-li-idr-mpls-path-programming-01 in which we also wanted to

introduce the tunnel attributes which can be applied to multiple BGP AFI/SAFIs. According to our usecase, the tunnel considered in the draft are almost MPLS tunnels.

According to my understanding, for the draft draft-rosen-tunnel-encaps-00 I think the tunnel types defined here are almost IP tunnels used for data center scenarios.

When I tracked to RFC 5512, it also only defined IP tunnels. I am not familiar with the history of the RFC.  Could you help explain why MPLS tunnels are not taken

into account at that time or maybe MPLS tunnels are considered in other drafts/RFCs?

Thanks & Regards,

Zhenbin(Robin)

________________________________
发件人: Idr [[email-masked]] 代表 Keyur Patel (keyupate) [[email-masked]]
发送时间: 2015年6月30日 2:16
收件人: [email-masked]
主题: [Idr] draft-rosen-tunnel-encaps-00.txt

Folks,

We have posted a new tunnel encapsulation attribute draft known as draft-rosen-tunnel-encaps-00.txt.

This draft addresses all the concerns and questions that were raised during the WG acceptance call of draft-vandevelde-idr-remote-next-hop.

Please provide comments/suggestions.

Best Regards,
Keyur

https://tools.ietf.org/html/draft-rosen-idr-tunnel-encaps-00

---

From: Lizhenbin <[email-masked]>
Date: Fri, 3 Jul 2015 18:08:41 +0000

Hi Authors,

I have following comments regarding the draft:

1. Can you propose one section to introduce the usecases or requirements for these BGP extensions proposed by the draft?

2. For the Remote Endpoint Sub-TLV in Section 2.1, why is the AS number sub-field is introduced? I think in most cases maybe the AS number is not necessary.

3. Section 2.1: "   There is one special case: the Remote Endpoint sub-TLV MAY have a
   value field consisting entirely of zeroes.  This means that the
   tunnel's remote endpoint is the UPDATE's BGP next hop."

I think the special case may be just to waste process. Can it be removed?

4. For the MPLS-in-GRE in section 2.2.5, the draft introduced that it is equivalent to  including a TLV of the GRE tunnel type that
   also includes a Protocol Type sub-TLV ([RFC5512]) specifying MPLS as the protocol to be encapsulated.  I think the equivalence is better.

   We should not define tunnel types combining the tunnel types and the protocol types encapsulated. It is apparent that the MPLS-in-GRE tunnel types

   definition is different from other tunnel types. And by defining tunnel types combining the tunnel types and the protocol types encapsulated, it may introduce more

   tunnel types which will propose unnecessary debates.

5. Regarding IANA Considerations in section 10 "IANA is requested to add this document as a reference for tunnel
   types 8-13 in the "BGP Tunnel Encapsulation Tunnel Types" registry.", in the draft I have not seen what tunnel types do the number 8-13 indicated in the draft.

   Maybe I missed something.

Best Regards,

Zhenbin(Robin)

Folks,

Best Regards,
Keyur

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 7 Jul 2015 13:22:59 -0400

On 7/3/2015 1:32 PM, Lizhenbin wrote:
> According to my understanding, for the draft
> draft-rosen-tunnel-encaps-00 I think the tunnel types defined here
> are almost all IP tunnels used for data center scenarios.
>
> When I tracked to RFC 5512, it also only defined IP tunnels. I am
> not familiar with the history of the RFC.

RFC 5565 ("Softwire Mesh Framework") describes the use cases that we
were thinking about at the time RFC 5512 was written.

> Could you help explain why MPLS tunnels are not taken

BGP and LDP already have widely deployed methods of distributing
"service labels" for MPLS-based applications.  Typically MPLS-based 
applications run over an infrastructure where MPLS is enabled for 
transport and used by default. So there is no need for the egress node 
to use BGP to signal that it wants the ingress node to use an MPLS tunnel.

Note that the scenarios discussed in RFC 5565 could easily have been
handled with existing MPLS techniques ("6PE", "4PE"), but there was a
requirement to use non-MPLS tunnels for some reason.

> For the Remote Endpoint Sub-TLV in Section 2.1, why is the AS number
>  sub-field is introduced?

To support the security techniques discussed in section 11 of the draft.

> Section 2.1: "   There is one special case: the Remote Endpoint
> sub-TLV MAY have a value field consisting entirely of zeroes.  This
> means that the tunnel's remote endpoint is the UPDATE's BGP next
> hop."
>

You might be right, but the thinking here is that it is good to have a
special value of the Remote Endpoint sub-TLV that just means "next hop
address".  One alternative would be to omit the sub-TLV entirely if you
want the tunnel to go to the next hop.  However, that would complicate
the error processing (ability to detect malformed TLVs).  Another 
alternative would be to encode the IP address of the next hop in the 
sub-TLV.  But that introduces some issues if the next hop is changed 
while the route is being distributed.

BTW, the format of the Remote Endpoint sub-TLV has been changed in the 
latest rev, in order to explicitly indicate the address family of the 
remote endpoint address.

> For the MPLS-in-GRE in section 2.2.5, the draft introduced that it is
> equivalent to  including a TLV of the GRE tunnel type that also
> includes a Protocol Type sub-TLV ([RFC5512]) specifying MPLS as the
> protocol to be encapsulated.  I think the equivalence is better.
>
> We should not define tunnel types combining the tunnel types and the
>  protocol types encapsulated. It is apparent that the MPLS-in-GRE
> tunnel types definition is different from other tunnel types. And by
> defining tunnel types combining the tunnel types and the protocol
> types encapsulated, it may introduce more tunnel types which will
> propose unnecessary debates.

I agree with you, but I didn't win that argument ;-)  I suspect that
folks want to be able to say "of course we can encapsulate MPLS in GRE;
we even have a tunnel type specifically for doing that."

> Regarding IANA Considerations in section 10 "IANA is requested to add
> this document as a reference for tunnel types 8-13 in the "BGP Tunnel
> Encapsulation Tunnel Types" registry.", in the draft I have not seen
> what tunnel types do the number 8-13 indicated in the draft.

These codepoints have already been allocated by IANA and can be found in 
the BGP Tunnel Encapsulation Tunnel Types registry.  I've changed the 
text to the following:

    IANA is requested to add this document as a reference for tunnel
    types 8 (VXLAN), 9 (NVGRE), 11 (MPLS-in-GRE), and 12 (VXLAN-GPE) in
    the "BGP Tunnel Encapsulation Tunnel Types" registry.