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

From: Pedro Roque Marques <[email-masked]>
Date: Wed, 2 Feb 2005 17:12:13 -0800

Jeffrey Haas writes:

> 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.

Sounds like a feature. :-)

imho transport and forwarding to next-hop should be tied together
whenever possible.

The standard example being a network with v4 and v6 forwarding /
transport capabilities. Forwarding can break independently by AF. Using
v4 transport for v6 next-hops can lead to undetected blackholes...

>  I.e. an
> IPv6 transport session will require IPv6 VPN-IPv6 nexthops and an
> IPv4 transport session will require IPv4 VPN-IPv4 nexthops.

I guess you mean an LSP identified by a IPvX address...
That would be desirable. yes.

> MP-BGP allows for different address families to be carried across
> the same BGP session regardless of the form of the transport
> session.

AF of NLRI has nothing to do w/ nexthop or transport. af of next-hop
should correspond to transport.

>  When carrying information for a different address family
> (e.g.  an ipv4 transport session carrying ipv6 reachability)

You really shouldn't do that. :-) It is allowed but frowned upon. The
entire reason it is allowed is because some implementations wanted
this "transition" mode as a way to ramp up... 

> it is
> necessary to configure additional information about the endpoints of
> the session for reachability calculations.

And necessary to keep in mind that forwarding may break silently.

>  This draft appears to
> try to preclude this option in some capacities for VPN-IPv6.

Good.

> 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.

It matters. If the type matches, i can forward the transport session
on top of the LSP and have it drop if the LSP goes dead. Not everyone
runs their BGP sessions this way, but some network operators choose to
do so... usually after past negative experiences with sillent mpls
forwarding failures.

cheers,
  Pedro.

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

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 3 Feb 2005 10:09:10 -0500

Pedro,

> imho transport and forwarding to next-hop should be tied together

I generally agree.

I specifically disagree in this case.

In this particular case, the MP-BGP nexthop is meant to serve as
a way to select an LSP that will allow the each end of the VPN to
reach the tunneled reachability.  The nexthop will select whether
we try to use/create an LSP that is an IPv4 or an IPv6 LSP.

If BGP was being used as the label distribution protocol for the LSP
endpoints, I can see making a strong association between the BGP
transport session and the MP-BGP reachability.  However, it is as likely
(or more likely?) that a second protocol such as LDP or RSVP will
be used to signal the LSP.  

> v4 transport for v6 next-hops can lead to undetected blackholes...

True.  This is why we will still have a IPv6-based IGP running along-side
our IPv6 label distribution protocol in most cases.  Normal BGP
nexthop resolution will continue to work.

> this "transition" mode as a way to ramp up... 

And the wording that I commented on precluded this sort of mechanism.

If implementors want to force the AF to match the transport session,
nothing stops them from implementing it this way.  I believe that 
many implementations will do exactly that.

I don't find a need to enforce this in the protocol given that some people
will want to be able to do what I had commented on.

> do so... usually after past negative experiences with sillent mpls

That's an interesting comment.  A labeled BGP route (or VPN route)
is supposed to become unresolvable if there is no LSP to the end-point.
Perhaps I misunderstand you.

-- 
Jeff Haas 
NextHop Technologies

---

From: Pedro Roque Marques <[email-masked]>
Date: Thu, 3 Feb 2005 10:32:28 -0800

Jeffrey Haas writes:

> In this particular case, the MP-BGP nexthop is meant to serve as a
> way to select an LSP that will allow the each end of the VPN to
> reach the tunneled reachability.  The nexthop will select whether we
> try to use/create an LSP that is an IPv4 or an IPv6 LSP.

> transport session and the MP-BGP reachability.  However, it is as
> likely (or more likely?) that a second protocol such as LDP or RSVP
> will be used to signal the LSP.

Jeff,
I don't agree with that line of reasoning. On ibgp, BGP is not used to
determine interior routing... some other protocol is.

But by using a next-hop that matches the transport, if there is a
silent forwarding failure on the path (no control info), the BGP
session will come down due to keepalive failure.

As i mentioned, some networks have as a requirement that, iBGP VPN
sessions are carried over the LSPs so that forwarding failures will
also affect the control plane.

> I don't find a need to enforce this in the protocol given that some
> people will want to be able to do what I had commented on.

If i remember correctly, you objected to the spec including a SHOULD
"use next-hops in this way"... there is a reason to prefer one method
of doing things. i.e. a justification.

Then there is the question of should a standard allow as much freedom
as possible or nail down the most common option that implementations
should support and let vendors expand on top of this minimum common
set. There is no perfect answer to that.

>> It matters. If the type matches, i can forward the transport
>> session on top of the LSP and have it drop if the LSP goes
>> dead. Not everyone runs their BGP sessions this way, but some
>> network operators choose to do so... usually after past negative
>> experiences with sillent mpls forwarding failures.

> is supposed to become unresolvable if there is no LSP to the
> end-point.  Perhaps I misunderstand you.

Example: LDP LSP between 2 PEs; control plane is fine; some label
change didn't get propagated down to the forwarding engines; traffic
gets dropped sillently.

Also, if LDP is used in "black-hole creation mode"
(a.k.a. independent-control) this kind of mismatch between control and
forwarding plane can occur quite easily.

  Pedro.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 3 Feb 2005 16:24:00 -0500

Pedro,

> session will come down due to keepalive failure.

In at least one of the scenarios you have proposed - a label change
fails to propagate - even running the same nexthop AF as your
peering session wont protect you.

> also affect the control plane.

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.

Did it belong in the base protocol specification?  Perhaps.
(And it might be there.  I haven't read 2547bis in some time.)

> of doing things. i.e. a justification.

No, my original objection was to the SHALL use them this way.
The response of the authors was essentially, "no, we didn't mean it
quite this way".

> change didn't get propagated down to the forwarding engines; traffic

If this is a common event, it sounds like the implementation isn't very
robust.   Then again, one could simply run BFD across your LSP/tunnel
of choice and stop worrying about it. :-)

-- 
Jeff Haas 
NextHop Technologies

---

From: Pedro Roque Marques <[email-masked]>
Date: Thu, 3 Feb 2005 13:51:50 -0800

> peering session wont protect you.

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.

> 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.

  Pedro.

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 4 Feb 2005 09:24:57 +2244

> plane) forwarding failure will cause the BGP transport session to come

Right.  But this is a generic MP-BGP issue rather than one specific
to this particular protocol extention.

> 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.

-- 
Jeff Haas 
NextHop Technologies