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

From: lidefeng <[email-masked]>
Date: Fri, 08 Oct 2004 14:16:00 +0800

----- Original Message ----- 
From: "Jonathan Harrison" <[email-masked]>
To: "'lidefeng'" <[email-masked]>; <[email-masked]>
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.

---

From: lidefeng <[email-masked]>
Date: Fri, 08 Oct 2004 22:13:52 +0800

I read the L3vpn wg charter, I didn't find any statement that ISIS as a pe-ce routing protocol for BGP/MPLS VPN, just like it didn't explictly state that OSPF as a pe-ce routing protocol for BGP/MPLS VPN, and draft-ietf-l3vpn-ospf-2547-01.txt
is a WG draft, and there is no explict statement of including PE-PE GRE or IP in BGP/MPLS IP VPNs in L3VPN wg charter, and draft-ietf-l3vpn-gre-ip-2547-02.txt is a wg draft too, what's more, now that this topic is out of scope of l3vpn wg charter, how come this draft was arranged for presentation? 

And IS-IS is deployed in some scenarios, such as some enterprise network, and when two such enterprise networks would like to access service provider to apply BGP/MPLS VPN service between this two sites, if use IS-IS as PE-CE routing protocol, it will be much easier for these enterprise networks customer to transition from the previous network without changing the routing protocol in the original network.

In some service providers, the IS-IS is prefered for its advantage in its compatibility between IPv4 and IPv6 so as to transit their VPN easily, as I mentioned in my last e-mail, IS-ISv6 can be supported easily by adding two TLVs to IS-ISv4, however, if OSPFv2 is deployed as CE-PE routing, when VPN customer hope to transit customer network from IPv4 to IPv6, then he would deploy OSPFv3 in their network, as OSPFv3 is not compatible with OSPFv2, in fact, they may be looked upon as two different routing protocol, so this transition will bring some impact to cutomer's network. In this regard, some service provider would prefer IS-IS as CE-PE routing protocol in BGP/MPLS VPN.

In other words, IS-IS as the PE-CE routing protocol give the service provider an alternative to choose the PE-CE routing protocol, though is not an indispensable choice, it just provide guide line for service provider when he choose IS-IS as PE-CE routing protocol, and its goal is to be progressed into an informational RFC, not a standard track RFC which demand the complete abservation. So why not accept this subject in L3VPN WG charter?

As draft-sheng will address the problem when IS-IS is used as PE-CE routing protocol, and there are some requirements from some service providers in some scenarios. so I hope chairs can reconsider to make the progress to this draft.

	

>Defeng,
>
>Currently, the L3VPN WG charter does not include ISIS as a PE-CE routing
>protocol. However, I would like to open the mailing list to discussion.
>
>Is there a compelling reason to deploy ISIS as a PE-CE routing protocol, as
>opposed to BGP or OSPF? Also, I would like to determine whether there is
>broad WG interest in this work.
>
>                                              Ron
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] 
>> On Behalf Of lidefeng
>> Sent: Thursday, September 02, 2004 5:13 AM
>> To: [email-masked]; Ronald Bonica; Ross Callon
>> Cc: [email-masked]
>> 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
>> 
>> 
>> 
>
>.