Subject: [bess] Fw: New Version Notification for draft-li-bess-4pe-01.txt

From: "[email-masked]" <[email-masked]>
Date: Wed, 9 Mar 2016 11:37:09 +0800

Hello all,

I update my draft. 4PE is introduced in this doc to meet the gap pointed out in RFC7439. 4PE routers in IPv6-only MPLS network can use MP-BGP extended in this doc to connect IPv4-only islands.. Your comments are very appreciated.

[email-masked]
 
From: internet-drafts
Date: 2016-03-09 09:54
To: Zhenqiang Li
Subject: New Version Notification for draft-li-bess-4pe-01.txt
 
A new version of I-D, draft-li-bess-4pe-01.txt
has been successfully submitted by Zhenqiang Li and posted to the
IETF repository.
 
Name: draft-li-bess-4pe
Revision: 01
Title: Connecting IPv4 Islands over IPv6 MPLS Using IPv4 Provider Edge Routers (4PE)
Document date: 2016-03-08
Group: Individual Submission
Pages: 9
URL:            https://www.ietf.org/internet-drafts/draft-li-bess-4pe-01.txt
Status:         https://datatracker.ietf.org/doc/draft-li-bess-4pe/
Htmlized:       https://tools.ietf.org/html/draft-li-bess-4pe-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-li-bess-4pe-01
 
Abstract:
   This document explains how to interconnect IPv4 islands over a
   Multiprotocol Label Switching (MPLS)-enabled IPv6-only core.  This
   approach relies on IPv4 Provider Edge routers (4PE), which are Dual
   Stacks in order to connect to IPv4 islands and to the MPLS core.  The
   4PE routers exchange the IPv4 reachability information transparently
   over the core using the Multiprotocol Border Gateway Protocol (MP-
   BGP).  MP-BGP is extended to do this.  A new Subsequence Address
   Family Identifier (SAFI) with corresponding new format Network Layer
   Reachability Information (NLRI), is introduced.  The BGP Next Hop
   field is used to convey the IPv4 address of the 4PE router, a field
   is added in Network Layer Reachability Information (NLRI) to convey
   the IPv6 address of the 4PE router, so that dynamically established
   IPv6-signaled MPLS Label Switched Paths (LSPs) can be used without
   explicit tunnel configuration.

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.
 
The IETF Secretariat

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 9 Mar 2016 10:44:27 -0500

I think this problem is already solved in RFC 5549.

RFC 5549 specifies the procedures for creating a route with IPv4 or 
VPN-IPv4 NLRI and an IPv6 next hop, which should provide both 4PE and 
4vPE functionality.

Your proposal seems to differ, in that it puts the v6 next hop address 
in the NLRI, rather than in the next hop field.  I don't think it makes 
much sense to put the next hop address in the NLRI, as that would then 
require a special set of rules for bestpath selection.

On 3/8/2016 10:37 PM, [email-masked] wrote:
> Hello all,
>
> I update my draft. 4PE is introduced in this doc to meet the gap 
> pointed out in RFC7439. 4PE routers in IPv6-only MPLS network can use 
> MP-BGP extended in this doc to connect IPv4-only islands.. Your 
> comments are very appreciated.
>
> ------------------------------------------------------------------------
> [email-masked]
>
>     *From:* internet-drafts <mailto:[email-masked]>
>     *Date:* 2016-03-09 09:54
>     *To:* Zhenqiang Li <mailto:[email-masked]>
>     *Subject:* New Version Notification for draft-li-bess-4pe-01.txt
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 10 Mar 2016 17:32:10 +0800

Thank you very much for your comments, Eric.

Yes, RFC5549 does specify the  procedures for creating a route with IPv4 or VPN-IPv4 NLRI and an IPv6 next hop. IPv4 NLRI with IPv6 next hop is for the situation where an IPv6-only network conneting IPv4-only islands. VPN-IPv4 NLRI with IPv6 next hop is for the 4vPE situation.

What I want to solve is the 4PE situation, where an IPv6-only network running with MPLS connecting the IPv4-only islands. The routes in the 4PE NLRI have labels assigned by the 4PE routers.

Besides, 4PE routers need both IPv4 next hop and IPv6 next hop to build their IPv4 routing table and IPv6 routing table respectively.

[email-masked]
 
From: Eric C Rosen
Date: 2016-03-09 23:44
To: [email-masked]; bess
Subject: Re: [bess] Fw: New Version Notification for draft-li-bess-4pe-01.txt
I think this problem is already solved in RFC 5549.

RFC 5549 specifies the procedures for creating a route with IPv4 or VPN-IPv4 NLRI and an IPv6 next hop, which should provide both 4PE and 4vPE functionality.  

Your proposal seems to differ, in that it puts the v6 next hop address in the NLRI, rather than in the next hop field.  I don't think it makes much sense to put the next hop address in the NLRI, as that would then require a special set of rules for bestpath selection.

[email-masked]
 
From: internet-drafts
Date: 2016-03-09 09:54
To: Zhenqiang Li

Name: draft-li-bess-4pe
Revision: 01
 
Abstract:

 
The IETF Secretariat

---

From: Zhuangshunwan <[email-masked]>
Date: Fri, 11 Mar 2016 08:18:44 +0000

I have read this document, and I think that it is a useful solution to connect the IPv4-only islands across the IPv6-only network running with MPLS.

Regards,
Shunwan

发件人: BESS [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2016年3月10日 17:32
收件人: Eric C Rosen; bess
主题: Re: [bess] Fw: New Version Notification for draft-li-bess-4pe-01.txt

________________________________
[email-masked]<mailto:[email-masked]>

From: Eric C Rosen<mailto:[email-masked]>
Date: 2016-03-09 23:44
To: [email-masked]<mailto:[email-masked]>; bess<mailto:[email-masked]>
Subject: Re: [bess] Fw: New Version Notification for draft-li-bess-4pe-01.txt
I think this problem is already solved in RFC 5549.

Your proposal seems to differ, in that it puts the v6 next hop address in the NLRI, rather than in the next hop field.  I don't think it makes much sense to put the next hop address in the NLRI, as that would then require a special set of rules for bestpath selection.
On 3/8/2016 10:37 PM, [email-masked]<mailto:[email-masked]> wrote:
Hello all,

________________________________
[email-masked]<mailto:[email-masked]>

From: internet-drafts<mailto:[email-masked]>
Date: 2016-03-09 09:54
To: Zhenqiang Li<mailto:[email-masked]>
Subject: New Version Notification for draft-li-bess-4pe-01.txt

Name: draft-li-bess-4pe
Revision: 01

Abstract:

The IETF Secretariat

BESS mailing list

[email-masked]<mailto:[email-masked]>

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 14 Mar 2016 15:48:57 -0400

On 3/10/2016 4:32 AM, [email-masked] wrote:
> Yes, RFC5549 does specify the procedures for creating a route with 
> IPv4 or VPN-IPv4 NLRI and an IPv6 next hop. IPv4 NLRI with IPv6 next 
> hop is for the situation where an IPv6-only network conneting 
> IPv4-only islands. VPN-IPv4 NLRI with IPv6 next hop is for the 4vPE 
> situation.
>
> What I want to solve is the 4PE situation, where an IPv6-only network 
> running with MPLS connecting the IPv4-only islands. The routes in the 
> 4PE NLRI have labels assigned by the 4PE routers.

RFC 5549 will work when the IPv6-only network runs MPLS.

If you want the 4PE routers to send labeled IPv4 routes to each other, 
they just need to use SAFI 4.

If the core runs only IPv6/MPLS, and the next hop of a 4PE route is an 
IPv4 address, I don't really see how the next hop resolution is going to 
work, as the next hop (a v4 address) will not appear to be reachable 
through the v6 core.

I think your proposal really is intended to treat the v6 address in the 
NLRI as the next hop.  But that leaves open the question of why you want 
to put the next hop address in the NLRI field instead of in the next hop 
field.

>
> Besides, 4PE routers need both IPv4 next hop and IPv6 next hop to 
> build their IPv4 routing table and IPv6 routing table respectively.

Some people think it's a bad idea for the prefix and the next hop to be 
of different address families; those folks tend to regard RFC 5549 as a 
bad solution.

However, I don't see what advantage your proposal has over RFC 5549.   
In order to determine whether a given 4PE route is feasible, or whether 
it is the bestpath, you still have to resolve the IPv6 next hop, you 
still have to consider the IGP distance to the IPv6 next hop, etc.

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 16 Mar 2016 16:57:10 +0800

Hi, Eric and all,

Try to answer your questions below, please comment.

Q: If the core runs only IPv6/MPLS, and the next hop of a 4PE route is an IPv4 address, I don't really see how the next hop resolution is going to work, as the next hop (a v4 address) will not appear to be reachable through the v6 core.
A: No, you can not use the v4 next hop to reach the egress 4PE in the v6 core directly. But, the ingress 4PE can use the v4 next hop to get the corresponding v6 address of the egress 4PE and forward the packet toward the egress 4PE through the v6 LSP after encapsulation. Encapsulation here means adding two labels. Ingress 4PE needs a data structure to establish the connection between the v4 next hop and the the corresponding v6 address of the egress 4PE. This data structure is implementation specific.

Q: I think your proposal really is intended to treat the v6 address in the NLRI as the next hop.  But that leaves open the question of why you want to put the next hop address in the NLRI field instead of in the next hop field.
A: What I want is to send both the IPv4 and IPv6 addresses of the 4PE to other 4PEs.

Q: Some people think it's a bad idea for the prefix and the next hop to be of different address families; those folks tend to regard RFC 5549 as a bad solution.
A: I don't think I am one of those folks.

Q: However, I don't see what advantage your proposal has over RFC 5549.   In order to determine whether a given 4PE route is feasible, or whether it is the bestpath, you still have to resolve the IPv6 next hop, you still have to consider the IGP distance to the IPv6 next hop, etc.  
A: If 4PE only gets the v6 addresses of the other 4PEs, how does the 4PE build its IPv4 routing table? Can it install a v6 address in its v4 routing table?

[email-masked]
 
From: Eric C Rosen
Date: 2016-03-15 03:48

If you want the 4PE routers to send labeled IPv4 routes to each other, they just need to use SAFI 4.

If the core runs only IPv6/MPLS, and the next hop of a 4PE route is an IPv4 address, I don't really see how the next hop resolution is going to work, as the next hop (a v4 address) will not appear to be reachable through the v6 core.

I think your proposal really is intended to treat the v6 address in the NLRI as the next hop.  But that leaves open the question of why you want to put the next hop address in the NLRI field instead of in the next hop field.

Some people think it's a bad idea for the prefix and the next hop to be of different address families; those folks tend to regard RFC 5549 as a bad solution.

However, I don't see what advantage your proposal has over RFC 5549.   In order to determine whether a given 4PE route is feasible, or whether it is the bestpath, you still have to resolve the IPv6 next hop, you still have to consider the IGP distance to the IPv6 next hop, etc.

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 22 Mar 2016 12:08:17 -0400

On 3/16/2016 4:57 AM, [email-masked] wrote:
> Q: If the core runs only IPv6/MPLS, and the next hop of a 4PE route is 
> an IPv4 address, I don't really see how the next hop resolution is 
> going to work, as the next hop (a v4 address) will not appear to be 
> reachable through the v6 core.
> A: No, you can not use the v4 next hop to reach the egress 4PE in the 
> v6 core directly. But, the ingress 4PE can use the v4 next hop to get 
> the corresponding v6 address of the egress 4PE and forward the packet 
> toward the egress 4PE through the v6 LSP after encapsulation. 
> Encapsulation here means adding two labels. Ingress 4PE needs a data 
> structure to establish the connection between the v4 next hop and the 
> the corresponding v6 address of the egress 4PE. This data structure is 
> implementation specific.

I think the key statement here is "Ingress 4PE needs a data structure to 
establish the connection between the v4 next hop and the the 
corresponding v6 address of the egress 4PE. This data structure is 
implementation specific." Whatever implementation technique you choose 
to use, you are still treating the v6 next hop as the real next hop.  I 
don't see why the protocol should not carry the v6 next hop in the next 
hop field, per RFC 5549.

>
> Q: I think your proposal really is intended to treat the v6 address in 
> the NLRI as the next hop.  But that leaves open the question of why 
> you want to put the next hop address in the NLRI field instead of in 
> the next hop field.

But the IPv4 address of the 4PE router plays no role in the protocol.  
In the implementation, you seem to be using it only as a sort of pointer 
to the IPv6 address of the 4PE router.
>
> Q: Some people think it's a bad idea for the prefix and the next hop 
> to be of different address families; those folks tend to regard RFC 
> 5549 as a bad solution.
> Q: However, I don't see what advantage your proposal has over RFC 
> 5549.   In order to determine whether a given 4PE route is feasible, 
> or whether it is the bestpath, you still have to resolve the IPv6 next 
> hop, you still have to consider the IGP distance to the IPv6 next hop, 
> etc.
> A: If 4PE only gets the v6 addresses of the other 4PEs, how does the 
> 4PE build its IPv4 routing table? Can it install a v6 address in its 
> v4 routing table?

Whether an IPv6 address can be installed as a next hop in the IPv4 
routing table is an implementation issue.

I don't see any reason for the protocol to carry around the IPv4 address 
of the 4PE router, as this information doesn't really play any role.

If you put the next hop in the NLRI, and put a meaningless value in the 
next hop field, you have to revise all the bestpath selection rules.