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

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

Thanks for your comments, I will study your comments further and reply your e-mail.

Regards

Defeng Li
Huawei Technologies


----- 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.
> 
> 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.
> 
>  - 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.
> 
>  - 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.
> 
> 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. 
>  
>   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.  
> 
>   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.
> 
>   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.
> 
> 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.
> 
> 6) I have a number of minor editorial comments that I will mail to you
> privately.
> 
> Please let me know if you wish to discuss any of these points in more
> detail, or if there is anything I can do to help you with the draft, such as
> drafting text.  
> 
> Take care,
> 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: 02 September 2004 10:13
> To: rick at rhwilder.net; Ronald Bonica; Ross Callon
> Cc: l3vpn at ietf.org
> Subject: About IS-IS as the PE/CE Protocol in BGP/MPLS VPNs (43834 bytes)
> 
> 
> Dear Chairmen,
> 
> At 57th IETF meeting, I made the presentation for
> draft-sheng-ppvpn-isis-bgp-mpls-00.txt at PPVPN wg meeting and proposed the
> draft about "IS-IS as the PE/CE Protocol in BGP/MPLS VPNs" as work group
> draft, now PPVPN wg is divided into L3VPN and L2VPN, at the same time, draft
> "OSPF as the PE/CE Protocol in BGP/MPLS VPNs " is progressed as L3VPN wg,
> and IS-IS as an alternate IGP in SP's network and enterprise's network has
> its advantages over OSPF, especially in IPv6 and Traffic Engineering
> scenarios(OSPFv3 can't be compatibility with OSPFv2,while IS-ISv6 can be
> updated from IS-ISv4 by TLV extensiona), and IS-IS gained its wide
> deployment gradually.
> 
> So I hope L3VPN wg consider to progress
> draft-sheng-ppvpn-isis-bgp-mpls-00.txt as WG draft, and it's goal is to
> become an informational RFC.
> 
> As to the technical problem might exist in it, comments are welcomed.
> 
> Regards
> 
> Defeng Li
> Huawei Technologies
> 
>