Subject: RE: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04

From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Date: Tue, 1 Feb 2005 11:13:49 +0100

Hello Jeffrey,

>> This draft ties the MP-BGP nexthop associated with VPN-IPv6 
>> reachability to the BGP Speaker's transport session type.

This was not the intent, but I looked back at the current text and I have to agree it precisely (and incorrectly) does that.
This needs to be fixed. How about the following sort of changes:

1) The following text:
"
3.2.1 BGP Next Hop encoding
The encoding of the BGP Next Hop depends on whether the IPv6 VPN reachability is advertised between BGP speakers using IPv6 connectivity (''BGP speakers with IPv6 connectivity'') or using IPv4 connectivity (''BGP speakers with IPv4 connectivity'').
"
be replaced by something like:
"
3.2.1 BGP Next Hop encoding
The encoding of the BGP Next Hop depends on whether the policy of the BGP Speaker is to request that IPv6 VPN traffic be transported to that BGP Next Hop using IPv6 tunneling (''BGP speaker requesting IPv6 transport'') or using IPv4 tunneling (''BGP speakers requesting IPv4 transport'').
"

2) The following text:
"
3.2.1.1 BGP speakers with IPv6 connectivity
When using IPv6 connectivity to the other BGP speaker for advertisement of the IPv6 VPN reachability, a BGP speaker SHALL advertise a Next Hop Network Address field containing a VPN-IPv6 address:
"
be replaced by something like:
"
3.2.1.1 BGP speaker requesting IPv6 transport
When the IPv6 VPN traffic is to be transported to the BGP speaker using IPv6 tunneling (e.g. IPv6 MPLS LSPs, IPsec-protected IPv6 tunnels), the BGP speaker SHALL advertise a Next Hop Network Address field containing a VPN-IPv6 address:
"

3) The following text:
"
3.2.1.2 BGP Speakers with IPv4 connectivity
When using IPv4 connectivity to the other BGP speaker for advertisement of the IPv6 VPN reachability, a BGP speaker SHALL advertise to its peer a Next Hop Network Address field containing a VPN-IPv6 address:
"
be replaced by something like:
"
3.2.1.2 BGP Speakers requesting IPv4 transport
When the IPv6 VPN traffic is to be transported to the BGP speaker using IPv4 tunneling (e.g. IPv4 MPLS LSPs, IPsec-protected IPv4 tunnels), the BGP speaker SHALL advertise to its peer a Next Hop Network Address field containing a VPN-IPv6 address:
"

Would those sort of changes address the problem?

I will also re-read all the relevant text to try determine if additional changes are needed in other places. Please, let us know if you've already identified other text needing correction.

Thanks a lot for this comment.

Francois

>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Jeffrey Haas
>> Sent: mardi 1 février 2005 00:04
>> To: Yakov Rekhter
>> Cc: Ross Callon; [email-masked]; [email-masked]; 
>> [email-masked]; Ronald Bonica
>> Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
>> 
>> I have a concern with regards to the MP-BGP nexthops for this draft:
>> 
>> This draft ties the MP-BGP nexthop associated with VPN-IPv6 
>> reachability
>> to the BGP Speaker's transport session type.  I.e. an IPv6 
>> transport session
>> will require IPv6 VPN-IPv6 nexthops and an IPv4 transport 
>> session will
>> require IPv4 VPN-IPv4 nexthops.
>> 
>> Why is this a SHALL?
>> 
>> MP-BGP allows for different address families to be carried across
>> the same BGP session regardless of the form of the transport session.
>> When carrying information for a different address family (e.g.
>> an ipv4 transport session carrying ipv6 reachability) it is necessary
>> to configure additional information about the endpoints of 
>> the session
>> for reachability calculations.  This draft appears to try to preclude
>> this option in some capacities for VPN-IPv6.
>> 
>> I would suspect that regardless of the transport session type, as
>> long as it was clear if the nexthop was v4 or v6 that as long as
>> a label-switched path could be established between the two 
>> BGP speakers
>> it shouldn't matter what kind of transport session is being used.
>> 
>> On Mon, Jan 17, 2005 at 07:52:37AM -0800, Yakov Rekhter wrote:
>> > Folks,
>> > 
>> > This message begins a last call on 
>> draft-ietf-l3vpn-bgp-ipv6-04. Last
>> > call ends on Feb 1 at midnight UTC.
>> > 
>> > Yakov.
>> > 
>> > P.S. this is a combined last call with the L3VPN WG.
>> > 
>> > _______________________________________________
>> > Idr mailing list
>> > [email-masked]
>> > https://www1.ietf.org/mailman/listinfo/idr
>> 
>> -- 
>> Jeff Haas 
>> NextHop Technologies
>> 
>> _______________________________________________
>> Idr mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/idr
>> 

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

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 1 Feb 2005 17:12:09 -0500

Francois,

> The encoding of the BGP Next Hop depends on whether the policy of the BGP Speaker is to request that IPv6 VPN traffic be transported to that BGP Next Hop using IPv6 tunneling (''BGP speaker request…

This seems reasonable.

> When the IPv6 VPN traffic is to be transported to the BGP speaker using IPv6 tunneling (e.g. IPv6 MPLS LSPs, IPsec-protected IPv6 tunnels), the BGP speaker SHALL advertise a Next Hop Network Addres…

Also reasonable.

> When the IPv6 VPN traffic is to be transported to the BGP speaker using IPv4 tunneling (e.g. IPv4 MPLS LSPs, IPsec-protected IPv4 tunnels), the BGP speaker SHALL advertise to its peer a Next Hop Ne…

Also good.

> Would those sort of changes address the problem?

I think that does it.

-- 
Jeff Haas 
NextHop Technologies