The IP Over NBMA (ION) Archive

["Eric W. Gray" <egret@nh.ultranet.com>]

Brian,

	I was a little confused by your notation.


You wrote (in part):
> 
> Masataka,
> >
> > As long as routers (in, on, interior, exerior,
> > not-a-router-but-a-routing-server or whatever) are short
> > cut, RESV can't be merged.
> >
> 
> Just to take a simple example, assume that R100 and R200
> are egress routers from an NBMA cloud, that R10 is somewhere
> inside the cloud, and that R1 is an ingress router to the cloud.
> 
> I am using "ingress" and "egress" to indicate the direction of
> a specific multicast flow. The sender is upstream of R1, and
> the receivers are downstream of R100 and R200.
> ...
> expressed as (R1,R10,R100|R200) using a fairly obvious notation.
> 

So far, so good...

> 
> At this point NHRP operates and inserts a shortcut such that
> the route is (R1,(R10,R100)|R200)
>

I thought I understood this - it seems to mean packets go to R10 (then 
R100) and R200 (directly).

> 
> or NHRP operates twice and we get
>              ((R1,R100)|(R1|R200))
>

Now you lost me.  Shouldn't this be (R1,R100|R200)?  I can't make any
sense out of it as it is...

> 
> In either case the RSVP soft state in the routers becomes invalid and
> will time out and be recreated, and presumably ISSLL will then
> reconfigure the VCs appropriately.
> 
> 2. NHRP operates before the PATH and RESV messages have done their
> job. The initial route is ((R1,R100)|(R1|R200)) for example.
>

Not too much more understandable looking at it a second time either...

> ...
> 
>   Brian Carpenter

--
Eric Gray