RE: About IS-IS as the PE/CE Protocol in BGP/MPLS VPNs (43834 byt es)

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

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