Subject: [Isis-wg] DDRP (was doubts)

From: "Philip Christian" <[email-masked]>
Date: Fri, 27 Sep 2002 08:48:44 +0000

Jonathan,

My understanding was that DDRP is nothing more than a simple way of flooding TE type information around a cloud.  More specifically it uses the OSPF flooding mechanism, without the requirement for building an IP forwarding table.

Basically the layers of hierarchy are provided having multiple clouds which do not interact with each other, other than that the TE information "somehow" gets passed from one cloud into another.  My understanding was that the "somehow", which is actually the unique point, is not yet defined.

If I am right then one could use IS-IS as a flooding mechanism instead (or any other).  The TE stuff could still be delivered to the edge of the cloud and passed onto the next (somehow), but the IS-IS LSPs wouldn't.  You wouldn't need 30,000 IP addresses either.

Have I got it about right ?

Philip

----- Original Message -----
From: Jonathan Sadler <[email-masked]>
Date: Thu, 26 Sep 2002 15:20:18 -0500 
To: Jeff Parker <[email-masked]>
Subject: Re: [Isis-wg] doubts

> Jeff -
> 
> Jeff Parker wrote:
> > > The biggest probably is the need to support
> > > Multi-Level hierarchies with a depth greater
> > > than 2.
> >
> >         While I don't want to start a food fight
> > here, can you help me understand why we need
> > additional levels?  I have heard people mutter
> > things about this for years, but I haven't
> > really understood the point yet.
> 
> The main rationale has to do with the way that Telecom Service Providers
> organize their operations staffs, as well as their networks, and the
> size of those networks.  Many operate separate groups that individually
> focus on Metro, Regional, National, and International networks. 
> Consequently, there is natural summarization in the network designs. 
> Couple this with aggregate SONET/SDH node counts of >30,000 (!) nodes
> and you can see why they find hierarchy for ASON routing desireable.
> 
> Jonathan Sadler
> ============================================================
> The information contained in this message may be privileged 
> and confidential and protected from disclosure.  If the 
> reader of this message is not the intended recipient, or an 
> employee or agent responsible for delivering this message to 
> the intended recipient, you are hereby notified that any 
> reproduction, dissemination or distribution of this 
> communication is strictly prohibited. If you have received 
> this communication in error, please notify us immediately by 
> replying to the message and deleting it from your computer.
> 
> Thank you.
> Tellabs
> ============================================================
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/isis-wg
> 

-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Mike Truskowski <[email-masked]>
Date: Fri, 27 Sep 2002 09:21:46 -0700 (PDT)

And to complete... you wouldn't need a multi-layer heirarchy greater
then 2.

Mike

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 27 Sep 2002 21:28:28 -0700

>My understanding was that DDRP is nothing more than a simple way of flooding TE type information around a cloud.  More specifically it uses the OSPF flooding mechanism, without the requirement for b…
well, if this effort is going on I would encourage to think very 
carefully about the 'link-state as a flooding mechanism we can 
piggy-back on' approach first.
 Throwing arbitrary 'stuff' into a link-state and letting it rip leads 
to tears and broken hearts. Some kind of scoping is needed. Whether it is a
hierarchy, a 'time-to-live', 'flooding-scope', 'summarization'  or other 
abstraction approach is a design decision but just thinking that TE can 
be flooded to all people in the whole ISIS cloud will bite ...

    maybe just saying the obvious

    -- tony

---

From: mike shand <[email-masked]>
Date: Mon, 30 Sep 2002 08:33:32 +0100

I strongly agree with Tony. And on the matter of multi-level hierarchies, 
don't forget that there is no need to invent new protocol mechanisms (or 
packet types) to do this. You can get most of what you would want simply by 
running the level 2 protocol multiple times, with suitable scoping rules.

         Mike

At 21:28 27/09/2002 -0700, Tony Przygienda wrote:
>Philip Christian wrote:
>
>>Jonathan,
>>
>>My understanding was that DDRP is nothing more than a simple way of 
>>flooding TE type information around a cloud.  More specifically it uses 
>>the OSPF flooding mechanism, without the requirement for building an IP 
>>forwarding table.
>well, if this effort is going on I would encourage to think very carefully 
>about the 'link-state as a flooding mechanism we can piggy-back on' 
>approach first.
>Throwing arbitrary 'stuff' into a link-state and letting it rip leads to 
>tears and broken hearts. Some kind of scoping is needed. Whether it is a
>abstraction approach is a design decision but just thinking that TE can be 
>flooded to all people in the whole ISIS cloud will bite ...
>
>>Basically the layers of hierarchy are provided having multiple clouds 
>>which do not interact with each other, other than that the TE information 
>>"somehow" gets passed from one cloud into another.  My understanding was 
>>that the "somehow", which is actually the unique point, is not yet defined.
>>
>>If I am right then one could use IS-IS as a flooding mechanism instead 
>>(or any other).  The TE stuff could still be delivered to the edge of the 
>>cloud and passed onto the next (somehow), but the IS-IS LSPs 
>>wouldn't.  You wouldn't need 30,000 IP addresses either.
>>
>>Date: Thu, 26 Sep 2002 15:20:18 -0500 To: Jeff Parker <[email-masked]>
>>>The information contained in this message may be privileged and 
>>>confidential and protected from disclosure.  If the reader of this 
>>>message is not the intended recipient, or an employee or agent 
>>>responsible for delivering this message to the intended recipient, you 
>>>are hereby notified that any reproduction, dissemination or distribution 
>>>of this communication is strictly prohibited. If you have received this 
>>>communication in error, please notify us immediately by replying to the 
>>>message and deleting it from your computer.
>>>
>>>Thank you.
>>>Tellabs