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

From: "Michael Dell" <[email-masked]>
Date: Tue, 1 Feb 2005 12:13:56 -0000

Francois

I have a question about your proposed change to the BGP next hop encoding.

If I understand you correctly, you say that the way the BGP next hop of an IPv6-VPN route is constructed should not depend on the transport type of the BGP session between the speakers, but rather on the transport type of the tunnel over which data will be passed. 

For example, if the two speakers share an IPv6 BGP session, but will transport data over an IPv4 MPLS LSP, then the BGP next hop of an IPv6-VPN NLRI should be constructed from the IPv6-mapped IPv4 version of the advertising speaker's IPv4 address (the egress address of the LSP), rather than its IPv6 address (the session's local address).

This sounds sensible, and probably what was originally intended.  However, I am uncertain how the BGP speaker is supposed to select which BGP next hop to use.  If two speakers with an IPv6 session are to forward data over an IPv4 tunnel, is it up to the user to configure policy so that the correct next hops are used when advertising routes to each other?  This could be achieved by some implementation specific policy to set the next-hop of VPNv6 routes, but should there perhaps be a more standardised way of defining how this should work, such as within the mplsL3VpnVrfTable MIB table?  (This is probably more a question for the L3VPN WG I guess).

Regards

Mike Dell
Data Connection Ltd

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 01 February 2005 10:14
To: Jeffrey Haas
Cc: NextHop - Susan Hares; [email-masked]; Francois Le Faucheur
(flefauch); Yakov Rekhter; Ross Callon; Ronald Bonica;
[email-masked]; [email-masked]
Subject: RE: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04

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

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

---

From: "Michael Dell" <[email-masked]>
Date: Tue, 1 Feb 2005 16:54:41 -0000

Francois

Thanks for the reply.  Yes, I think that it would be helpful to make it clear that it is up to the user/implementation to configure policy to define what the BGP next-hop should be.

On reflection, I would agree that defining how this should be configured is probably an implementation matter.

Mike Dell
Data Connection Ltd.

-----Original Message-----
From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
Sent: 01 February 2005 16:22
To: Michael Dell
Cc: NextHop - Susan Hares; [email-masked]; Yakov Rekhter; Ross Callon;
Ronald Bonica; [email-masked]; [email-masked]; Jeffrey
Haas; Francois Le Faucheur (flefauch)
Subject: RE: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04

Hello Michael,

>> From: Michael Dell [mailto:[email-masked]] 
>> Sent: mardi 1 février 2005 13:14
>> To: Francois Le Faucheur (flefauch); Jeffrey Haas
>> Cc: NextHop - Susan Hares; [email-masked]; Yakov Rekhter; Ross 
>> Callon; Ronald Bonica; [email-masked]; [email-masked]
>> If I understand you correctly, you say that the way the BGP 
>> next hop of an IPv6-VPN route is constructed should not 
>> depend on the transport type of the BGP session between the 
>> speakers, but rather on the transport type of the tunnel 
>> over which data will be passed. 
>> 
>> For example, if the two speakers share an IPv6 BGP session, 
>> but will transport data over an IPv4 MPLS LSP, then the BGP 
>> next hop of an IPv6-VPN NLRI should be constructed from the 
>> IPv6-mapped IPv4 version of the advertising speaker's IPv4 
>> address (the egress address of the LSP), rather than its 
>> IPv6 address (the session's local address).

yes.
 
>> This sounds sensible, and probably what was originally 
>> intended.  However, I am uncertain how the BGP speaker is 
>> supposed to select which BGP next hop to use.  If two 
>> speakers with an IPv6 session are to forward data over an 
>> IPv4 tunnel, is it up to the user to configure policy so 
>> that the correct next hops are used when advertising routes 
>> to each other?  

Yes. That is the intent.
Should we add a clarifying sentence to that effect?

>> This could be achieved by some 
>> implementation specific policy to set the next-hop of VPNv6 
>> routes,

Right.

>> but should there perhaps be a more standardised way 
>> of defining how this should work, such as within the 
>> mplsL3VpnVrfTable MIB table?  (This is probably more a 
>> question for the L3VPN WG I guess).
 
I think this would be beyond the scope of draft-ietf-l3vpn-bgp-ipv6.
With respect to a specific MIB knob, I don't have the right expertise to follow it up, but it is not clear to me this would naturally map into as a single binary MIB knob since using IPv4 or IPv6 type Next Hop could be the resultant of several configuration knobs (eg "route map" forcing the nexthop).

Thanks

Francois

>> This was not the intent, but I looked back at the current 
>> text and I have to agree it precisely (and incorrectly) does that.
>> 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'').
>> "
>> 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:
>> "
>> 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:
>> "
>> 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:
>> "
>> 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:
>> "
>> 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:
>> "
>> 
>> 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.
>> 
>>

---

From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Date: Fri, 4 Feb 2005 17:06:51 +0100

Jeffrey, Pedro,

The proposed updated text actually stays away from discussing what is the right "policy" to decide whether IPv6 VPN traffic should be transported over v4 or v6. It basically just says, "if IPv6 VPN traffic is to be transported over vN, then you shall include a next-hop that looks like vN"; For example:
"
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:
...blablabla 
"

Personally, I think it is probably beyond the scope of this particular IPv6 VPN document to prescribe what policies may/should/must be used by operators for selection of transport vs BGP stack. So, my proposal would be to :
	- keep the proposed updated text that we discussed
	- add a couple of sentences that point out potential operational issues involved in transporting traffic over vN when the corresponding BGP advertisements are carried themselves over vM (instead of vN).

Would that be acceptable?
Pedro, would you be willing to craft the couple of additional sentences?

Cheers

Francois

>> Sent: jeudi 3 février 2005 11:41
>> To: Pedro Roque Marques
>> Cc: [email-masked]
>> On Mon, Mar 24, 1975 at 10:06:56AM -0800, Pedro Roque Marques wrote:
>> > The point is that it does. If ibgp transport between PE1 
>> and PE2 uses
>> > the forwarding LSP between PE1 and PE2 then a silent (in control
>> > plane) forwarding failure will cause the BGP transport 
>> session to come
>> > down.
>> 
>> Right.  But this is a generic MP-BGP issue rather than one specific
>> to this particular protocol extention.
>> 
>> > > I will agree with you 100% that there are operational 
>> practices that
>> > > will provide better survivability in certain failure 
>> scenarios.  Do
>> > > these belong in this protocol extention?  Probably not.
>> > 
>> > I thought so... but i conceed that it is a matter of opinion.
>> 
>> I objected to the SHALL.  It sounds like you believe a SHOULD is the
>> solution.  Propose new text - that's what last call is all about. :-)
>> 
>> I wouldn't object to a SHOULD.
>> 
>> >   Pedro.
>> 
>> -- 
>> Jeff Haas 
>> NextHop Technologies
>>