The following will be the routing policy for private ISPs and customers of VSNL.

VSNL will announce only default routes to ISPs

a) VSNL will not accept a prefix length greater
    than 24.

b) ISP must submit an application by filling in a
    webbased form indicating the networks that
    need to be announced. All networks must be
    registered in the APNIC database.

c) ISP must indicate the Autonomous System 
    Number (AS) from which the network originates
    and whether it acts as transit for the network.

d) ISPs must inform VSNL at least 48 hours
    before announcing new network since VSNL
    will need to update their access lists

a) VSNL will support static routes for single   
     homed ISPs without an AS number.

b) VSNL will support BGP for multi-homed ISPs
     with an AS number.

This section explains how the first type of multihomed site will be treated. There are basically two approaches that can be taken when you have multiple connections to VSNL:

1. One link is used as the primary while the other
    link is used only to backup the first (this should
    be used for the simplest configurations and/or
    for times when there is a dramatic bandwidth   
    difference between the two links); and

2. Load-sharing between the two.

In the case of primary / backup, VSNL can configure this without the customer having to do much of anything spccial. As a matter of fact, if there are a *very* small number of networks involved, this can be done using static routes, and BGP doesn't need to be involved. If the number of networks are going to increase or if more connectivity to VSNL or another provider is planned, BGP should be used to allow for that growth. Regardless of the type of routing used, the way that primary/backup is implemented is by VSNL applying a policy to the backup link to treat them at a lower preference than the primary link.

Multiply Connected to VSNL - Load-sharing

This can be achieved by using the community attribute in BGP4. By sending different values of the community attribute to VSNL, the customer can dictate the appropriate path back for traffic destined to that particular network.

VSNL Supports different values for the community attribute that are mapped to local preferences of 70, 90 and l00 (default).

Thus a customer connecting to VSNL from Bombay and Delhi can prefer the Bombay link for Bombay networks and Delhi link for Delhi networks and use each other for backup.

Customer must to be aware of issues such as redundancy vs. load-sharing, link bandwidth, symmetrical routing etc. in order for them to achieve the desired result through multi-homing.

1. Sites which have two or more connections to  
    VSNL

2. Sites which have a connection to VSNL and a
    separate connection to another provider.

This section deals with the second type of multihomed site. Third-parties will see two routes to the customer: one through VSNL and another through a different provider.

The assumption in this document is that customers who are multi-homed use BGP4 as the routing protocol with VSNL and any other provider(s). Although it is possible for a site to be multi-homed and not use BGP, that approach is unclean and doesn't allow for much flexibility. Since a multi-homed customer needs to use BGP, it also needs to have an autonomous system (AS) number.

The approach of treating a link to VSNL as primary and a link to another provider as backup (or vice versa) is easier to configure than load sharing. VSNL's default configuration is to treat routes heard from customers at a higher preference than routes heard from peer providers; this is done using the local_pref attribute of BGP. In order to treat the VSNL link as primary, the customer may either manipulate the AS-PATH to have a longer length AS-PATH announced to the backup provider, or may announce a less specific route to the backup provider and a more specific route to VSNL. This is for traffic coming back. For outgoing traffic, the customer may prefer the default through VSNL in several ways.

Load sharing can he achieved in several ways.

Outbound Load-sharing. This is under the control of the customer.

Inbound Load-sharing: This can be achieved by announcing some networks as primary through service provider X and some as primary through VSNL. AS-PATH manipulation and aggregation for back up may again be used to achieve this.

• A minimum of one 124 should be allocated to multihomed customers.

• Addresses assigned by VSNL are Non-portable IP addresses.

• ISPs should not split a 124 in difitrent locations if different Internet gateways are being used.

This section discusses the details of the procedures involved and customer requirements. We have referred to the routing policies policies used by ISPs like MCI, Worldcom and Sprint to arrive at the set of requirements and procedures below.

BGP4 Requirements

1. Customer must be multi-homed to run BGP.

2. Customer must have an AS number.

3. Customer must run BGP-4. VSNI will not
    Peer with customers using BGP3.

4. ISP must be capable of configuring his BGP      
    Session. VSNL may charge an additional   
    consulting fee if customer is unable to configure     BGP-4 on his router.

5. VSNL will not permit multi-hop BGP
    sessions without a Special Customer
    Arrangement (SCA).

6. There should be NO unfiltered redistribution  
    from interior routing protocols into BGP.
    Explicit distribute-list or network statements
    should be used to prevent injections of invalid
    routes into global tables.

7. There should be NO redistribution from BGP
    into interior routing protocols, as it corrupts
    as-path information.

8. There should be as-path filters preventing   
    leakage of routing information from customer's     other service provider to us and vice versa.    
    Those filters should be inclusive, rather than    
    exclusive (i.e. they should list customer as-es   
    instead of excluding other provider's Ases).