The Routing Over Large Clouds Mailing List Archive by date

[Curtis Villamizar <curtis@ans.net>]

In message <rgc.1150546329B@hogpa.ho.att.com>, "Robert G. Cole" writes:
> >
> >Bob,
> >
> >Major transit routers today are seeing on the order of 10,000 unique
> >destination addresses over short periods of time (90 second sampling).
> >If a transit router does not wish to support 10,000 VC (keeping in
> >mind that the entire VCI space is 64K), then it would probably be
> >configured to forward packets hop by hop only.
> >
> >I don't think deleting option (c) is needed.  This is a usage issue
> >more than anything.
> >
> >Curtis
> >
> 
> Does this mean that the only way to avoid multiple VCs being established
> for the same routed path thru multiple transit routers is to disable
> NHRP for transit routers?
> 
> Bob


I think there is more than one option.  

I actually think disabling NHRP for transit routers will be the one
most commonly used, but there are other options.  If a RSVP flowspec
comes along, a transit router would probably just add the flowspec to
an existing hop by hop VC for aggregated real time stuff and provide a
predictive service this way.  The amount of state associated with
adding the RSVP flowspec and dropping it is very small compared to
adding and dropping a VC.

You could disable option (c) if you know a router downstream will
establish a VC (for example if your service provider has asked you to
do so or told you that you will be charged for it).

If the VC is set up due to an RSVP flowspec, the RSVP packets might be
blocked until the VC is establised, then forwarded on the VC but the
flow itself sent along the hop by hop path.  This amounts to partially
disabling (c).

The risk of disabling (c) or partially disabling it is if there is
some reason (other end can't handle any more VCs for example) that the
direct connection can't be made.  Better to forward the packets than
drop them on the floor.

Curtis