Wendy, Guohai, Please see below.
On Tuesday, April 14, 2015, Wendy Roome <[email protected]> wrote: > Guohai, > > I agree with Richard¹s earlier comment that the consensus of the WG was > that an endpoint is in one PID. Here are my reasons for supporting that. > > I believe that clients do not care about PIDs. PIDS are irrelevent. > Clients really care about endpoints. We introduce PIDs because an > endpoint-to-endpoint cost matrix is too large (for today¹s computers, > anyway!). So we partition the 2^32 (or 2^128) addresses into a few > hundred, or maybe a few thousand, equivalence classes, called PIDs, and > have a cost matrix from PID-PID rather than endpoint-endpoint. So when a > client wants to cost from EP1 to EP2, the client maps each EP to a PID, > and gets to costs between those PIDs. > > But that makes it essential that an endpoint is in only one PID. If it's > in several PIDs, then that endpoint has several different costs. Which one > should the client use? Not to say that I am convinced about an approach, but here is one, motivated by TCAM: introducing priority to distinguish multiple matches (in two dimensions), by assigning priority values to different entries. How stupid is this idea? Richard > It is like the old observation that a person with one watch always knows > the time of day. But a person with two watches is never sure. :-) > > So whenever someone suggests an extension that would allow an endpoint to > be in multiple PIDs, my immediate question is, What would a client do with > that information? Why would a client care? > > Incidentally, what if the server offered multiple Network Maps, with > different endpoint partitions, and different cost maps? That certainly is > supported by RFC 7285, and (in a sense) allows an endpoint to be in more > than one PID. However, it then raises the question of how the client > decides which Network Map to use. > > - Wendy Roome > > On 04/14/2015, 15:00, "[email protected] <javascript:;>" < > [email protected] <javascript:;>> > wrote: > > >Message: 1 > >Date: Tue, 14 Apr 2015 04:50:02 +0800 (GMT+08:00) > >From: ??? <[email protected] <javascript:;>> > >To: "Y. Richard Yang" <[email protected] <javascript:;>> > >Subject: Re: [alto] ALTO extension for representing SDN policies > >Message-ID: <[email protected] > <javascript:;>> > > > >Dear Richard, > > > >The longest prefix matching mechanism in ALTO maps each IP address into a > >single PID, this is the non-overlapping property of an ALTO network map. > >But in the end-to-end > >policies such as GBP, EPGs may be overlapped, some endpoints may belong > >to multiple EPGs, the longest prefix matching mechanism should be changed > >to adapt for that. > >I think that one prefix or IP address can be mapped into a PID list that > >contains one or multiple PIDs. We can still use the longest prefix > >matching, but the result is a PID list, > >not a single PID. > > > _______________________________________________ > alto mailing list > [email protected] <javascript:;> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=AwIFAw&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=5Pj2BLTpyrL0ldzx9_DaSxu_afHjts_St8R8QtTw858&s=FJJdzZgCaKLOKMlI5rWtjrIQAsSv42sNKU_qwrzMzI0&e= > -- Richard
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
