 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
________________________________ From: rtgwg-bounces at ietf.org on behalf of PAPADIMITRIOU Dimitri Sent: Wed 11/06/2008 22:58 To: Yousuf, Mohammad A; John G. Scudder; ZININ Alex; akatlas at gmail.com Cc: rtgwg at ietf.org Subject: RE: Agenda topics for IETF-72 Hi Dimitri, Thanks for checking it out. >hi >i would like to understand the following point: >"This draft uses MAC Address Translation (MAT) to provide VLAN >functionality natively to BB (Backbone Bridging). Pair wise shortest >paths are calculated for each of the unique C-MACs (one per Chrysolite >switch)." Each of the 'virtual circuits' / Customer endpoints/ N-MACS are created as a sort of 'sub' MAC address of the WAN switch. This allows the cloud to just ignore the details when routing, and gives easy pairwise SPF paths. We will probably avoid developing the UNI as well. It isnt really necessary. see example type config below. If the customer cant do this then the switch can just MAT the packets, *with the customer restricted to a single circuit. int E0.1 <A sub interfce for each 'circuit' Source MAC-ADDRESS <customer end point ""N-MAC"" placed here> Dest MAC-ADDRESS <customer end point ""N-MAC"" placed here> >[...From rtgwg-bounces at ietf.org Thu Jun 12 06:50:42 2008 Return-Path: <rtgwg-bounces at ietf.org> X-Original-To: rtgwg-archive at optimus.ietf.org Delivered-To: ietfarch-rtgwg-archive at core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D59133A6AE6; Thu, 12 Jun 2008 06:50:41 -0700 (PDT) X-Original-To: rtgwg at core3.amsl.com Delivered-To: rtgwg at core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48EB93A6AE5 for <rtgwg at core3.amsl.com>; Thu, 12 Jun 2008 06:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, WEIRD_QUOTING=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2W2EZx3D4f-R for <rtgwg at core3.amsl.com>; Thu, 12 Jun 2008 06:50:30 -0700 (PDT) Received: from sernt13.essex.ac.uk (sernt13.essex.ac.uk [155.245.42.33]) by core3.amsl.com (Postfix) with ESMTP id 5C9CE3A6ADF for <rtgwg at ietf.org>; Thu, 12 Jun 2008 06:50:28 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Agenda topics for IETF-72 Date: Thu, 12 Jun 2008 14:50:52 +0100 Message-ID: <4E57829B0709A6488E2364ABB96082AF033CFCE3 at sernt13.essex.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: Agenda topics for IETF-72 Thread-Index: AcjKSKg8f2bHk3BBTmCd3QrSKZ7vgwBYyu4gABeZHsAAIS0n1wAAj6UwAABtH0AFrom: "Yousuf, Mohammad A" <mayous at essex.ac.uk> To: "Yousuf, Mohammad A" <mayous at essex.ac.uk>, "John G. Scudder" <jgs at juniper.net>, "ZININ Alex" <Alex.Zinin at alcatel-lucent.sg>, <akatlas at gmail.com> Cc: rtgwg at ietf.org X-BeenThere: rtgwg at ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request at ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/rtgwg> List-Post: <mailto:rtgwg at ietf.org> List-Help: <mailto:rtgwg-request at ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request at ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="==============41644113==" Sender: rtgwg-bounces at ietf.org Errors-To: rtgwg-bounces at ietf.org This is a multi-part message in MIME format.Title: RE: Agenda topics for IETF-72
|
From: rtgwg-bounces at ietf.org on behalf of
PAPADIMITRIOU Dimitri Hi Dimitri, Thanks
for checking it out. >hi Each
of the 'virtual circuits' / Customer endpoints/ N-MACS are created as a
sort of 'sub' MAC address of the WAN switch. This allows the cloud to just
ignore the details when routing, and gives easy pairwise SPF paths. We
will probably avoid developing the UNI as well. It isnt really necessary.
see example type config below. If the customer cant do this then the
switch can just MAT the packets, *with the customer restricted to a
single circuit. int
E0.1 <A sub interfce for each 'circuit' Source
MAC-ADDRESS <customer end point ""N-MAC""
placed here>
From: rtgwg-bounces at ietf.org on behalf of
PAPADIMITRIOU Dimitri Hi Dimitri, Thanks
for checking it out. >hi Each
of the 'virtual circuits' / Customer endpoints/ N-MACS are created as a
sort of 'sub' MAC address of the WAN switch. This allows the cloud to just
ignore the details when routing, and gives easy pairwise SPF paths. We
will probably avoid developing the UNI as well. It isnt really necessary.
see example type config below. If the customer cant do this then the
switch can just MAT the packets, *with the customer restricted to a
single circuit. int
E0.1 <A sub interfce for each 'circuit' Source
MAC-ADDRESS <customer end point ""N-MAC""
placed here> >[...] "Ospf-lite [LITE] will be used
as the link state routing protocol This is similar to the issues you faced in
the PWE3 mapping I Guess. We
appreciate your Q's / comments / time spent checking it out. Regards, Mohammad,
MT
>[...] "Ospf-lite [LITE] will be used
as the link state routing protocol This is similar to the issues you faced in
the PWE3 mapping I Guess. We
appreciate your Q's / comments / time spent checking it out. Regards, Mohammad,
MT
|
_______________________________________________ rtgwg mailing list rtgwg at ietf.org https://www.ietf.org/mailman/listinfo/rtgwg