Re: About IS-IS as the PE/CE Protocol in BGP/MPLS VPNs (43834 bytes)

[lidefeng <77cronux.leed0621 at huawei.com>]

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