Hi Tomonori > -----Original Message----- > From: Tomonori TAKEDA [mailto:[EMAIL PROTECTED] > Sent: Saturday, March 03, 2007 8:52 AM > Hi Don, > > Thanks for summarizing issues. > > Questions for clarification. > > - Does the signaling change for shuffling only? Or for nesting and > stitching as well?
This change would be for all forms of L1VPN > > - If we introduce RD in addition to "L1vpn Globally unique I-D" > specified in the current I-D, we open the door to the extranet, I > assume. Does it imply that PIT is per RD, rather than per L1vpn > globally unique I-D? Not sure I follow you. RD uniquely identifies attachment of CE devices. This is different than L1VPN Globally unique ID. You could have an L1VPN that has CE with many different RDs. The PIT is per PE device. > > - It may be too early to say, but does this change impact how CE-PE TE > information is distributed (e.g., by BGP-TE)? I'm not sure since we have not quite agreed on the change it is just a proposal. We should discuss this when we discuss he changes. Regards, Don > > > Thanks, > Tomonori > > On Thu, 1 Mar 2007 14:56:02 -0500 > "Don Fedyk" <[EMAIL PROTECTED]> wrote: > > > Hi > > > > An issue came up when we were discussing optimizing the L1VPN auto > > discovery information and also an implication if we move to multiple > > domains. > > > > For reference the current the L1VPN basic mode draft has: > > > > > > (Client realm) > > +----+ +----+ > > | |<Port Index> <Port Index> | | > > | |CPI VPN-PPI | | > > ---| CE |-----------------------------| PE |--- > > | | <Port Index> | | > > | | PPI | | > > +----+ +----+ > > (Provider realm) > > > > > > And the auto discovery information is documented as: > > > > +---------------------------------------+ > > | Length (1 octet) | > > +---------------------------------------+ > > | PPI Length (1 octet) | > > +---------------------------------------+ > > | PPI (variable) | > > +---------------------------------------+ > > | CPI AFI (2 octets) | > > +---------------------------------------+ > > | CPI (length) | > > +---------------------------------------+ > > | CPI (variable) | > > +---------------------------------------+ > > > > > > When Signaling the procedure is to look up the remote CPI a > the near end > > PE and translates to a PPI for signaling purposes. If we > were to extend > > this information to multiple domains the PPI-CPI mapping > would carry the > > Provider address PPI outside the provider. > > > > One way to optimize this is to carry only the CPI with a Route > > Distinguisher, which is an 8 byte globally unique value. > > > > Like this: > > > > +---------------------------------------+ > > | Length (2 octets) | > > +---------------------------------------+ > > | RD (8 octets) | > > ~ ~ > > +---------------------------------------+ > > | CPI1 (length 1 octet) | > > +---------------------------------------+ > > | CPI1 (variable) | > > +---------------------------------------+ > > | CPI2 (length 1 octet) | > > +---------------------------------------+ > > | CPI2 (variable) | > > +---------------------------------------+ > > | etc | > > > > While the RD is larger the actual space for carrying > multiple CPIs will > > be reduced. The remote PE is inferred from the BGP Next Hop > carried in > > the auto-discovery routes. The information in these records is all > > globally unique addressing information and independent of provider > > attachment. This aligns with the other auto discovery schemes. > > > > Note the PPI and VPN-PPI remain but are local information only. > > > > This also implies a signaling change. The changes would > include look up > > CPI for a given RD, Signal to the destination associated PE > and include > > the RD and CPI in signaling to allow the destination PE to > resolve the > > customer port information. > > > > We would like to solicit comments on these changes. > > > > Thanks, > > Don > > > > _______________________________________________ > > L1vpn mailing list > > L1vpn@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/l1vpn > > _______________________________________________ L1vpn mailing list L1vpn@lists.ietf.org https://www1.ietf.org/mailman/listinfo/l1vpn
