Hey Michuki

I liked your last bit where you advised on the way forward. Remember that this idea is not based on the current limitations of routing protocols but rather possibilities and features that would come in handy since we are fast moving into a unified data village (if I may call it that). This means I was not implying how it will work on IS IS, OSPF or any other protocol but rather how each had to be tweaked to cater for new features, so lets not argue on how they each work.

Additionally RFC is simply Request For Comments where standards emerge. I am currently stuck with my ISP at home and I cannot migrate since it requires additional investment on another new infrastructure hence the need can't we advance or create a model where it would be possible to move without needing new infrastructure or even set-up. That is a need which I believe if well looked at by the IETF community and skunks can result to a higher or better features on the routing protocols.

Meanwhile lemme look at the sites u recommended.

Regards
./TheMburu



On Tue, Apr 26, 2011 at 11:04 AM, Michuki Mwangi <michuki.mwangi@gmail.com> wrote:


On 4/26/11 9:27 AM, TheMburu George wrote:
> Hey Michuki n Thuo
>
> This is what I mean: ASN identifies the end route or destination to a
> network, more precisely it means that the IP address in question resides
> within the bloack of the ASN (so was mobile prefix originally i.e 072*
> would identify a block within the Queen Bee) but that a line of thot.
>

You may want to read RFC's 1771 and 1930 - your definition of an ASN is
somewhat not true. But in its simplicity ASN denotes a network under a
single control with common routing policy.

In many instances today some networks have their own PI space but use
the ISPs ASN (as origin AS). How the Number portability works today is
slightly different.

> Back to my idea, we have two blocks of IP Private and Public which are
> routable.

ok.

> Taking you to IS-IS routing protocol which was originally
> created for OSI protocol and later tweaked for TCP/IP and so is OSPF
> which required tweaking.

Clarifications - OSI is not a protocol but a model.

IS-IS is a layer 2 protocol (CLNS = connectionless)

OSPF is layer 3 protocol (it depends on IP connectivity)

Updates to OSPF i.e OSPFv2 and OSPFv3 have included features of IS-IS
i.e working on the interface level though somewhat still dependent on
layer 3 connectivity. See the relevant RFC's for updates.

Both protocols their distinct differences starting from LSA types, etc.

If we approach this analogy can we then say a
> possible way to approach this is to have floating IP Block i.e. not
> within Private or Public which you can use to create adjancencies with
> any provider you choose to use

To start with - No operator in their right mind will use an IGP with
their customers. This protocols were not built with any safety or
security in mind (they are fully trusting protocols) as such as an
operator your customers network sneezing would give you a bad cold - if
you get what i mean.

Going ahead - Well if its not Private or Public do you mean creating a
new address space just for Point-2-Point interfaces or in other words
adjascencies?.

If you are proposing either creating an entire address space
specifically for this - then this is not necessary since IPv6 already
has enough space to cater for such. Each network gets a minmum
allocation of /32 that is 65,536 /48 Subnets and each /48 gives 65,536
/64 subnets and each /64 gives you 2^64 Addresses. There's more than
necessary.

If you are proposing allocating a specific block for adjacency within
the existing Ipv4 and IPv6 block then you are likely to bring up the
same problems folks have been stuck with with RFC1918 space. Some folks
proposed a similar approach to RFC1918 in IPv6 using the Unique Local
Address. But this was met with reservations.

If you have very specific proposals on how this will work you are
welcome to propose the recommendations - this happens at the Routing and
Internet Areas of the Internet Engineering Task Force - see
http://datatracker.ietf.org/wg/.

Before doing so its important to try establish that what you want to
achieve cannot be accomplished using the existing protocols and if it
can be the limitations and how your proposal (called a draft) is going
to address the limitations.

 then we can tweak how you associate to
> the new providers AS block or something like that.
>

In all am not sure how what you are proposing cannot be dealt with using
MPLS?. However a unique IP will still be required either way.

> Note: I'm not talking of multi-homing but  a user somewhere who gets
> poor services and would like to kuhama from ISP.
>

The only way a user can move from one ISP to another is if the resources
they use (primarily an IP Address) is independent from any ISP. That
means the user needs to have their own unique IP address. Which is
similar to what Number Portability is - it means your number is yours
and does not belong to any operator as was the case in the past.

Now for a more interesting development which might be linked to what you
are proposing,  you may want to read the research work thats going on
under the LISP Working Group under the Internet Area.
http://datatracker.ietf.org/wg/lisp/charter/

Regards,

Michuki.



--
Conservatism is the adherence to the old tried against the new untried.