RE: About IS-IS as the PE/CE Protocol in BGP/MPLS VPNs

[Jonathan Harrison <jon.harrison at dataconnection.com>]

Defeng Li,

Thanks for the response to my comments.

We understand your explanation, however we still think that the text
describing the effect of using the up/down bit in relation to sham links
could be expanded.

Consider the case where there are two PE devices (A and B), connected by an
MPLS/BGP VPN, and also connected through IS-IS with a back-door link.  The
requirement for preventing the redistribution of redistributed addresses is
as follows.

 - PE device A learns of a destination address in an IS-IS LSP from a router
at the local customer site.

 - PE device A advertises the address via BGP to remote PE device B.

 - PE device B redistributes the address into the IS-IS network.

 - PE device A learns of the destination address in the IS-IS LSP of PE
device B.

 - PE device A has now learnt the address from both a local router, and from
PE device B.

 - It is a requirement that the preferred route of PE device A is the route
to the local router.  (Otherwise, A will install the redistributed route to
the address in the forwarding table, and then redistribute this
redistributed route via BGP to PE device B, and so on.)

The method you suggest uses the up/down bit to ensure that this requirement
is met.  This works due to the rules of route preference defined in RFC 2966
- for example, a level 1 route with internal metric is always preferred to a
level 1 route with the up/down bit set (regardless of the actual metric
value).  

So the redistributed routes are less preferable.  Note that the VPN will
still be used for traffic - consider the following cases.

1) If there is no back-door link the routes learnt from BGP are used to
route traffic over the VPN link (regardless of whether a sham link is used).

2) If there is a back-door link, but no sham link, then the routes over the
back-door link are always preferred (because of the setting of the up/down
bit).  In other words, the VPN link is acting as a back-up link - it is only
used if the back-door link goes down.

3) If there is a back-door link and a sham link, then the routes learnt over
the VPN are not used.  However, the internal IS-IS routes may take the
inter-site traffic over the VPN (sham) link and/or the back-door link,
depending on the network topology.
 

To answer your question on sham links - I think that manual configuration of
the sham links probably makes the most sense.  BGP can still be used to pass
the end-point addresses between the VPN sites - the presence of these
addresses indicates whether the sham link is usable (and should be added to
the IS-IS LSP), rather than for auto-configuration.  

Jon
-------------------------------------------
Jon Harrison
Network Protocols Group
Data Connection Ltd
Tel:	+44 20 8366 1177                 
Fax:	+44 20 8363 1039
Email:	jrh at dataconnection.com    
Web:	http://www.dataconnection.com


-----Original Message-----
From: lidefeng [mailto:77cronux.leed0621 at huawei.com]
Sent: 08 October 2004 07:16
To: Jonathan Harrison; l3vpn at ietf.org
Subject: Re: About IS-IS as the PE/CE Protocol in BGP/MPLS VPNs (43834
bytes)


----- Original Message ----- 
From: "Jonathan Harrison" <jon.harrison at dataconnection.com>
To: "'lidefeng'" <77cronux.leed0621 at huawei.com>; <l3vpn at ietf.org>
Sent: Thursday, September 23, 2004 11:00 PM
Subject: RE: About IS-IS as the PE/CE Protocol in BGP/MPLS VPNs (43834
bytes)


> Defeng Li,
> 
> We've looked through your draft in some detail, and have a few comments.
> 
> 1) Overall, we think that the draft is useful, and that it goes some way
to
> solving the problem.
> 
> 2) The main issue with the draft is that it does not go into any detail
with
> regards to the possible topologies used in the customer IS-IS network.
The
> result is that the topological restrictions imposed by the proposed
solution
> are not obvious, and it is not clear whether the solution needs to be
> extended to cope with additional cases.
> 
> For example, the CE devices could be
> 
>  - all at level 1, all in the same area
>  - all at level 1, some CE devices are in the same area, some CE devices
are
> in different areas
>  - all at level 2
>  - some at level 1, some at level 2.
> 
> The draft should clearly explain whether it applies to such topologies,
and
> how it applies to these topologies.  I've noted some particular cases
below
> that do not appear to be handled by the draft.

A: Agree

> 
> 3) As mentioned in section 4.3, redistributed addresses must be less
> preferable in the routing calculation (at least on the PE routers) to
> internal IS-IS routes to prevent loops.  Hence it makes sense to advertise
> the VPN routes from BGP as level 1 routes with the "up/down" bit set.
Note
> though that this has some interesting consequences.

A: Maybe the description of the third paragraph of 4.3 is not very clear.
4.3 mainly focus on the issue of loop prevention using up/down bit. At last,

Redistribute addresses will be converted to some type of
LSP(level-1/level-2, 
internal/external reachability...) as per the attribute that bgp extended
community carry. Besides, when we configure the command "redistribute bgp...
"
in isis, we also can specify the level/metric-type of converted lsp by the 
command parameters, which i think should be prefered to "choose" to BGP
ext-com carry. 

So, it is not "redistributed addresses must be less preferable in the
routing 
calculation ". We can consider to remove the specification or give a more 
clear description in the next version of the draft. 

I wonder if i have clarify the confusion. 
> 
>  - Such routes are less preferable to internal IS-IS routes, and so the
> backdoor link is always preferred.  The result is that nothing is gained
by
> allowing different metric types/levels to be advertised in BGP extended
> communities.

A: As per the last explanation, "backdoor link is always preferred" will not
happen.

> 
>  - This also imposes topology restrictions.  If the customer site
containing
> a CE device contains multiple areas, then the routes from BGP will only be
> advertised in the level 1 area containing the CE device.  These routes
> cannot be advertised via level 2 to other areas, because the route has the
> up/down bit set.  Similar problems arise if the CE devices are in a level
2
> only topology.
> 
> These examples show that there are a number of types of topology for which
> the solution currently doesn't work.  We should either look at the best
way
> to enhance the draft to apply to any topology, or (as mentioned above) the
> draft should describe any topological restrictions.

A: Yes, we should add one more restriction that CE sites must belong to
level-1. 
PE-CE can work in both level-1 and level-2 domain.

> 
> 4) The document needs to describe the sham link processing in much more
> detail.  In particular, it should explain the following points.
> 
>   a) Why are sham links required?  They are needed because routing
> information passed through the VPN must be less preferable than the
internal
> IS-IS routes learnt via the back-door link.  In order for the VPN to be
used
> for routing traffic, it must appear as an IS-IS link with lower cost than
> the back-door link. 
A: Agree.

>  
>   b) When can a sham link can be set up?  An IS will only route over the
> sham link if it has the LSPs describing both ends of the link.  Hence the
CE
> devices at both ends of a sham link must either both act at level 2, or
both
> be in the same area at level 1.  

A: This is a really big problem for us. Sham link is only required when back
door
exists. But it is more difficult for isis to exchange hello or LSP packet
via 
backbone between PEs because we can't forward the hello/LSP through
multi-hop
as what OSPF vitual link could do.  
In my opnion, it is difficult to maintain "up/down" relationship between
PEs. 
I think we can simply add the sham link(NBR TLV) into the PE's LSP if the 
route of the address that sham link configuration designate is active . 
what is your good option?


> 
>   c) How is the sham link configured?  This should differentiate between
> information that is manually configured, and information that can be
> auto-configured (for comparison, see draft-rosen-vpns-ospf-bgp-mpls-06,
> which describes how sham links may be manually configured and/or
> automatically configured).  In particular, the document should describe
how
> the metric used for each link is chosen -  it could either be manually
> configured, or a default value used for each link, or it could be based in
> some way on the cost of the path between the PE devices.

A: I think we only need to support the maually configured manner, which  is
more
simple and also prcatical. 

> 
>   d) Is it the customer or the service provider that is responsible for
the
> metric chosen for a sham link?  The metric will have a significant effect
on
> the whether the customer IS-IS network uses the sham link or the back-door
> link for traffic.  Hence the choice of metric must come from the customer.
> However, it is the (service provider configured) PE devices that actually
> sets up the sham link.

A: In my opnion, the draft only need to specify a method to configure the 
metric of the sham link. Who is responsible to decide the metric value is 
beyond the scope of the draft. 


> 
> 5) The draft assumes that narrow metrics are used.  Wide metrics are
> commonly used in IS-IS networks (and may even be required to give
sufficient
> differentiation between the cost of a sham link and the cost of a
back-door
> link), so the draft should consider the wide metrics case.
> 
A: Yes, we forget to add the wide-metric part into the initial draft, we 
will update it in the draft of the next version. 

> 6) I have a number of minor editorial comments that I will mail to you
> privately.

A: Thanks for your very helpful work. In fact, the initial draft need to be
elaborated really.