[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: CNAP/ RegionIDs ?





I think you raced some good points another question which comes to mind is how
those regions and redirection relate to BGP routing. Somebody (forgot who)
raced that point at the last IETF.

For example, should regions have to match BGP CIDR block.

If not what does it help to redirect on layer 7 to surrogates
which are not close by on layer 3. Personally I think this should
be left up to the actual user of the protocol and should not
be part of the protocol definition but I would like to know 
what other people think. 

Oliver

Abbie Barbir writes:
 > 
 > hi,
 > 
 > see remarks inside
 > 
 > here I also post another question related to contnet TTL in CNAP.
 > 
 > The way it is working now there is a TTL associated with each contnet.
 > 
 > The point here do we need that?
 > how would that relate to number of messages?
 > can we just assume TTL inifinity until the contnet life time is explicitly 
 > specified.
 > 
 > 
 > ps: The CNAP draft is currently being updated, any further feedback,
 > remarks, questions should be sent to the list ASAP.
 > 
 > The same applies for CNAPComp.
 > 
 > thanks
 > 
 > abbie
 > 
 > > -----Original Message-----
 > > From: Delphine Kaplan [mailto:delphine.kaplan@activia.net]
 > > Sent: Thursday, February 14, 2002 10:39 AM
 > > To: cdn@ops.ietf.org
 > > Subject: CNAP/ RegionIDs ?
 > > 
 > > 
 > > 
 > > Reading the draft CNAP we realized there are some unclear definition
 > > about the Region IDs.
 > > 
 > > We use the acronym "RID" in place of "RegionID".
 > > RIDs are a grouping of areas (an area is a set of IP prefixes)
 > > and are used to link Content and Area ADVERTISE messages.
 > > One objective of RIDs is to reduce the size of messages exchanged
 > > (send only the added prefixes when newly delivered by a content) ,
 > > and to symplify the content management (withdrawing/adding
 > > content on areas identified by RIDs).
 > > 
 > > our questions are :
 > > 
 > > 1/ how do we know when a RID becomes obsolete ?
 > > - define a TTL for RIDs?
 > > - a RID is obsolete when replaced by a new one? (if TTL=0
 > >     this means RID is no more used),
 > > - explicit withdrawal of RIDs?
 > > - other ideas ?
 > > 
 > 
 > defining a TTL will lead to extra messages to be sent when the RID is still
 > valid by the TTL is close to expirey.
 > 
 > How about defining a RID , assign it a value of inifnity, then explicitly
 > withdraw the RID when it is no longer needed or valid .
 > 
 > > 2/ is the RID list an additive field (wrt Area ADVERTISE messages) ?
 > > for ex. when two CNs are connected to some
 > > identical areas with identical metrics, does it make sense 
 > > for one of the CN
 > > (non-authoritative for the area) to add its "CNAS:RID" before 
 > > forwarding
 > > the Area Advertisement further ? In this case we have to put 
 > > the CNAS in
 > > first part of RID field (similar to BGP community attribute).
 > 
 > how does this relate to regions that consists of subregions, like item 4.??
 > 
 > > 
 > > 3/ what is exactly the notion of "authoritative for a content"
 > > and the notion of "authoritative for an area" ?
 > > 
 > 
 > 
 > > 4/ are hierarchy of RIDs (meta-RIDs) of some interest ?
 > > in other words should we explicitly handle grouping of RID
 > > (defining a RID which is a set of RIDs is already possible but the
 > > hierarchical relation can not be explicitly stated)
 > > 
 > > 
 > yes, I think it should be of interest.
 > 
 > 
 > > Delphine & Martin
 > > 
 > > 
 > > 
 > > 
 > >