Subject: CREDITOS PERSONALES

From: "[email-masked]" <[email-masked]>
Date: Mon, 29 Sep 2008 11:03:16 +0200

NOTEBOOKS y COMPUTADORAS con GARANTIA ENTREGA EN LOCAL EN LA ZONA DE CABALLITO - CAPITAL FEDERAL
ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA y EN NUESTRO LOCAL
CREDITOS PERSONALES HASTA EN 36 CUOTAS

EMail: [email-masked]
CEL: 15-3197-5821

Disponemos de lineas de credito para consumo previa aprobacion bancaria, con resolucion inmediata y 48Hs de acreditacion
En cuotas fijas y en pesos hasta en 60 cuotas

Para Compras en general
Los requisitos varian de acuerdo a su forma de demostrar ingresos:

1. Si trabaja en relacion de dependencia son: DNI, recibo de sueldo y 1 servicio de su domicilio
2. Si es monotributista son: DNI, ultimos 6 recibos de pago de monotributo y IIBB y 1 servicio de su domicilio
3. Si es Responsable Inscripto son: DNI, Declaracion Jurada de Impuesto a las ganancias y 1 servicio de su domicilio
4. Si es Jubilado o Pensionado son: DNI, Recibo de Jubilacion o Pension y 1 servicio de su domicilio
5. Tambien puede demostrar ingresos de manera informal a traves del consumo en su tarjeta de credito, sin usar limite de la misma y usandola solo para calificar, los requisitos son: DNI, tarjeta de credito y ultimo resumen de la Tarjeta de Credito
6. Creditos a Jubilados y Pensionados de ANSES, y a ex-combatientes de Malvinas Argentinas con descuento directo en el haber mensual

Puede sumar ingresos con parientes o amigos en caso de que no llegue con su recibo, que tiene que ser mayor de $450

Tambien disponible para personas que residan en el interior del pais, debe llevar la documentacion a la sucursal de OCA mas cercana previa carga de su legajo
Preaprobacion telefonica o a traves de MSN o telefono con minimos datos

Envelope-to: [email-masked]
Delivery-date: Fri, 26 Sep 2008 16:06:20 +0000
To: IETF-Announce <[email-masked]> 
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-ccamp-rfc4420bis (Encoding of Attributes  for Multiprotocol Label Switching (MPLS) Label Switched Path  (LSP) Establishment Using RSVP-TE) to Proposed Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Message-Id: <[email-masked]>
Date: Fri, 26 Sep 2008 09:03:53 -0700 (PDT)

The IESG has received a request from the Common Control and Measurement 
Plane WG (ccamp) to consider the following document:

- 'Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label 
   Switched Path (LSP) Establishment Using RSVP-TE '
   <draft-ietf-ccamp-rfc4420bis-03.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2008-10-10. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc4420bis-03.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17120&rfc_flag=0

Delivery-date: Wed, 24 Sep 2008 12:49:28 +0000
From: David McWalter <[email-masked]>
To: "[email-masked]" <[email-masked]>
CC: Andrew Rhodes <[email-masked]>, Nic Neate <[email-masked]>
Date: Wed, 24 Sep 2008 13:47:09 +0100
Subject: FW: draft-rhodes-rsvp-recovery-signaling-00
Accept-Language: en-US
acceptlanguage: en-US

Dear all,

We propose this update to RSVP recovery signaling.

Comments would be welcome.
Andrew Rhodes, Nic Neate, David McWalter.

http://www.ietf.org/internet-drafts/draft-rhodes-ccamp-rsvp-recovery-fix-00=
.txt

Title:
RSVP-TE Recovery Signaling Fixes

Abstract:
This document updates the ASSOCIATION object used in RSVP-TE signaling of E=
nd-to-End and Segment Recovery.  This document solves problems with existin=
g Segment Recovery procedures, and also makes possible recovery paths that =
cross addressing domain boundaries.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf =
Of David McWalter
Sent: 02 September 2008 12:23
To: [email-masked]
Cc: Andrew Rhodes; Nic Neate
Subject: FW: draft-rhodes-rsvp-recovery-signaling-00

Dear all,

This mail contains an udpate on our work with RSVP recovery signaling.

We are considering changes to RSVP signaling that
-  allow segment recovery to use merge points other than egress (rhodes dra=
ft section 3.1)
-  allow inter-domain e2e and SR (section 3.2)

Initially, we will not propose solutions that
-  allow protecting LSPs themselves to be protected (section 3.3)
-  prevent loss of traffic on overlapping repairs (section 3.4)

We shall aim to be backward-compatible with 4872, as we know that deploymen=
ts exist.  We shall not aim to be back-compatible with 4873, as there seem =
to be fundamental problems, described in sections 3.1 & 4.1 of the rhodes p=
roblem draft, below.  We shall try to keep changes minimal.

We'd be glad to hear opinions, and we would welcome collaboration.

Andrew Rhodes, Nic Neate, David McWalter.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf =
Of David McWalter
Sent: 06 August 2008 10:05
To: [email-masked]
Cc: Andrew Rhodes; Nic Neate
Subject: draft-rhodes-rsvp-recovery-signaling-00

Dear all,

We would welcome comments on this draft.

Andrew Rhodes, Nic Neate, David McWalter.

http://www.ietf.org/internet-drafts/draft-rhodes-rsvp-recovery-signaling
-00.txt

Title:
Problems observed with RSVP recovery signaling

Abstract:
Implementation experience with RSVP-TE recovery signaling has uncovered som=
e problems.  Associations between LSPs in different sessions are forbidden.=
  Protecting LSPs cannot themselves be protected.  Overlapping repairs caus=
e loss of traffic.  This draft provides details of these problems for the c=
ommunity to consider.

Delivery-date: Tue, 23 Sep 2008 03:38:12 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'
Date: Mon, 22 Sep 2008 22:36:43 -0500
From: "Bardalai, Snigdho" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C91D2D.98DE8ECB
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Adrian,
=20
I have a few comments on the link local approach that could possibly be =
used to reduce the amount of LSA information being distributed for a PCE =
based optical network.
=20
Basic behavior requirements:
1. A PCC should advertise RWA information only to a PCE neighbor and may =
avoid advertising to another PCC.
2. A PCE should advertise RWA information to another PCE neighbor but =
may avoid advertising to another PCC.=20
=20
So in general RWA information may be advertised only to PCE neighbors =
and "filtered" out for other neighbors. Non-RWA information should not =
be "filtered" (e.g. PCE discovery related LSAs).
=20
>From an implementation perspective the "filteration" function can be =
performed very simply by keeping track of the neighbor type (i.e. by =
matching the PCE address learned during PCE discovery) and then applying =
the rule - if neighbor type is PCE then advertise RWA information else =
don't.
=20
Thanks,
Snigdho
=20
=20

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Monday, August 11, 2008 12:25 PM
To: Bardalai, Snigdho; [email-masked]; [email-masked]
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,

I have the following comments on this draft. I was wondering what were =
the objectives for the IGP evaluation. IMHO the evaluation from WSON =
perspective should address the following:
1. IGP usage in the context of traditional distributed solutions for =
WSON=20
[Dan] With the situation that TE information is already be carried by =
IGP, it's nature to think that the wavelength information can also be =
carried by IGP. I am not saying it should be, but it's worth to look at.
[Bardalai, Snigdho] Do you see any particular issues with using the IGP =
for this purpose ?
[Dan] From the result of the simulation, the OSPF convergency time takes =
a liitle bit longer when the entire network restarts. Because the WSON =
information is added in the OSPF LSA. During the network running =
normally, the update of wavelength availability information doesn't =
impact the IGP performance obviously.
[Adrian] Certainly, from the point of view of someone coming at this =
without an implementation (I used to have one :-), the concern is that =
adding the RWA information to the IGP might mean that there was simply =
too much information to be distributed. What Dan's draft is trying to do =
is show the dimensions of the information and how dynamic it is. From =
this, we can quickly see how things will scale.
I do not believe that there is an issue with the interaction with IP =
routing, but I guess we should consider that it is possible that the DCN =
will be a real IP network carrying other traffic and that we need to not =
disrupt IGP convergence in that network. Mechanisms exist (or are being =
developed) to make that safe, and Dan's I-D should be able to tell us =
how important it is to use them.
=20
2. IGP usage in the context of PCE solutions for WSON
[Dan] It's a potential way for PCE to get the wavelength information.
[Bardalai, Snigdho] Since the PCE is the location where path-computation =
takes place is it possible to limit LSA advertisements from PCC to PCE =
neighbors, instead of to every PCC neighbor?
[Dan] You are right, PCC which doesn't do the path-computation doesn't =
need this kind of information.
[Adrian] This is an important point which you raised in conversation =
with me in Dublin: it is possible to consider using link-local scope =
flooding of RWA information from PCC to PCE so that it goes no further. =
But there is a clear trade-off... with how many PCCs will a PCE be =
required to maintain an IGP association? There is also a quesiton to be =
answered about the function required for restoration - how much =
information does the head-end LSR need to perform rapid, "best-effort" =
path computation to restore LSPs after a network failure? This =
information *does* need to be flooded. The informaiton model I-D is =
intended to help with this question.

3. Flooding and refresh of static and dynamic link state updates
[Dan] Try to figure out the impact to the performance of IGP.
[Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? =
Ex. using the OSPF "do not age" concept?
[Dan] Yes, it's possible to take this way to reduce the protocol =
traffic. But we should consider the scenario when a node gets restart or =
goes down, so the HELLO message may still need to be kept.
[Adrian] Yes. You are both right. We should treat "static" as truely =
static and not needing refresh. We can handle node-down and link-down =
events without the need to time out the LSAs containing the static data =
if we link the behavior to the time-out of other node/link information. =
But we *do* need to consider the amount of information that will be held =
in LSA DBs and need to be flooded at start of day and in node restart as =
below.

4. Data base sync-up during node restarts
[Dan] Yes, this should be considered. Especially the very large amount =
of data will be sent to the restarting node. We may consider the point =
to point data exchange instead of flooding the LSA updates. Or slice the =
big data packet into small pieces.
[Bardalai, Snigdho] This is little tricky, I would be interested to see =
if there is a clean solution.
[Adrian] An important point to consider (in OSPF) is what happens in a =
lossy environment if the LSA gets very large. In this case it will be =
fragmented into very many IP packets and there will be a good =
statistical likelihood of at least one packet being lost. That means =
that the LSA might never get delivered whiled the DCN will get hammered. =
One solution (thanks, Igor) is to break the information down into =
smaller LSAs. Since the information is essentially lists or matrices, =
this is quite easy to do.

Could you please let me know if the above is within the current scope? I =
believe that these are important.=20
[Adrian] Very much in scope!
=20
Cheers,
Adrian

------_=_NextPart_001_01C91D2D.98DE8ECB
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">

<META content=3D"MSHTML 6.00.2900.3395" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D345591403-23092008><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
Adrian,</FONT></SPAN></DIV>
<DIV><SPAN class=3D345591403-23092008><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D345591403-23092008><FONT face=3DArial color=3D#0000ff =
size=3D2>I have=20
a few comments on the link local approach that could possibly be used to =
reduce=20
the amount of LSA information being distributed for a PCE based optical=20
network.</FONT></SPAN></DIV>
<DIV><SPAN class=3D345591403-23092008><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D345591403-23092008><FONT face=3DArial color=3D#0000ff =
size=3D2>Basic=20
behavior requirements:</FONT></SPAN></DIV>
<DIV><SPAN class=3D345591403-23092008><FONT face=3DArial color=3D#0000ff =
size=3D2>1. A=20
PCC should advertise&nbsp;RWA information only to a PCE neighbor and may =
avoid=20
advertising to another PCC.</FONT></SPAN></DIV>
<DIV><SPAN class=3D345591403-23092008><FONT face=3DArial color=3D#0000ff =
size=3D2>2. A=20
PCE should advertise RWA information to another PCE neighbor but may =
avoid=20
advertising to another PCC. </FONT></SPAN></DIV>
<DIV><SPAN class=3D345591403-23092008><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D345591403-23092008><FONT face=3DArial color=3D#0000ff =
size=3D2>So in=20
general RWA information may be advertised only to PCE neighbors and =
"filtered"=20
out for other neighbors. Non-RWA&nbsp;information should not be =
"filtered"=20
(e.g.&nbsp;PCE discovery related LSAs).</FONT></SPAN></DIV>
<DIV><SPAN class=3D345591403-23092008><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D345591403-23092008><FONT face=3DArial color=3D#0000ff =
size=3D2>From=20
an implementation perspective the "filteration" function can be =
performed very=20
simply by keeping track of the neighbor type (i.e. by matching the PCE =
address=20
learned during PCE discovery) and then applying the rule=20
-&nbsp;i</FONT></SPAN><SPAN class=3D345591403-23092008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>f neighbor type is PCE then advertise RWA =
information else=20
don't.</FONT></SPAN></DIV>
<DIV><SPAN class=3D345591403-23092008><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D345591403-23092008><FONT face=3DArial color=3D#0000ff =

size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=3D345591403-23092008><FONT face=3DArial color=3D#0000ff =

size=3D2>Snigdho</FONT></SPAN></DIV>
<DIV><SPAN class=3D345591403-23092008><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D345591403-23092008><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE>
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Adrian Farrel=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Monday, August 11, 2008 =
12:25=20
  PM<BR><B>To:</B> Bardalai, Snigdho; [email-masked];=20
  [email-masked]<BR><B>Subject:</B> Re: Comments on=20
  'draft-li-ccamp-wson-igp-eval-01.txt'<BR><BR></FONT></DIV>
  <DIV>Hi,</DIV>
  <BLOCKQUOTE=20
  style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #f5f5f5 2px solid; MARGIN-RIGHT: 0px">
    <DIV>I have the following comments on this draft. I was wondering =
what were=20
    the objectives for the IGP evaluation. IMHO the evaluation from WSON =

    perspective should address the following:<BR>1. IGP usage in the =
context of=20
    traditional distributed solutions for WSON <BR><FONT =
color=3D#000080>[Dan]=20
    With the situation that TE information is already be carried by IGP, =
it's=20
    nature to think that the wavelength information can also be carried =
by IGP.=20
    I am not saying it should be, but it's worth to look =
at.<BR></FONT><FONT=20
    color=3D#808000>[Bardalai, Snigdho] Do you see any particular issues =
with=20
    using the IGP for this purpose ?</FONT></DIV>
    <DIV><FONT color=3D#800000>[Dan] From the result of the =
simulation,&nbsp;the=20
    OSPF convergency time&nbsp;takes a liitle bit longer when the entire =
network=20
    restarts. Because&nbsp;the WSON information is added in the OSPF=20
    LSA.&nbsp;During the network running normally, the update of =
wavelength=20
    availability information&nbsp;doesn't&nbsp;impact the IGP =
performance=20
    obviously.</FONT></DIV>
    <DIV><FONT color=3D#cc0000>[Adrian] Certainly, from the point of =
view of=20
    someone coming at this without an implementation (I used&nbsp;to =
have one=20
    :-), the concern is that adding the RWA information to the IGP might =
mean=20
    that there was simply too much information to be distributed. What =
Dan's=20
    draft is trying to do is show the dimensions of the information =
and&nbsp;how=20
    dynamic it is. From this, we can quickly see how things will=20
    scale.</FONT></DIV>
    <DIV><FONT color=3D#800000><FONT color=3D#cc0000>I do not believe =
that there is=20
    an issue with the interaction with IP routing, but I guess we should =

    consider that it is possible that the DCN will be a real IP network =
carrying=20
    other traffic and that we need to not disrupt IGP convergence in =
that=20
    network. Mechanisms exist (or are being developed) to make that =
safe, and=20
    Dan's I-D should be able to tell us how important it is to use=20
    them.</FONT><BR></FONT>&nbsp;<BR>2. IGP usage in the context of PCE=20
    solutions for WSON<BR><FONT color=3D#000080>[Dan] It's a potential =
way for PCE=20
    to get the wavelength information.<BR></FONT><FONT =
color=3D#808000>[Bardalai,=20
    Snigdho] Since the PCE is the location where path-computation takes =
place is=20
    it possible to limit LSA advertisements from PCC to PCE neighbors, =
instead=20
    of to every PCC neighbor?</FONT></DIV>
    <DIV><FONT color=3D#800000>[Dan] You are right, PCC which doesn't do =
the=20
    path-computation doesn't need this kind of information.</FONT></DIV>
    <DIV><FONT color=3D#800000><FONT color=3D#cc0000>[Adrian] This is an =
important=20
    point which you raised in conversation with me in Dublin: it is =
possible to=20
    consider using link-local scope flooding of RWA information from PCC =
to PCE=20
    so that it goes no further. But there is a clear trade-off... with =
how many=20
    PCCs will a PCE be required to maintain an IGP association? There is =
also a=20
    quesiton to be answered about the function required for restoration =
- how=20
    much information does the head-end LSR need to perform rapid, =
"best-effort"=20
    path computation to restore LSPs after a network failure? This =
information=20
    *does* need to be flooded. The informaiton model I-D is intended to =
help=20
    with this question.</FONT><BR></FONT><BR>3. Flooding and refresh of =
static=20
    and dynamic link state updates<BR><FONT color=3D#000080>[Dan] Try to =
figure=20
    out the impact to the performance of IGP.<BR></FONT><FONT=20
    color=3D#808000>[Bardalai, Snigdho] Is it possible to limit =
refreshing of=20
    static LSA? Ex. using the OSPF "do not age" concept?</FONT></DIV>
    <DIV><FONT color=3D#800000>[Dan] Yes, it's possible to take this way =
to reduce=20
    the protocol traffic. But we should consider the scenario when a =
node gets=20
    restart or goes down, so the HELLO message may still need to be=20
    kept.</FONT></DIV>
    <DIV><FONT color=3D#800000><FONT color=3D#cc0000>[Adrian] Yes. You =
are both=20
    right. We should treat "static" as truely static and not needing =
refresh. We=20
    can handle node-down and link-down events without the need to time =
out the=20
    LSAs containing the static data if we link the behavior to the =
time-out of=20
    other node/link information. But we *do* need to consider the amount =
of=20
    information that will be held in LSA DBs and need to be flooded at =
start of=20
    day and in node restart as below.</FONT><BR></FONT><BR>4. Data base =
sync-up=20
    during node restarts<BR><FONT color=3D#000080>[Dan] Yes, this should =
be=20
    considered. Especially the very large amount of data will be sent to =
the=20
    restarting node. We may consider the point to point data exchange =
instead of=20
    flooding the LSA updates. Or slice the big data packet into small=20
    pieces.<BR></FONT><FONT color=3D#808000>[Bardalai, Snigdho] This is =
little=20
    tricky, I would be interested to see if there is a clean=20
    solution.</FONT></DIV>
    <DIV><FONT color=3D#cc0000>[Adrian] An important point to consider =
(in OSPF)=20
    is what happens in a lossy environment if the LSA gets very large. =
In this=20
    case it will be fragmented into very many IP packets and there will =
be a=20
    good statistical likelihood of at least one packet being lost. That =
means=20
    that the LSA might never get delivered whiled the DCN will get =
hammered. One=20
    solution (thanks, Igor) is to break the information down into =
smaller LSAs.=20
    Since the information is essentially lists or matrices, this is =
quite easy=20
    to do.</FONT></DIV>
    <DIV><FONT color=3D#808000><BR></FONT>Could you please let me know =
if the=20
    above is within the current scope? I believe that these are =
important.=20
    <BR><FONT color=3D#cc0000>[Adrian] Very much in scope!</FONT></DIV>
    <DIV><FONT color=3D#cc0000></FONT>&nbsp;</DIV>
    <DIV><FONT color=3D#cc0000>Cheers,</FONT></DIV>
    <DIV><FONT color=3D#cc0000>Adrian</FONT></DIV></BLOCKQUOTE>
  <META content=3DTYUWAMWXFN =
name=3DSKYPE_FRAMEID><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C91D2D.98DE8ECB--

Envelope-to: [email-masked]
Delivery-date: Mon, 22 Sep 2008 21:38:00 +0000
To: [email-masked], [email-masked]
Subject: RFC 5339 on Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN)
From: [email-masked]
Cc: [email-masked], [email-masked]
Message-Id: <[email-masked]>
Date: Mon, 22 Sep 2008 14:34:10 -0700 (PDT)

A new Request for Comments is now available in online RFC libraries.

        RFC 5339

        Title:      Evaluation of Existing GMPLS Protocols 
                    against Multi-Layer and Multi-Region Networks 
                    (MLN/MRN) 
        Author:     JL. Le Roux, Ed.,
                    D. Papadimitriou, Ed.
        Status:     Informational
        Date:       September 2008
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      25
        Characters: 53998
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ccamp-gmpls-mln-eval-06.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5339.txt

This document provides an evaluation of Generalized Multiprotocol
Label Switching (GMPLS) protocols and mechanisms against the
requirements for Multi-Layer Networks (MLNs) and Multi-Region Networks
(MRNs).  In addition, this document identifies areas where additional
protocol extensions or procedures are needed to satisfy these
requirements, and provides guidelines for potential extensions.  
This memo provides information for the Internet community.

This document is a product of the Common Control and Measurement Plane Working Group of the IETF.

INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

Delivery-date: Tue, 16 Sep 2008 04:25:57 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Fw: Liaison on ASON Routing Topics
Date: Tue, 16 Sep 2008 05:24:11 +0100

FYI
----- Original Message ----- 
From: "Ross Callon" <[email-masked]>
To: <[email-masked]>
Cc: "Scott Bradner" <[email-masked]>; "IAB" <[email-masked]>; "Russ Housley" 
<[email-masked]>; <[email-masked]>; "Trowbridge, Stephen J 
(Steve)" <[email-masked]>; "Lam, Hing-Kam (Kam)" 
<[email-masked]>; "Malcolm Betts" <[email-masked]>; 
<[email-masked]>; "Brungard, Deborah A, ALABS" <[email-masked]>; "Adrian 
Farrel" <[email-masked]>; "Ross Callon" <[email-masked]>
Sent: Monday, September 15, 2008 10:18 PM
Subject: Liaison on ASON Routing Topics (with reference added)

Thank you for your liaison dated 2/29/08 about handling ASON routing
topics in a joint forum.

At the 71st IETF meeting in Philadelphia in March this year, we  held
an extra meeting to discuss the open issues related to ASON  routing,
and we are grateful to the ITU-T experts who attended,  some of them
travelling specially for this meeting. During the  meeting it was
agreed that work should commence on a revision of  RFC 4258 to
address the concerns raised by the ITU.

This work is being led by a team of volunteers with considerable ITU
and IETF experience, and can be discussed on an open mailing  list.
Subscription details can be found at
https://www.ietf.org/mailman/listinfo/ason-routing

For the moment, this work is under the care of the CCAMP working
group within the Routing Area of the IETF. Questions can be sent to
the Routing Area Directors:
  - Ross Callon ([email-masked])
  - Dave Ward ([email-masked] )
or to the CCAMP working group co-chairs:
  - Deborah Brungard ([email-masked])
  - Adrian Farrel ([email-masked])

We look forward to further cooperation between the ITU and IETF.

Sincerely,
Ross Callon
Dave Ward

Reference:

https://datatracker.ietf.org/liaison/428/

Delivery-date: Mon, 15 Sep 2008 13:32:15 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-pc-and-sc-reqs-06.txt 
Date: Mon, 15 Sep 2008 06:30:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : draft-ietf-ccamp-pc-and-sc-reqs-06.txt
	Author(s)       : D. Caviglia, et al.
	Filename        : draft-ietf-ccamp-pc-and-sc-reqs-06.txt
	Pages           : 11
	Date            : 2008-09-15

>From a Carrier perspective, the possibility of turning a Permanent
Connection (PC) into a Soft Permanent Connection (SPC) and vice
versa, without actually affecting Data Plane traffic being carried
over it, is a valuable option.  In other terms, such operation can be
seen as a way of transferring the ownership and control of an
existing and in-use Data Plane connection between the Management
Plane and the Control Plane, leaving its Data Plane state untouched.

This memo sets out the requirements for such procedures within a
Generalized Multiprotocol Label Switching (GMPLS) network.

Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc-reqs-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-pc-and-sc-reqs-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Fri, 12 Sep 2008 18:35:25 +0000
Date: Fri, 12 Sep 2008 14:34:11 -0400
From: Matt Tylenda <[email-masked]>
To: [email-masked]
Subject: MPLS2008 International Conference, October 19-22, Washington DC

The 11th annual MPLS 2008 is set to open on October 19, 2008 in Washington,
DC 

The technical program details and sponsors list is available at
www.mpls2008.com 

Registration is still open -
http://www.isocore.com/mpls2008/registration/attendees.htm 

The conference interop demonstration is planned to showcase key interesting
technologies including Mobile Backhaul, first ever interoperability of GMPLS
control Ethernet Label Switching (GELS), PCE/PCC, and PBB/Ethernet & MPLS
OAM. Technical and participation details are available at
-http://www.isocore.com/mpls2008/program/inter_op.htm 

We look forward to seeing you at the show!

-- 
Matt Tylenda
[email-masked]
ISOCORE

Delivery-date: Fri, 12 Sep 2008 17:19:45 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Fw: Nomcom call for candidates 
Date: Fri, 12 Sep 2008 18:17:37 +0100

The NomCom chair, Joel Halpern, asks that you consider nominating and/or 
standing for any of the open positions on the IAB or IESG.

Please look at  his email and the NomCom web page that he links to.

Thanks,
Adrian

> The 2008-9 IETF Nominating Committee needs your help.
> We have started getting candidates.
> If we are going to do our job in time, we have only 3 more weeks to get
> enough candidates to have a reasonable pool for all the jobs.
> At the moment, we do not have a reasonable pool for any jobs.
>
> If you are willing to serve, please nominate yourself.
> If there is someone you think would do a good job, please nominate them.
>
> The web site at:
>    http://wiki.tools.ietf.org/group/nomcom/08
> Has the list of positions we are seeking people for, as well as tools for
> providing both nominations and feedback.
>
> Alternatively, you can submit nominations by sending email to me.
>
> Please help us.
>
> Thank you,
> Joel M. Halpern
> [email-masked]
> [email-masked] 

Delivery-date: Tue, 09 Sep 2008 21:43:18 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Yakov Rekhter" <[email-masked]>
Cc: "Yakov Rekhter" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Meanwhile, back on topic (BGP-TE) 
Date: Tue, 9 Sep 2008 22:42:31 +0100

Perfect.
Thanks for your patience.
Adrian
----- Original Message ----- 
From: "Yakov Rekhter" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: "Yakov Rekhter" <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, September 09, 2008 10:16 PM
Subject: Re: Meanwhile, back on topic (BGP-TE)

> Adrian,
>
>> Yakov,
>>
>> OK, that helps a lot.
>
> Glad to hear this.
>
>> My concern was that to be fully useful, the VPN route
>> TE information needs to be combined with TE information about the 
>> potential
>> paths to the PE.
>>
>> What I did not want to see was that the VPN route TE information would be
>> updated by a transit node to reflect any information about the path to 
>> the
>> PE.
>>
>> This appears to be a limitation you intended to impose, so it is just 
>> about
>> getting the words right. I like what you have suggested below. Can you 
>> add
>> some form of "...and MUST NOT be modified by any other BGP speaker..." or 
>> do
>> you consider that part of the definition of the attribute inherited from 
>> the
>> base BGP spec?
>
> How about adding the following:
>
>  Procedures for modifying the Traffic Engineering attribute,
>  when re-advertising a route that carries such attribute
>  are outside the scope of this document.
>
> Yakov.
>
>>
>> Cheers,
>> Adrian
>>
>> ----- Original Message ----- 
>> From: "Yakov Rekhter" <[email-masked]>
>> To: "Adrian Farrel" <[email-masked]>
>> Cc: "Yakov Rekhter" <[email-masked]>; <[email-masked]>;
>> <[email-masked]>
>> Sent: Tuesday, September 09, 2008 6:55 PM
>> Subject: Re: Meanwhile, back on topic (BGP-TE)
>>
>>
>> > Adrian,
>> >
>> >> Hi Yakov et al.,
>> >>
>> >> Thanks for the 02 revision
>> >>
>> >> The new text in the Abstract and Introduction goes a long way to
>> >> addressing
>> >> my concerns.
>> >>
>> >>    The scope and applicability of this attribute currently excludes 
>> >> its
>> >>    use for non-VPN deployment scenarios.
>> >
>> > Glad to hear this.
>> >
>> >> But it doesn't answer my multi-AS question. What will an ASBR 
>> >> advertise
>> >> onwards?
>> >
>> > ASBRs just re-advertise VPN routes without modifying TE attribute
>> > of these routes.
>> >
>> >> The TE parameters that it receives from the source PE are the TE
>> >> parameters
>> >> of the PE-CE link to a specific port. If it advertises those 
>> >> parameters
>> >> it
>> >> is clearly not advertising the TE parameters of the route, but I am 
>> >> not
>> >> clear how a BGP speaker down the line can tell that this is just the
>> >> PE-CE
>> >> link that is being described. But to do otherwise would imply that the
>> >> ASBR
>> >> is making some assessment of the TE route available from the ASBR to 
>> >> the
>> >> PE.
>> >
>> > The TE information is associated with a *VPN* route, not with the
>> > (non-VPN) route from the ASBR to the PE.
>> >
>> >> This is the question I was trying to raise about "TE aggregation" 
>> >> (which
>> >> is
>> >> *not* route aggregation).
>> >>
>> >> It seems to me that this whole question is either out of scope of
>> >> requiring
>> >> significant future study.
>> >
>> > It seems to me that this whole question is due to the lack of
>> > understanding that the TE attribute is associated with a VPN route
>> > originated by a PE, not with a (non-VPN) route to the PE that
>> > originates the VPN route. The TE attribute of a VPN route is
>> > propagated "as is" by the VPN service provider(s), without any
>> > modifications.
>> >
>> > To make it clear that the draft only deals with using BGP TE
>> > attribute for VPN routes I would propose the following changes:
>> >
>> > 1. Section 1 and Section 2 replace
>> >
>> >   The scope and applicability of this attribute currently excludes its
>> >   use for non-VPN deployment scenarios.
>> >
>> > with
>> >
>> >  The scope and applicability of this attribute currently excludes its
>> >  use for non-VPN reachability information.
>> >
>> > 2. Section 2 replace
>> >
>> >   In certain cases (e.g., L1VPN [RFC5195]) it may be useful to augment
>> >   reachability information carried in BGP with the Traffic Engineering
>> >   information.
>> >
>> > with
>> >
>> >   In certain cases (e.g., L1VPN [RFC5195]) it may be useful to augment
>> >   VPN reachability information carried in BGP with the Traffic 
>> > Engineering
>> >   information.
>> >
>> >> Probably the solution that can get us to closure most quickly is one
>> >> where
>> >> we update your new text to say...
>> >>
>> >>    The scope and applicability of this attribute is currently limited 
>> >> to
>> >>    single-AS VPN deployment scenarios.
>> >
>> > So far you did not present any technical reason(s) to justify
>> > imposing this limitation.
>> >
>> >> I would also like to see a something added to Section 4 along the 
>> >> lines
>> >> of...
>> >>
>> >>    Traffic engineering aggregation is the process of reporting a set 
>> >> of
>> >> TE
>> >>    parameters for a single route where multiple paths exist across the
>> >>    domain. The results of TE aggregation MUST NOT be advertised
>> >>    using the Traffic Engineering Attribute.
>> >
>> > Could you please illustrate how the concept of "traffic engineering
>> > aggregation" is applicable in the context of VPN routing information
>> > advertised in BGP.
>> >
>> > Yakov.
>> >
>>
> 

Delivery-date: Tue, 09 Sep 2008 21:23:43 +0000
To: "Adrian Farrel" <[email-masked]>
cc: "Yakov Rekhter" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Meanwhile, back on topic (BGP-TE) 
Date: Tue, 09 Sep 2008 14:16:50 -0700
From: Yakov Rekhter <[email-masked]>

Adrian,

> Yakov,
> OK, that helps a lot. 

Glad to hear this.

> My concern was that to be fully useful, the VPN route 
> TE information needs to be combined with TE information about the potential 
> paths to the PE.
> 
> What I did not want to see was that the VPN route TE information would be 
> updated by a transit node to reflect any information about the path to the 
> PE.
> 
> This appears to be a limitation you intended to impose, so it is just about 
> getting the words right. I like what you have suggested below. Can you add 
> some form of "...and MUST NOT be modified by any other BGP speaker..." or do 
> you consider that part of the definition of the attribute inherited from the 
> base BGP spec?

How about adding the following:

  Procedures for modifying the Traffic Engineering attribute,
  when re-advertising a route that carries such attribute
  are outside the scope of this document.

Yakov.

> 
> Cheers,
> Adrian
> 
> ----- Original Message ----- 
> From: "Yakov Rekhter" <[email-masked]>
> To: "Adrian Farrel" <[email-masked]>
> Cc: "Yakov Rekhter" <[email-masked]>; <[email-masked]>; 
> <[email-masked]>
> Sent: Tuesday, September 09, 2008 6:55 PM
> Subject: Re: Meanwhile, back on topic (BGP-TE)
> 
> 
> > Adrian,
> >
> >> Hi Yakov et al.,
> >>
> >> Thanks for the 02 revision
> >>
> >> The new text in the Abstract and Introduction goes a long way to 
> >> addressing
> >> my concerns.
> >>
> >>    The scope and applicability of this attribute currently excludes its
> >>    use for non-VPN deployment scenarios.
> >
> > Glad to hear this.
> >
> >> But it doesn't answer my multi-AS question. What will an ASBR advertise
> >> onwards?
> >
> > ASBRs just re-advertise VPN routes without modifying TE attribute
> > of these routes.
> >
> >> The TE parameters that it receives from the source PE are the TE 
> >> parameters
> >> of the PE-CE link to a specific port. If it advertises those parameters 
> >> it
> >> is clearly not advertising the TE parameters of the route, but I am not
> >> clear how a BGP speaker down the line can tell that this is just the 
> >> PE-CE
> >> link that is being described. But to do otherwise would imply that the 
> >> ASBR
> >> is making some assessment of the TE route available from the ASBR to the 
> >> PE.
> >
> > The TE information is associated with a *VPN* route, not with the
> > (non-VPN) route from the ASBR to the PE.
> >
> >> This is the question I was trying to raise about "TE aggregation" (which 
> >> is
> >> *not* route aggregation).
> >>
> >> It seems to me that this whole question is either out of scope of 
> >> requiring
> >> significant future study.
> >
> > It seems to me that this whole question is due to the lack of
> > understanding that the TE attribute is associated with a VPN route
> > originated by a PE, not with a (non-VPN) route to the PE that
> > originates the VPN route. The TE attribute of a VPN route is
> > propagated "as is" by the VPN service provider(s), without any
> > modifications.
> >
> > To make it clear that the draft only deals with using BGP TE
> > attribute for VPN routes I would propose the following changes:
> >
> > 1. Section 1 and Section 2 replace
> >
> >   The scope and applicability of this attribute currently excludes its
> >   use for non-VPN deployment scenarios.
> >
> > with
> >
> >  The scope and applicability of this attribute currently excludes its
> >  use for non-VPN reachability information.
> >
> > 2. Section 2 replace
> >
> >   In certain cases (e.g., L1VPN [RFC5195]) it may be useful to augment
> >   reachability information carried in BGP with the Traffic Engineering
> >   information.
> >
> > with
> >
> >   In certain cases (e.g., L1VPN [RFC5195]) it may be useful to augment
> >   VPN reachability information carried in BGP with the Traffic Engineering
> >   information.
> >
> >> Probably the solution that can get us to closure most quickly is one 
> >> where
> >> we update your new text to say...
> >>
> >>    The scope and applicability of this attribute is currently limited to
> >>    single-AS VPN deployment scenarios.
> >
> > So far you did not present any technical reason(s) to justify
> > imposing this limitation.
> >
> >> I would also like to see a something added to Section 4 along the lines
> >> of...
> >>
> >>    Traffic engineering aggregation is the process of reporting a set of 
> >> TE
> >>    parameters for a single route where multiple paths exist across the
> >>    domain. The results of TE aggregation MUST NOT be advertised
> >>    using the Traffic Engineering Attribute.
> >
> > Could you please illustrate how the concept of "traffic engineering
> > aggregation" is applicable in the context of VPN routing information
> > advertised in BGP.
> >
> > Yakov.
> > 
> 

Delivery-date: Tue, 09 Sep 2008 18:23:55 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Yakov Rekhter" <[email-masked]>
Cc: "Yakov Rekhter" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Meanwhile, back on topic (BGP-TE) 
Date: Tue, 9 Sep 2008 19:22:42 +0100

Yakov,

OK, that helps a lot. My concern was that to be fully useful, the VPN route 
TE information needs to be combined with TE information about the potential 
paths to the PE.

What I did not want to see was that the VPN route TE information would be 
updated by a transit node to reflect any information about the path to the 
PE.

This appears to be a limitation you intended to impose, so it is just about 
getting the words right. I like what you have suggested below. Can you add 
some form of "...and MUST NOT be modified by any other BGP speaker..." or do 
you consider that part of the definition of the attribute inherited from the 
base BGP spec?

Cheers,
Adrian

----- Original Message ----- 
From: "Yakov Rekhter" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: "Yakov Rekhter" <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, September 09, 2008 6:55 PM
Subject: Re: Meanwhile, back on topic (BGP-TE)

> Adrian,
>
>> Hi Yakov et al.,
>>
>> Thanks for the 02 revision
>>
>> The new text in the Abstract and Introduction goes a long way to 
>> addressing
>> my concerns.
>>
>>    The scope and applicability of this attribute currently excludes its
>>    use for non-VPN deployment scenarios.
>
> Glad to hear this.
>
>> But it doesn't answer my multi-AS question. What will an ASBR advertise
>> onwards?
>
> ASBRs just re-advertise VPN routes without modifying TE attribute
> of these routes.
>
>> The TE parameters that it receives from the source PE are the TE 
>> parameters
>> of the PE-CE link to a specific port. If it advertises those parameters 
>> it
>> is clearly not advertising the TE parameters of the route, but I am not
>> clear how a BGP speaker down the line can tell that this is just the 
>> PE-CE
>> link that is being described. But to do otherwise would imply that the 
>> ASBR
>> is making some assessment of the TE route available from the ASBR to the 
>> PE.
>
> The TE information is associated with a *VPN* route, not with the
> (non-VPN) route from the ASBR to the PE.
>
>> This is the question I was trying to raise about "TE aggregation" (which 
>> is
>> *not* route aggregation).
>>
>> It seems to me that this whole question is either out of scope of 
>> requiring
>> significant future study.
>
> It seems to me that this whole question is due to the lack of
> understanding that the TE attribute is associated with a VPN route
> originated by a PE, not with a (non-VPN) route to the PE that
> originates the VPN route. The TE attribute of a VPN route is
> propagated "as is" by the VPN service provider(s), without any
> modifications.
>
> To make it clear that the draft only deals with using BGP TE
> attribute for VPN routes I would propose the following changes:
>
> 1. Section 1 and Section 2 replace
>
>   The scope and applicability of this attribute currently excludes its
>   use for non-VPN deployment scenarios.
>
> with
>
>  The scope and applicability of this attribute currently excludes its
>  use for non-VPN reachability information.
>
> 2. Section 2 replace
>
>   In certain cases (e.g., L1VPN [RFC5195]) it may be useful to augment
>   reachability information carried in BGP with the Traffic Engineering
>   information.
>
> with
>
>   In certain cases (e.g., L1VPN [RFC5195]) it may be useful to augment
>   VPN reachability information carried in BGP with the Traffic Engineering
>   information.
>
>> Probably the solution that can get us to closure most quickly is one 
>> where
>> we update your new text to say...
>>
>>    The scope and applicability of this attribute is currently limited to
>>    single-AS VPN deployment scenarios.
>
> So far you did not present any technical reason(s) to justify
> imposing this limitation.
>
>> I would also like to see a something added to Section 4 along the lines
>> of...
>>
>>    Traffic engineering aggregation is the process of reporting a set of 
>> TE
>>    parameters for a single route where multiple paths exist across the
>>    domain. The results of TE aggregation MUST NOT be advertised
>>    using the Traffic Engineering Attribute.
>
> Could you please illustrate how the concept of "traffic engineering
> aggregation" is applicable in the context of VPN routing information
> advertised in BGP.
>
> Yakov.
> 

Delivery-date: Tue, 09 Sep 2008 17:57:02 +0000
To: "Adrian Farrel" <[email-masked]>
cc: "Yakov Rekhter" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Meanwhile, back on topic (BGP-TE) 
Date: Tue, 09 Sep 2008 10:55:00 -0700
From: Yakov Rekhter <[email-masked]>

Adrian,

> Hi Yakov et al.,
> 
> Thanks for the 02 revision
> 
> The new text in the Abstract and Introduction goes a long way to addressing 
> my concerns.
> 
>    The scope and applicability of this attribute currently excludes its
>    use for non-VPN deployment scenarios.

Glad to hear this.

> But it doesn't answer my multi-AS question. What will an ASBR advertise 
> onwards?

ASBRs just re-advertise VPN routes without modifying TE attribute
of these routes.

> The TE parameters that it receives from the source PE are the TE parameters 
> of the PE-CE link to a specific port. If it advertises those parameters it 
> is clearly not advertising the TE parameters of the route, but I am not 
> clear how a BGP speaker down the line can tell that this is just the PE-CE 
> link that is being described. But to do otherwise would imply that the ASBR 
> is making some assessment of the TE route available from the ASBR to the PE.

The TE information is associated with a *VPN* route, not with the 
(non-VPN) route from the ASBR to the PE. 
 
> This is the question I was trying to raise about "TE aggregation" (which is 
> *not* route aggregation).
> 
> It seems to me that this whole question is either out of scope of requiring 
> significant future study.

It seems to me that this whole question is due to the lack of
understanding that the TE attribute is associated with a VPN route
originated by a PE, not with a (non-VPN) route to the PE that
originates the VPN route. The TE attribute of a VPN route is
propagated "as is" by the VPN service provider(s), without any
modifications.

To make it clear that the draft only deals with using BGP TE
attribute for VPN routes I would propose the following changes:

1. Section 1 and Section 2 replace

   The scope and applicability of this attribute currently excludes its
   use for non-VPN deployment scenarios.
 
with

  The scope and applicability of this attribute currently excludes its
  use for non-VPN reachability information.

2. Section 2 replace 

   In certain cases (e.g., L1VPN [RFC5195]) it may be useful to augment
   reachability information carried in BGP with the Traffic Engineering
   information.

with

   In certain cases (e.g., L1VPN [RFC5195]) it may be useful to augment
   VPN reachability information carried in BGP with the Traffic Engineering
   information.

> Probably the solution that can get us to closure most quickly is one where 
> we update your new text to say...
> 
>    The scope and applicability of this attribute is currently limited to
>    single-AS VPN deployment scenarios.

So far you did not present any technical reason(s) to justify
imposing this limitation.

> I would also like to see a something added to Section 4 along the lines 
> of...
> 
>    Traffic engineering aggregation is the process of reporting a set of TE
>    parameters for a single route where multiple paths exist across the
>    domain. The results of TE aggregation MUST NOT be advertised
>    using the Traffic Engineering Attribute.

Could you please illustrate how the concept of "traffic engineering
aggregation" is applicable in the context of VPN routing information
advertised in BGP.

Yakov.

Delivery-date: Mon, 08 Sep 2008 23:04:09 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Yakov Rekhter" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Meanwhile, back on topic (BGP-TE)
Date: Tue, 9 Sep 2008 00:01:32 +0100

Hi Yakov et al.,

Thanks for the 02 revision

The new text in the Abstract and Introduction goes a long way to addressing 
my concerns.

   The scope and applicability of this attribute currently excludes its
   use for non-VPN deployment scenarios.

But it doesn't answer my multi-AS question. What will an ASBR advertise 
onwards?

The TE parameters that it receives from the source PE are the TE parameters 
of the PE-CE link to a specific port. If it advertises those parameters it 
is clearly not advertising the TE parameters of the route, but I am not 
clear how a BGP speaker down the line can tell that this is just the PE-CE 
link that is being described. But to do otherwise would imply that the ASBR 
is making some assessment of the TE route available from the ASBR to the PE.

This is the question I was trying to raise about "TE aggregation" (which is 
*not* route aggregation).

It seems to me that this whole question is either out of scope of requiring 
significant future study.

Probably the solution that can get us to closure most quickly is one where 
we update your new text to say...

   The scope and applicability of this attribute is currently limited to
   single-AS VPN deployment scenarios.

I would also like to see a something added to Section 4 along the lines 
of...

   Traffic engineering aggregation is the process of reporting a set of TE
   parameters for a single route where multiple paths exist across the
   domain. The results of TE aggregation MUST NOT be advertised
   using the Traffic Engineering Attribute.

Cheers,
Adrian

Delivery-date: Mon, 08 Sep 2008 14:01:43 +0000
Date: Mon, 8 Sep 2008 06:59:35 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)
To: Adrian Farrel <[email-masked]>
Cc: [email-masked], [email-masked]

--0-979517846-1220882375=:27131
Content-Type: text/plain; charset=us-ascii

Hi Adrian,
Please, see in-line.

Igor

----- Original Message ----
From: Adrian Farrel <[email-masked]>
To: Igor Bryskin <[email-masked]>
Cc: [email-masked]; [email-masked]
Sent: Monday, September 8, 2008 6:23:52 AM
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)

Hi Igor,

Not sure that the scope of this discussion is particularly appropriate to 
CCAMP and Softwires mailing lists. Might be more relevant on the L1VPN and 
OSPF lists. You could open a thread there if you want to debate this 
further.

IB>>As you remember it was not even me who started this discussion. I simply reacted to the following Yakov's statement addressed to the WGs :

> >And while on the subject of scaling, please keep in mind that BGP
> >only stores L1VPN routes on PEs that have sites of that VPN connected
> >to them, and on an RR if used, but *not* on any of the P routers. In
> >contrast, rfc5252 (OSPF for L1VPN autodiscovery) results in storing
> >*all VPN TE information for all the VPNs* on *all* the IGP nodes, both P
> >and PE. So, clearly BGP-based approach scales better than OSPF-based
> >approach.

In your reference below you seem to agree that this statement is not exactly correct. Now let me explain why I think that this discussion could be interesting to the CCAMP WG (and I will certainly annoy much more people now :=). *IF* GMPLS Control Plane (which includes OSPF and does not include BGP) can provide a viable alternative to L1VPN-BGP, then how about L2VPNs? This is important especially in the context of the MPLS-TP work, where GMPLS is the control plane of choice today, and it does not include BGP, but MPLS-TP still needs the L2VPN solution. So, should we extend GMPLS with BGP or this is not necessary?
Wouldn't this be a good discussion for CCAMP WG list? How about L2VPN, PWE3, MPLS TP lists? 

> Although multi-instance OSPF was enthusiastically discussed and is ongoing 
> work in OSPF WG, it was never discussed in the L1VPN context.

Please see RFC 5253 section 7.1

     Alternatively, a separate instance of
     the OSPF protocol can be used just between PEs for distributing
     membership information.

This appears to be exactly the point you are making. So perhaps we are all 
in agreement?

IB>> One thing what is missing IMO in this RFC (and is actually part of this discussion) is comparison of configuration efforts for BGP and OSPF solutions.
A solution may have good scalability properties but require enourmous configuration efforts, and thus become very expensive. Would you agree?

Thanks,
Igor

Adrian

--0-979517846-1220882375=:27131
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div><br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">Hi Adrian,<br>Please, see in-line.<br><br>Igor<br><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;">----- Original Message ----<br>From: Adrian Farrel &lt;[email-masked]&gt;<br>To: Igor Bryskin &lt;[email-masked]&gt;<br>Cc: [email-masked]; [email-masked]<br>Sent: Monday, September 8, 2008 6:23:52 AM<br>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)<br><br>
Hi Igor,<br><br>Not sure that the scope of this discussion is particularly appropriate to <br>CCAMP and Softwires mailing lists. Might be more relevant on the L1VPN and <br>OSPF lists. You could open a thread there if you want to debate this <br>further.<br><br>IB&gt;&gt;As you remember it was not even me who started this discussion. I simply reacted to the following Yakov's statement addressed to the WGs :<br><br>&gt; &gt;And while on the subject of scaling, please keep in mind that BGP<br>&gt; &gt;only stores L1VPN routes on PEs that have sites of that VPN connected<br>&gt; &gt;to them, and on an RR if used, but *not* on any of the P routers. In<br>&gt; &gt;contrast, rfc5252 (OSPF for L1VPN autodiscovery) results in storing<br>&gt; &gt;*all VPN TE information for all the VPNs* on *all* the IGP nodes, both P<br>&gt; &gt;and PE. So, clearly BGP-based approach scales better than OSPF-based<br>&gt; &gt;approach.<br><br>In your reference below you seem to
 agree that this statement is not exactly correct. Now let me explain why I think that this discussion could be interesting to the CCAMP WG (and I will certainly annoy much more people now :=). *IF* GMPLS Control Plane (which includes OSPF and does not include BGP) can provide a viable alternative to L1VPN-BGP, then how about L2VPNs? This is important especially in the context of the MPLS-TP work, where GMPLS is the control plane of choice today, and it does not include BGP, but MPLS-TP still needs the L2VPN solution. So, should we extend GMPLS with BGP or this is not necessary?<br>Wouldn't this be a good discussion for CCAMP WG list? How about L2VPN, PWE3, MPLS TP lists?&nbsp; <br><br><br>&gt; Although multi-instance OSPF was enthusiastically discussed and is ongoing <br>&gt; work in OSPF WG, it was never discussed in the L1VPN context.<br><br>Please see RFC 5253 section 7.1<br><br>&nbsp; &nbsp;  Alternatively, a separate instance of<br>&nbsp; &nbsp; 
 the OSPF protocol can be used just between PEs for distributing<br>&nbsp; &nbsp;  membership information.<br><br>This appears to be exactly the point you are making. So perhaps we are all <br>in agreement?<br><br>IB&gt;&gt; One thing what is missing IMO in this RFC (and is actually part of this discussion) is comparison of configuration efforts for BGP and OSPF solutions.<br>A solution may have good scalability properties but require enourmous configuration efforts, and thus become very expensive. Would you agree?<br><br>Thanks,<br>Igor<br><br>Adrian<br><br></div></div></div><br>

      </body></html>
--0-979517846-1220882375=:27131--

Delivery-date: Mon, 08 Sep 2008 10:26:48 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)
Date: Mon, 8 Sep 2008 11:23:52 +0100

Hi Igor,

Not sure that the scope of this discussion is particularly appropriate to 
CCAMP and Softwires mailing lists. Might be more relevant on the L1VPN and 
OSPF lists. You could open a thread there if you want to debate this 
further.

> Although multi-instance OSPF was enthusiastically discussed and is ongoing 
> work in OSPF WG, it was never discussed in the L1VPN context.

Please see RFC 5253 section 7.1

     Alternatively, a separate instance of
     the OSPF protocol can be used just between PEs for distributing
     membership information.

This appears to be exactly the point you are making. So perhaps we are all 
in agreement?

Adrian

Delivery-date: Mon, 08 Sep 2008 00:25:04 +0000
Reply-To: [email-masked]
Sensitivity: Normal
To: "Igor Bryskin" <[email-masked]>, "Lou Berger" <[email-masked]>, "John Drake" <[email-masked]>, "Yakov Reckter" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd  question)
From: "Lou Berger" <[email-masked]>
Date: Mon, 8 Sep 2008 00:23:00 +0000

--part128276-boundary-1044013216-1678259618
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"

--part128276-boundary-1044013216-1678259618
Content-Transfer-Encoding: base64
Content-Type: text/html; charset="Windows-1252"

--part128276-boundary-1044013216-1678259618--

Delivery-date: Sun, 07 Sep 2008 18:10:18 +0000
Date: Sun, 7 Sep 2008 11:08:05 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd  question)
To: Lou Berger <[email-masked]>, "Drake, John E" <[email-masked]>, Yakov Rekhter <[email-masked]>
Cc: [email-masked], [email-masked]

--0-475561413-1220810885=:75146
Content-Type: text/plain; charset=us-ascii

>I do like to hear comments from other people.

IMO this discussion (OSPF and BGP applicability and limitations wrt 
L1VPNs) was sufficiently covered in the l1vpn WG, and nothing being 
said now changes the fundamental arguments or conclusions of that discussion.

Lou

PS  PLEASE feel free to drop me from the to/cc line of this thread!

Although multi-instance OSPF was enthusiastically discussed and is ongoing work in OSPF WG, it was never discussed in the L1VPN context. Because it potentially can improve the saclability properties of the L1VPN OSPF solution IMO it defenitely deserves more discussions. I am very interested in the discussion and hope others too. You sound like want to shut it down. It is my understanding that anyone can start a discussion in IETF WG, and the discussion can be closed:
a) by a WG chair;
b) because it is out of WG's charter;
c) it distracts WG from more important things.

I don't see much going on in the L1VPN WG, the discussion is surely within the L1VPN WG charter and, unless I've missed the announcement, you are not a WG chair. Sure, I'll drop you from To: Cc: and Bcc lists of all my outgoing messages, but this won't help. So, if the discussion makes you nervous or annoys you in any way
PLEASE feel free to unsubcribe temporarily from the WG lists (;=)!

--0-475561413-1220810885=:75146
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;">&gt;I do like to hear comments from other people.<br><br>IMO this discussion (OSPF and BGP applicability and limitations wrt <br>L1VPNs) was sufficiently covered in the l1vpn WG, and nothing being <br>said now changes the fundamental arguments or conclusions of that discussion.<br><br>Lou<br><br>PS&nbsp; PLEASE feel free to drop me from the to/cc line of this thread!<br><br><br>Although multi-instance OSPF was enthusiastically discussed and is ongoing work in OSPF WG, it was never discussed in the L1VPN context. Because it potentially can improve the saclability properties of the L1VPN OSPF solution IMO it defenitely deserves more discussions. I
 am very interested in the discussion and hope others too. You sound like want to shut it down. It is my understanding that anyone can start a discussion in IETF WG, and the discussion can be closed:<br>a) by a WG chair;<br>b) because it is out of WG's charter;<br>c) it distracts WG from more important things.<br><br>I don't see much going on in the L1VPN WG, the discussion is surely within the L1VPN WG charter and, unless I've missed the announcement, you are not a WG chair. Sure, I'll drop you from To: Cc: and Bcc lists of all my outgoing messages, but this won't help. So, if the discussion makes you nervous or annoys you in any way<br>PLEASE feel free to unsubcribe temporarily from the WG lists (;=)!<br><br></div></div></div><br>

      </body></html>
--0-475561413-1220810885=:75146--

Delivery-date: Fri, 05 Sep 2008 16:16:43 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Fw: IETF Mailing List Issue
Date: Fri, 5 Sep 2008 17:12:13 +0100

FYI
----- Original Message ----- 
From: "Alexa Morris" <[email-masked]>
To: <[email-masked]>
Cc: "Working Group Chairs" <[email-masked]>; "IETF Discussion" 
<[email-masked]>
Sent: Friday, September 05, 2008 5:02 PM
Subject: IETF Mailing List Issue

> Last night, after a server reboot, the postconfirm spam checker that was
> recently put in front of IETF mailing lists failed to start. 
> Unfortunately,
> this resulted in a huge influx of spam to the IETF ticket system, and a
> simultaneous failure of IETF list email. Everything is back online now and
> functioning; however, email messages sent to IETF lists in the last 16 
> hours
> were lost, and will need to be resent.
>
> We have now installed a direct watcher on postconfirm, to force a restart 
> of
> it when it fails. In addition, Henrik is working on the system now to find
> out why it failed to start in the first place, and why its failure caused
> mail loss rather than mail deferral.
>
> I apologize for any inconvenience this may have caused you. As always,
> please feel free to contact me if you have any questions or concerns.
>
> Regards,
> Alexa
>
> -----------
> Alexa Morris / Executive Director / IETF
> 48377 Fremont Blvd., Suite 117, Fremont, CA  94538
> Phone: +1.510.492.4089 / Fax: +1.510.492.4001
> Email: [email-masked]

Delivery-date: Fri, 05 Sep 2008 15:54:12 +0000
Reply-To: "tom.petch" <[email-masked]>
From: "tom.petch" <[email-masked]>
To: "Yakov Rekhter" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (3rd question)
Date: Fri, 5 Sep 2008 16:41:09 +0200

Is there any convention about what to do if the Indication is neither one nor
zero?  Or does it never happen?  I appreciate that the text is the same in
RFC4203 and so thought that there is likely to be implementation experience of
this.

Tom Petch

Delivery-date: Fri, 05 Sep 2008 12:20:12 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: A Definition of BNF for use in GMPLS
Date: Fri, 5 Sep 2008 12:37:36 +0100

Hi,

During the IESG review of draft-ietf-pce-pcep-14.txt,
several ADs noted that the BNF used in the specification
did not have a normative reference.

The authors of PCEP had based their BNF usage on that
used in RSVP ([RFC2205], [RFC3209], and [RFC3473]) and it
turns out that these documents also don't have references
to any definition of BNF. 

On investigation, it appears that the form of BNF used in
these protocol specifications and in the definition of LMP
([RFC4204]) deviates slightly from any existing definition
of BNF (cf. ABNF [RFC5234]).

In order to rectify this and meet the IESG's requirements
for a reference in the PCEP spec, I have produced 
http://www.ietf.org/internet-drafts/draft-farrel-rtg-common-bnf-00.txt

It would be very helpful if the members of CCAMP could
quickly review this draft for consistency with RSVP-TE and
LMP as used in RFC 3473, RFC 4204, and the various protocol
extension RFCs.

Many thanks,
Adrian

Delivery-date: Fri, 05 Sep 2008 00:49:23 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-isis-interas-te-extension-04.txt 
Date: Thu,  4 Sep 2008 17:45:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
	Author(s)       : M. Chen, R. Zhang
	Filename        : draft-ietf-ccamp-isis-interas-te-extension-04.txt
	Pages           : 20
	Date            : 2008-09-04

This document describes extensions to the ISIS (ISIS) protocol to 
support Multiprotocol Label Switching (MPLS) and Generalized MPLS 
(GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems 
(ASes). It defines ISIS-TE extensions for the flooding of TE 
information about inter-AS links which can be used to perform inter-
AS TE path computation. 

 No support for flooding information from within one AS to another AS 
is proposed or defined in this document. 

Conventions used in this document 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC-2119 [RFC2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas-te-extension-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-isis-interas-te-extension-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Thu, 04 Sep 2008 16:49:46 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-rwa-info-00.txt 
Date: Thu,  4 Sep 2008 09:45:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks 
	Author(s)	: G. Bernstein, Y. Lee, D. Li, W. Imajuku
	Filename	: draft-ietf-ccamp-rwa-info-00.txt
	Pages		: 15
	Date		: 2008-8-29
	
This document provides an information model of information needed by 
   the routing and wavelength assignment (RWA) process in wavelength 
   switched optical networks (WSONs).  The purpose of information 
   described in this model is to facilitate constrained lightpath 
   computation in WSONs. In particular in cases where there are no or a 
   limited number of wavelength converters available in the WSON. This 
   model currently does not include optical impairments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-rwa-info-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--NextPart--

Delivery-date: Wed, 03 Sep 2008 20:02:16 +0000
Reply-To: <[email-masked]>
From: "Tony Li" <[email-masked]>
To: "'Igor Bryskin'" <[email-masked]>, "'Drake, John E'" <[email-masked]>, "'Yakov Rekhter'" <[email-masked]>, "'Lou Berger'" <[email-masked]>
Cc: "'Yakov Rekhter'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)
Date: Wed, 3 Sep 2008 12:57:57 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_00AC_01C90DC4.BB9BA2A0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

I completely agree with you. By creating overlays I propose to do exactly
what you are saying: constrain the topology only to the interested parties.
This puts away the scalability concerns but raises the question how bad it
is in terms of configuration effort, specifically, how difficult it is to
add a new PE (a member of a subset of VPNs). I know that BGP configuration
is not exactly automatic either. So how big is the difference in the
configuration efforts? 
I know for a fact that some L1 network operators are interested in L1 VPN
application but reluctant to deploy BGP. They do deploy for quite some time
already GMPLS based control plane with OSPF-TE. Why in your opinion the
multi-instance OSPF solution will not be acceptible for them? 

Providers are disinclined to have any configuration that scales linearly
with the number of VPNs.  The higher the complexity of the per-VPN
configuration, the higher the work multiplier.
 
Of course, if you really want to advocate building static tunnels for VPNs,
one has to wonder why PE's and P's are involved at all.  Push the VPN
configuration to the CPE and leave the centralized boxes out of the equation
entirely.
 
Tony

------=_NextPart_000_00AC_01C90DC4.BB9BA2A0
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE type=3Dtext/css>DIV {
	MARGIN: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.6000.16705" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV><FONT =
face=3DArial=20
color=3D#0000ff></FONT><BR>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><SPAN=20
  class=3D859562217-03092008>I completely agree with you. By creating =
overlays I=20
  propose to do exactly what you are saying: constrain the topology only =
to the=20
  interested parties. This puts away the scalability concerns but raises =
the=20
  question how bad it is in terms of configuration effort, specifically, =
how=20
  difficult it is to add a new PE (a member of a subset of VPNs). I know =
that=20
  BGP configuration is not exactly automatic either. So how big is the=20
  difference in the configuration efforts? <BR>I know for a fact that =
some L1=20
  network operators are interested in L1 VPN application but reluctant =
to deploy=20
  BGP. They do deploy for quite some time already GMPLS based control =
plane with=20
  OSPF-TE. Why in your opinion the multi-instance OSPF solution will not =
be=20
  acceptible for them?<SPAN class=3D437255519-03092008><FONT =
face=3DArial=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></SPAN></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><SPAN=20
  class=3D859562217-03092008><SPAN=20
  class=3D437255519-03092008></SPAN></SPAN>&nbsp;</DIV></BLOCKQUOTE>
<DIV class=3DOutlookMessageHeader lang=3Den-us align=3Dleft><SPAN=20
class=3D859562217-03092008><SPAN class=3D437255519-03092008><FONT =
face=3DArial=20
color=3D#0000ff>Providers are disinclined to have any configuration that =

scales&nbsp;linearly with the number of VPNs.&nbsp; The higher the =
complexity of=20
the per-VPN configuration, the higher the work=20
multiplier.</FONT></SPAN></SPAN></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us align=3Dleft><SPAN=20
class=3D859562217-03092008><SPAN class=3D437255519-03092008><FONT =
face=3DArial=20
color=3D#0000ff></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us align=3Dleft><SPAN=20
class=3D859562217-03092008><SPAN class=3D437255519-03092008><FONT =
face=3DArial=20
color=3D#0000ff>Of course, if you really want to advocate building =
static tunnels=20
for VPNs, one has to wonder why PE's and P's are involved at all.&nbsp; =
Push the=20
VPN configuration to the CPE and leave the centralized boxes out of the =
equation=20
entirely.</FONT></SPAN></SPAN></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us align=3Dleft><SPAN=20
class=3D859562217-03092008><SPAN class=3D437255519-03092008><FONT =
face=3DArial=20
color=3D#0000ff></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us align=3Dleft><SPAN=20
class=3D859562217-03092008><SPAN class=3D437255519-03092008><FONT =
face=3DArial=20
color=3D#0000ff>Tony</FONT></SPAN></SPAN></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us align=3Dleft><SPAN=20
class=3D859562217-03092008><SPAN=20
class=3D437255519-03092008>&nbsp;</SPAN></SPAN></DIV></BODY></HTML>

------=_NextPart_000_00AC_01C90DC4.BB9BA2A0--

Delivery-date: Wed, 03 Sep 2008 18:50:56 +0000
Date: Wed, 3 Sep 2008 11:46:47 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)
To: [email-masked], "Drake, John E" <[email-masked]>, Yakov Rekhter <[email-masked]>, Lou Berger <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked], [email-masked]

--0-704739775-1220467607=:43004
Content-Type: text/plain; charset=us-ascii

 I do like  to hear comments from other people. 
 
OSPF (and any other 
flooding based protocol) is a particularly poor basis for doing restricted 
dissemination of information.  The only way to constrain the flooding 
is to constrain the topology, which adds an additional layer of 
management overhead that is simply unnecessary.

Hi Tony,
I completely agree with you. By creating overlays I propose to do exactly what you are saying: constrain the topology only to the interested parties. This puts away the scalability concerns but raises the question how bad it is in terms of configuration effort, specifically, how difficult it is to add a new PE (a member of a subset of VPNs). I know that BGP configuration is not exactly automatic either. So how big is the difference in the configuration efforts? 
I know for a fact that some L1 network operators are interested in L1 VPN application but reluctant to deploy BGP. They do deploy for quite some time already GMPLS based control plane with OSPF-TE. Why in your opinion the multi-instance OSPF solution will not be acceptible for them?

Thanks for your input.
Igor

Igor

--0-704739775-1220467607=:43004
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><blockquote style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px; margin-right: 0px;"><div class="OutlookMessageHeader" dir="ltr" align="left" lang="en-us">&nbsp;I do like 
  to hear comments from other people.<span class="859562217-03092008"><font color="#0000ff" face="Arial">&nbsp;</font></span></div>
  <div class="OutlookMessageHeader" dir="ltr" align="left" lang="en-us"><span class="859562217-03092008"></span>&nbsp;</div></blockquote>
<div class="OutlookMessageHeader" align="left" lang="en-us"><span class="859562217-03092008"><font color="#0000ff" face="Arial">OSPF&nbsp;(and any other 
flooding&nbsp;based protocol) is a particularly poor basis for doing restricted 
dissemination of information.&nbsp;&nbsp;The only way to constrain the flooding 
is to constrain the topology,&nbsp;which&nbsp;adds an additional layer of 
management overhead that is simply unnecessary.<br><br></font></span></div><div class="OutlookMessageHeader" align="left" lang="en-us"><span class="859562217-03092008">Hi Tony,<br>I completely agree with you. By creating overlays I propose to do exactly what you are saying: constrain the topology only to the interested parties. This puts away the scalability concerns but raises the question how bad it is in terms of configuration effort, specifically, how difficult it is to add a new PE (a member of a subset of VPNs). I know that BGP configuration is not exactly automatic either. So how big is the difference in the configuration efforts? <br>I know for a fact that some L1 network operators are interested in L1 VPN application but reluctant to deploy BGP. They do deploy for quite some time already GMPLS based control plane with OSPF-TE. Why in your opinion the multi-instance OSPF solution will not be acceptible for them?<br><br>Thanks for your
 input.<br>Igor<br><br><br>Igor<br>&nbsp;<br></span></div></div></div></div><br>

      </body></html>
--0-704739775-1220467607=:43004--

Delivery-date: Wed, 03 Sep 2008 17:43:38 +0000
Date: Wed, 03 Sep 2008 13:39:27 -0400
To: Igor Bryskin <[email-masked]>, "Drake, John E" <[email-masked]>, Yakov Rekhter <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)
Cc: [email-masked],[email-masked]

At 09:47 AM 9/3/2008, Igor Bryskin wrote:
>I do like to hear comments from other people.

IMO this discussion (OSPF and BGP applicability and limitations wrt 
L1VPNs) was sufficiently covered in the l1vpn WG, and nothing being 
said now changes the fundamental arguments or conclusions of that discussion.

Lou

PS  PLEASE feel free to drop me from the to/cc line of this thread!

Delivery-date: Wed, 03 Sep 2008 17:36:52 +0000
Date: Wed, 03 Sep 2008 13:32:17 -0400
To: Yakov Rekhter <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) 
Cc: Lou Berger <[email-masked]>,Adrian Farrel <[email-masked]>, [email-masked],[email-masked],[email-masked]

looks fine to me.  I'll look for it in the updated draft...

Lou

At 11:18 AM 9/3/2008, Yakov Rekhter wrote:
>Lou,
>
> > At 05:30 PM 9/2/2008, Yakov Rekhter wrote:
> >
> > >Here is the text I'll add to the spec to discuss this issue:
> > >
> > >      Use of Traffic Engineering Attribute does not increase the number
> > >      of routes.
> > >
> > >      When the routes differ in other than the Traffic Engineering
> > >      Attribute (e.g., differ in the set of Route Targets, and/or
> > >      NEXT_HOP), use of Traffic Engineering Attribute has no impact
> > >      on the number of BGP Update messages required to carry the routes.
> > >      Only when the routes have all, but the Traffic Engineering
> > >      Attribute the same, use of the attribute may increase the number
> > >      of BGP Update messages required to carry the routes.
> > >
> > >Yakov.
> >
> > Is this from babel fish?  How about:
> >
> > Use of Traffic Engineering Attribute does not increase the number
> > of routes, but may increase the number of BGP Update messages
> > required to distribute the routes.
> >
> > When the routes differ in other than the Traffic Engineering
> > Attribute (e.g., differ in the set of Route Targets, and/or
> > NEXT_HOP), use of Traffic Engineering Attribute has no impact
> > on the number of BGP Update messages required to carry the routes.
> > There is also no impact when routes share all other attribute
> > information and have an aggregated or identical Traffic 
> Engineering Attribute
>.
> > When routes share all other attribute information and have different
> > Traffic Engineering Attributes, routes must be distributed in
> > per-route BGP Update messages rather than a single message.
>
>Almost there... The only change is to the first paragraph,
>as follows:
>
>    Use of Traffic Engineering Attribute does not increase the number
>    of routes, but may increase the number of BGP Update messages
>    required to distribute the routes depending on whether these routes
>    share the same BGP Traffic Engineering attribute or not (see below).
>
>The second paragraph is fine.
>
>Yakov.

Delivery-date: Wed, 03 Sep 2008 17:31:09 +0000
Reply-To: <[email-masked]>
From: "Tony Li" <[email-masked]>
To: "'Igor Bryskin'" <[email-masked]>, "'Drake, John E'" <[email-masked]>, "'Yakov Rekhter'" <[email-masked]>, "'Lou Berger'" <[email-masked]>
Cc: "'Yakov Rekhter'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)
Date: Wed, 3 Sep 2008 10:25:51 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_009D_01C90DAF.7C0AA4C0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

 I do like to hear comments from other people. 

OSPF (and any other flooding based protocol) is a particularly poor basis
for doing restricted dissemination of information.  The only way to
constrain the flooding is to constrain the topology, which adds an
additional layer of management overhead that is simply unnecessary.
 
Tony

------=_NextPart_000_009D_01C90DAF.7C0AA4C0
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE type=3Dtext/css>DIV {
	MARGIN: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.6000.16705" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D859562217-03092008><FONT face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV><FONT face=3DArial=20
color=3D#0000ff></FONT><FONT face=3DArial color=3D#0000ff></FONT><FONT =
face=3DArial=20
color=3D#0000ff></FONT><BR>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>&nbsp;I do like=20
  to hear comments from other people.<SPAN =
class=3D859562217-03092008><FONT=20
  face=3DArial color=3D#0000ff>&nbsp;</FONT></SPAN></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><SPAN=20
  class=3D859562217-03092008></SPAN>&nbsp;</DIV></BLOCKQUOTE>
<DIV class=3DOutlookMessageHeader lang=3Den-us align=3Dleft><SPAN=20
class=3D859562217-03092008><FONT face=3DArial =
color=3D#0000ff>OSPF&nbsp;(and any other=20
flooding&nbsp;based protocol) is a particularly poor basis for doing =
restricted=20
dissemination of information.&nbsp;&nbsp;The only way to constrain the =
flooding=20
is to constrain the topology,&nbsp;which&nbsp;adds an additional layer =
of=20
management overhead that is simply unnecessary.</FONT></SPAN></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us align=3Dleft><SPAN=20
class=3D859562217-03092008><FONT face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us align=3Dleft><SPAN=20
class=3D859562217-03092008><FONT face=3DArial =
color=3D#0000ff>Tony</FONT></SPAN></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us align=3Dleft><SPAN=20
class=3D859562217-03092008></SPAN><SPAN=20
class=3D859562217-03092008>&nbsp;</SPAN></DIV></BODY></HTML>

------=_NextPart_000_009D_01C90DAF.7C0AA4C0--

Delivery-date: Wed, 03 Sep 2008 15:47:06 +0000
Date: Wed, 3 Sep 2008 08:42:24 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)
To: Yakov Rekhter <[email-masked]>
Cc: "Drake, John E" <[email-masked]>, Lou Berger <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked], [email-masked]

--0-1935299916-1220456544=:20196
Content-Type: text/plain; charset=us-ascii

Yakov,

Please, see in line

----- Original Message ----
From: Yakov Rekhter <[email-masked]>
To: Igor Bryskin <[email-masked]>
Cc: "Drake, John E" <[email-masked]>; Lou Berger <[email-masked]>; Adrian Farrel <[email-masked]>; [email-masked]; [email-masked]
Sent: Wednesday, September 3, 2008 11:13:04 AM
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) 

Igor,

> Yakov,
> Please,  see in-line.

see in-line...

> ----- Original Message ----
> From: Yakov Rekhter <[email-masked]>
> To: Igor Bryskin <[email-masked]>
> Cc: "Drake, John E" <[email-masked]>; Lou Berger <[email-masked]>
; Adrian Farrel <[email-masked]>; [email-masked]; [email-masked]
> Sent: Wednesday, September 3, 2008 9:55:49 AM
> Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)

> 
> Igor,
> 
> > And I am not arguing that sufficient redundancy must be provided. However 
> > you said:
> > >For your suggested approach to work with sufficient 
> > >redundancy, the topology of the overlay needs to be configured 
> > >such that every selected P router is connected to at least two 
> > >other selected P routers and every PE router needs to be 
> > >connected to at least two selected P routers.
> > 
> > If you just simply interconnect all VPN-aware PEs into a single
> > ring via IPin IP tunnels and run an instance of OSPF to distribute
> > VPN-related information between them, it will provide sufficient
> > redundancy and involve exactly *zero* Ps.
> >
> > So, I want you to drop your lecturing tone for a minute and simply
> > tell in what respect in your opinion this approach is not perfect
> > fo the L1VPN application. Otherwise, I am not interested in this
> > discussion any longer. I do like to hear comments from other people.
> 
> Since you asked, one problem with using OSPF, as John correctly
> pointed out, is that you are left with a situation in which *every* PE 
> router will have *all* L1VPN routes for all the L1VPNs. Of course, 
> this is "perfect" in a sense that you can do no worse than that :-)
> 
> IB>> Ok. Several points here. Note that neither Ps nor VPN-unaware PEs 
> IB>> participate in the distribution/maintenance of VPN information, 
> IB>> which is already significantly better than what you said about 
> IB>> the OSPF solution in your previous mail:
> 
> >... And while on the subject of scaling, please keep in mind that BGP
> >   only stores L1VPN routes on PEs that have sites of that VPN
> >   connected to them, and on an RR if used, but *not* on any of the P 
> >   routers. In contrast, rfc5252 (OSPF for L1VPN
> >   autodiscovery) results in storing *all VPN TE information 
> >   for all the VPNs* on *all* the IGP nodes, both P and PE. So, clearly 
> >
> >   BGP-based approach scales better than OSPF-based approach.
> > >>>>Yakov.
> 
> I do agree that if you use a single ring overlay interconnecting
> all VPN aware PEs you will have LSDBs at all PEs contain VPN info
> about all VPNs. However, in case of L1VPN this is not VPN routes,
> rather VPN Provider-To-Customer port mappings which I believe will
> prove to be significantly smaller, so I am not sure yet how bad
> is that. In any case, if it does present a problem on a network
> with large number of VPNs, who said that it has to be a single
> overlay? Why not to configure several overlays - each containing a
> single ring that interconnects PEs participating in a common sub-set
> of VPNs, and run a seperate instance o f OSPF in each overlay?

Sure. And this would be a good illustration of the fact that the
whole idea of using OSPF for L1VPN auto-discovery falls into the
paradigm of inherently flawed designs whose weakness can be solved
only by the usage of elaborate features, that, in turn, introduce 
a new set of problems.

Yakov.

Sorry, Yakov, those are just words. All I am trying to achieve is to use a link state protocol for reliable distribution of information between interested parties and exclusively via interested parties with all other network participants remaining oblivious to the process. With multiple instances of OSPF running in separate overlays of VPN-aware PEs, I believe, this goal could be achieved close to perfection. All we can argue about is which approach - BGP or OSPF - requires a lesser configuration effort to achieve the same goals, but you can not claim better scalability properties for the BGP solution.

Igor

> > 
> > 
> > 
> > 
> > ----- Original Message ----
> > From: "Drake, John E" <[email-masked]>
> > To: Igor Bryskin <[email-masked]>; Yakov Rekhter <[email-masked]>; 
Lo
> u Berger <[email-masked]>
> > Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel <[email-masked]>;
c
> [email-masked]; [email-masked]
> > Sent: Wednesday, September 3, 2008 8:10:07 AM
> > Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd questio
n)
> > 
> > Igor,
> > 
> > Actually, I am not sure that you do understand what I wrote, because you
> > are providing examples of the redundancy that I specified - every PE
> > router needs to have connectivity to two other routers in the IGP
> > instance.
> > 
> > Thanks,
> > 
> > John 
> > 
> > >-----Original Message-----
> > >From: Igor Bryskin [mailto:[email-masked]] 
> > >Sent: Tuesday, September 02, 2008 3:06 PM
> > >To: Drake, John E; Yakov Rekhter; Lou Berger
> > >Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
> > >[email-masked]
> > >Subject: Re: [Softwires] BGP TE attr last call by softwires WG 
> > >(2nd question)
> > >
> > >Hi John,
> > >
> > >I understand what you are saying and disagree. The overlay I 
> > >am talking about logically is a separate network and as any 
> > >network it should be sufficiently redundant to function. There 
> > >is a number of ways how you can address the redundancy 
> > >concerns. Look at the examples below:
> > >
> > >a) interconnect all VPN-aware PEs into a single ring: 
> > >PE=======PE
> > > ||                  ||
> > >PE               PE 
> > >||                   ||
> > >PE               PE 
> > >||                   ||
> > >...                ....
> > >PE=======PE
> > >
> > >b) connect each PE to two interconnected Ps 
> > >
> > >PE               P                 PE
> > >                    ||                  
> > >PE               ||                  PE 
> > >                    ||                  
> > >PE               ||                  PE 
> > >                    ||                  
> > >...                 ||                   ....
> > >PE               P                 PE
> > >
> > >
> > >Note that tunnels can traverse any number of VPN-unaware Ps and PEs.
> > >
> > >Igor
> > >
> > >
> > >----- Original Message ----
> > >From: "Drake, John E" <[email-masked]>
> > >To: Igor Bryskin <[email-masked]>; Yakov Rekhter 
> > ><[email-masked]>; Lou Berger <[email-masked]>
> > >Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel 
> > ><[email-masked]>; [email-masked]; [email-masked]
> > >Sent: Tuesday, September 2, 2008 2:24:26 PM
> > >Subject: RE: [Softwires] BGP TE attr last call by softwires WG 
> > >(2nd question)
> > >
> > >Igor,
> > >
> > >Several years ago when OSPF was first proposed as an 
> > >autodiscovery mechanism for L1VPNs, you were told that it was 
> > >a bad idea due to its scaling properties and impact on the IGP.
> > >
> > >You are now tacitly agreeing with those who told you it was a bad idea.
> > >
> > >For your suggested approach to work with sufficient 
> > >redundancy, the topology of the overlay needs to be configured 
> > >such that every selected P router is connected to at least two 
> > >other selected P routers and every PE router needs to be 
> > >connected to at least two selected P routers.
> > >
> > >When you are done with this configuration, you are left with a 
> > >situation in which *every* PE and selected P router will have 
> > >*all* L1VPN routes.
> > >
> > >Thanks,
> > >
> > >John 
> > >
> > >>-----Original Message-----
> > >>From: Igor Bryskin [mailto:[email-masked]]
> > >>Sent: Friday, August 29, 2008 12:10 PM
> > >>To: Drake, John E; Yakov Rekhter; Lou Berger
> > >>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
> > >>[email-masked]
> > >>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd 
> > >>question)
> > >>
> > >>Are you calling me silly? Are you coming to Minneapolis? :=)
> > >>
> > >>Seriously, what is wrong in your opinion with this approach? 
> > >>Many people are talking about multi-instance IGPs. What they have in 
> > >>mind is improving the IGP scalability:
> > >>a) by removing non-IP advertisements from the instance of IGP that 
> > >>manages IP routing/forwarding tables into separate IGP instance(s);
> > >>b) by distributing non-IP information only to and via 
> > >inerested parties 
> > >>leaving the bulk of Ps out of the process.
> > >>
> > >>In my opinion this is exactly what is needed for the OSPF-based L1VPN 
> > >>application.
> > >>
> > >>Igor
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>----- Original Message ----
> > >>From: "Drake, John E" <[email-masked]>
> > >>To: Igor Bryskin <[email-masked]>; Yakov Rekhter 
> > >><[email-masked]>; Lou Berger <[email-masked]>
> > >>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel 
> > >><[email-masked]>; [email-masked]; [email-masked]
> > >>Sent: Friday, August 29, 2008 2:31:36 PM
> > >>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd 
> > >>question)
> > >>
> > >>So you are proposing an OSPF route reflector?  At what point does the 
> > >>silliness stop?
> > >>
> > >>>-----Original Message-----
> > >>>From: Igor Bryskin [mailto:[email-masked]]
> > >>>Sent: Friday, August 29, 2008 11:29 AM
> > >>>To: Drake, John E; Yakov Rekhter; Lou Berger
> > >>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
> > >>>[email-masked]
> > >>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
> > >>>question)
> > >>>
> > >>>Hi John,
> > >>>
> > >>>No, not really. When you add a PE you configure local
> > >>interfaces, local
> > >>>VPN port mappings, stuff like that. While doing this you will also 
> > >>>configure an IPinIP tunnel to one of your spoke Ps and enable L1VPN 
> > >>>OSPF instance on the tunnel.
> > >>>Once you did that the local VPN information will be flooded
> > >>accross the
> > >>>overlay, likewise, the new PE will get all the necessary information 
> > >>>from other PEs.
> > >>>
> > >>>Cheers,
> > >>>Igor
> > >>>
> > >>>
> > >>>----- Original Message ----
> > >>>From: "Drake, John E" <[email-masked]>
> > >>>To: Igor Bryskin <[email-masked]>; Yakov Rekhter 
> > >>><[email-masked]>; Lou Berger <[email-masked]>
> > >>>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel 
> > >>><[email-masked]>; [email-masked]; [email-masked]
> > >>>Sent: Friday, August 29, 2008 11:20:16 AM
> > >>>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd
> > >>>question)
> > >>>
> > >>>Igor,
> > >>>
> > >>>Doesn't this defeat auto-discovery?  I.e., how is a new PE 
> > >added to a 
> > >>>given L1VPN?
> > >>>
> > >>>Thanks,
> > >>>
> > >>>John
> > >>>
> > >>>>-----Original Message-----
> > >>>>From: Igor Bryskin [mailto:[email-masked]]
> > >>>>Sent: Friday, August 29, 2008 5:51 AM
> > >>>>To: Yakov Rekhter; Lou Berger
> > >>>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
> > >>>>[email-masked]
> > >>>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
> > >>>>question)
> > >>>>
> > >>>>Yakov,
> > >>>>
> > >>>>You said:
> > >>>>
> > >>>>
> > >>>>... And while on the subject of scaling, please keep in mind
> > >>that BGP
> > >>>>only stores L1VPN routes on PEs that have sites of that VPN
> > >>connected
> > >>>>to them, and on an RR if used, but *not* on any of the P 
> > >routers. In 
> > >>>>contrast, rfc5252 (OSPF for L1VPN
> > >>>>autodiscovery) results in storing *all VPN TE information 
> > >for all the
> > >>>>VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based 
> > >>>>approach scales better than OSPF-based approach.
> > >>>>
> > >>>>Yakov.
> > >>>>
> > >>>>This is not true in case of multi-instance OSPF: one can build an 
> > >>>>overlay interconnecting PEs via one or small number of Ps
> > >>>using IPinIP
> > >>>>tunnels and run in this overlay an instance of OSPF specifically 
> > >>>>designated for distribution of L1VPN information. In this
> > >>>case the OSPF
> > >>>>solution won't scale any worse than the BGP approach. Note. 
> > >>>that rfc252
> > >>>>never said that the instance of OSPF used for flooding of the L1VPN 
> > >>>>information must be the same instance that is used for the
> > >>>distribution
> > >>>>of IP-related LSAs.
> > >>>>
> > >>>>Regards,
> > >>>>Igor
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> > 
> > 
> >      
> > --0-1141253910-1220449648=:97601
> > Content-Type: text/html; charset=us-ascii
> > 
> > <html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head
><
> body><div style="font-family:times new roman, new york, times, serif;font-siz
e:
> 12pt"><div>And I am not arguing that sufficient redundancy must be provided. 
Ho
> wever you said:<br>&gt;For your suggested approach to work with sufficient <b
r>
> &gt;redundancy, the topology of the overlay needs to be configured <br>&gt;su
ch
> that every selected P router is connected to at least two <br>&gt;other selec
t
> ed P routers and every PE router needs to be <br>&gt;connected to at least tw
o 
> selected P routers.<br><br>If you just simply interconnect all VPN-aware PEs 
in
> to a single ring via IPinIP tunnels and run an instance of OSPF to distribute
V
> PN-related information between them, it will provide sufficient redundancy an
d 
> involve exactly *zero* Ps.<br>So, I want you to drop your lecturing tone for 
a 
> minute and simply tell in what respect in your opinion this approach is not p
er
> fect fo the L1VPN
> >  application. Otherwise, I am not interested in this discussion any longer.
I
> do like to hear comments from other people.<br><br>Igor <br><br></div><div st
y
> le="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br>
<d
> iv style="font-family: arial,helvetica,sans-serif; font-size: 13px;">----- Or
ig
> inal Message ----<br>From: "Drake, John E" &lt;[email-masked]&gt;<b
r>
> To: Igor Bryskin &lt;[email-masked]&gt;; Yakov Rekhter &lt;yakov@juniper
.n
> et&gt;; Lou Berger &lt;[email-masked]&gt;<br>Cc: Yakov Rekhter &lt;yakov@ju
ni
> per.net&gt;; Adrian Farrel &lt;[email-masked]&gt;; [email-masked]; s
of
> [email-masked]<br>Sent: Wednesday, September 3, 2008 8:10:07 AM<br>Subject: 
RE
> : [Softwires] BGP TE attr last call by softwires WG (2nd question)<br><br>
> > Igor,<br><br>Actually, I am not sure that you do understand what I wrote, b
ec
> ause you<br>are providing examples of the redundancy that I specified - every
P
> E<br>router needs to have connectivity to two other routers in the IGP<br>ins
ta
> nce.<br><br>Thanks,<br><br>John <br><br>&gt;-----Original Message-----<br>&gt
;F
> rom: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href="mailt
o:
> [email-masked]">[email-masked]</a>] <br>&gt;Sent: Tuesday, Septembe
r 
> 02, 2008 3:06 PM<br>&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt;C
c:
> Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="ma
i
> lto:[email-masked]">[email-masked]</a>; <br>&gt;<a ymailto="mailto:so
ft
> [email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&g
t;
> Subject: Re: [Softwires] BGP TE attr last call by softwires WG <br>&gt;(2nd q
ue
> stion)<br>&gt;<br>&gt;Hi John,<br>&gt;<br>&gt;I understand what you are sayin
g 
> and disagree. The
> >  overlay I <br>&gt;am talking about logically is a separate network and as 
an
> y <br>&gt;network it should be sufficiently redundant to function. There <br>
&g
> t;is a number of ways how you can address the redundancy <br>&gt;concerns. Lo
ok
> at the examples below:<br>&gt;<br>&gt;a) interconnect all VPN-aware PEs into 
a
> single ring: <br>&gt;PE=======PE<br>&gt; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;

> &nbsp; &nbsp; &nbsp; &nbsp; ||<br>&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n
bs
> p; &nbsp;  PE <br>&gt;||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs
p;
> &nbsp;  ||<br>&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  PE <br>
&
> gt;||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||<br>&g
t;
> ...&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ....<br>&gt;PE====
==
> =PE<br>&gt;<br>&gt;b) connect each PE to two interconnected Ps <br>&gt;<br>&g
t;
> PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  P&nbsp; &nbsp; &nbsp; &nb
sp
> ; &nbsp; &nbsp; &nbsp;
> >  &nbsp;  PE<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
&n
> bsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
<
> br>&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||&nbsp; &nbsp; &n
bs
> p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PE <br>&gt;&nbsp; &nbsp; &nbsp; 
&n
> bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; 
&n
> bsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&
> nbsp; &nbsp;  ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp
; 
> PE <br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb
sp
> ; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>&gt;..
.&
> nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||&nbsp; &nbsp; &nbsp
; 
> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ....<br>&gt;PE&nbsp; &nbsp; &nbsp;
&
> nbsp; &nbsp; &nbsp; &nbsp;  P&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&
> nbsp; 
> >  PE<br>&gt;<br>&gt;<br>&gt;Note that tunnels can traverse any number of VPN
-u
> naware Ps and PEs.<br>&gt;<br>&gt;Igor<br>&gt;<br>&gt;<br>&gt;----- Original 
Me
> ssage ----<br>&gt;From: "Drake, John E" &lt;<a ymailto="mailto:John.E.Drake2@
bo
> eing.com" href="mailto:[email-masked]">[email-masked]</a>
&g
> t;<br>&gt;To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" href="
ma
> ilto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt;
&l
> t;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">yakov
@j
> uniper.net</a>&gt;; Lou Berger &lt;<a ymailto="mailto:[email-masked]" href=
"m
> ailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;Cc: Yakov Rekhter &lt
;<
> a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">yakov@ju
ni
> per.net</a>&gt;; Adrian Farrel <br>&gt;&lt;<a ymailto="mailto:[email-masked]
o.
> uk" href="mailto:[email-masked]">[email-masked]</a>&gt;; <a
> >  ymailto="mailto:[email-masked]" href="mailto:[email-masked]">ccamp
@o
> ps.ietf.org</a>; <a ymailto="mailto:[email-masked]" href="mailto:softwire
s@
> ietf.org">[email-masked]</a><br>&gt;Sent: Tuesday, September 2, 2008 2:24
:2
> 6 PM<br>&gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG <b
r>
> &gt;(2nd question)<br>&gt;<br>&gt;Igor,<br>&gt;<br>&gt;Several years ago when
O
> SPF was first proposed as an <br>&gt;autodiscovery mechanism for L1VPNs, you 
we
> re told that it was <br>&gt;a bad idea due to its scaling properties and impa
ct
> on the IGP.<br>&gt;<br>&gt;You are now tacitly agreeing with those who told y
o
> u it was a bad idea.<br>&gt;<br>&gt;For your suggested approach to work with 
su
> fficient <br>&gt;redundancy, the topology of the overlay needs to be configur
ed
> <br>&gt;such that every selected P router is connected to at least two <br>&g
t
> ;other selected P routers and every PE router needs to be <br>&gt;connected t
o 
> at least two selected
> >  P routers.<br>&gt;<br>&gt;When you are done with this configuration, you a
re
> left with a <br>&gt;situation in which *every* PE and selected P router will 
h
> ave <br>&gt;*all* L1VPN routes.<br>&gt;<br>&gt;Thanks,<br>&gt;<br>&gt;John <b
r>
> &gt;<br>&gt;&gt;-----Original Message-----<br>&gt;&gt;From: Igor Bryskin [mai
lt
> o:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">i
_b
> [email-masked]</a>]<br>&gt;&gt;Sent: Friday, August 29, 2008 12:10 PM<br>&g
t;
> &gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt;&gt;Cc: Yakov Rekhter
; 
> Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:ccamp@ops.
ie
> tf.org">[email-masked]</a>; <br>&gt;&gt;<a ymailto="mailto:softwires@ietf
.o
> rg" href="mailto:[email-masked]">[email-masked]</a><br>&gt;&gt;Subjec
t:
> Re: [Softwires] BGP TE attr last call by softwires WG (2nd <br>&gt;&gt;questi
o
> n)<br>&gt;&gt;<br>&gt;&gt;Are you calling me silly? Are you coming to Minneap
ol
> is?
> >  :=)<br>&gt;&gt;<br>&gt;&gt;Seriously, what is wrong in your opinion with t
hi
> s approach? <br>&gt;&gt;Many people are talking about multi-instance IGPs. Wh
at
> they have in <br>&gt;&gt;mind is improving the IGP scalability:<br>&gt;&gt;a)

> by removing non-IP advertisements from the instance of IGP that <br>&gt;&gt;m
an
> ages IP routing/forwarding tables into separate IGP instance(s);<br>&gt;&gt;b
) 
> by distributing non-IP information only to and via <br>&gt;inerested parties 
<b
> r>&gt;&gt;leaving the bulk of Ps out of the process.<br>&gt;&gt;<br>&gt;&gt;I
n 
> my opinion this is exactly what is needed for the OSPF-based L1VPN <br>&gt;&g
t;
> application.<br>&gt;&gt;<br>&gt;&gt;Igor<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<
br
> >&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;----- Original Message ----<br>&
gt
> ;&gt;From: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" h
re
> f="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;&
gt
> ;To: Igor Bryskin
> >  &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]
om
> ">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt;&gt;&lt;<a ymailto="mail
to
> :[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;
; 
> Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="mailto:lberger@labn
.n
> et">[email-masked]</a>&gt;<br>&gt;&gt;Cc: Yakov Rekhter &lt;<a ymailto="mai
lt
> o:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt
;;
> Adrian Farrel <br>&gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="m
a
> ilto:[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:cca
mp
> @ops.ietf.org" href="mailto:[email-masked]">[email-masked]</a>; <a ym
ai
> lto="mailto:[email-masked]" href="mailto:[email-masked]">softwires@ie
tf
> .org</a><br>&gt;&gt;Sent: Friday, August 29, 2008 2:31:36 PM<br>&gt;&gt;Subje
ct
> : RE: [Softwires] BGP TE attr last call by softwires WG (2nd
> >  <br>&gt;&gt;question)<br>&gt;&gt;<br>&gt;&gt;So you are proposing an OSPF 
ro
> ute reflector?&nbsp; At what point does the <br>&gt;&gt;silliness stop?<br>&g
t;
> &gt;<br>&gt;&gt;&gt;-----Original Message-----<br>&gt;&gt;&gt;From: Igor Brys
ki
> n [mailto:<a ymailto="mailto:[email-masked]" href="mailto:i_bryskin@yaho
o.
> com">[email-masked]</a>]<br>&gt;&gt;&gt;Sent: Friday, August 29, 2008 11
:2
> 9 AM<br>&gt;&gt;&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt;&gt;&
gt
> ;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" hre
f=
> "mailto:[email-masked]">[email-masked]</a>; <br>&gt;&gt;&gt;<a ymailt
o=
> "mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]
rg
> </a><br>&gt;&gt;&gt;Subject: Re: [Softwires] BGP TE attr last call by softwir
es
> WG (2nd<br>&gt;&gt;&gt;question)<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Hi John,<br>&
g
> t;&gt;&gt;<br>&gt;&gt;&gt;No, not really. When you add a PE you configure
> >  local<br>&gt;&gt;interfaces, local<br>&gt;&gt;&gt;VPN port mappings, stuff
l
> ike that. While doing this you will also <br>&gt;&gt;&gt;configure an IPinIP 
tu
> nnel to one of your spoke Ps and enable L1VPN <br>&gt;&gt;&gt;OSPF instance o
n 
> the tunnel.<br>&gt;&gt;&gt;Once you did that the local VPN information will b
e 
> flooded<br>&gt;&gt;accross the<br>&gt;&gt;&gt;overlay, likewise, the new PE w
il
> l get all the necessary information <br>&gt;&gt;&gt;from other PEs.<br>&gt;&g
t;
> &gt;<br>&gt;&gt;&gt;Cheers,<br>&gt;&gt;&gt;Igor<br>&gt;&gt;&gt;<br>&gt;&gt;&g
t;
> <br>&gt;&gt;&gt;----- Original Message ----<br>&gt;&gt;&gt;From: "Drake, John
E
> " &lt;<a ymailto="mailto:[email-masked]" href="mailto:John.E.Drake2
@b
> oeing.com">[email-masked]</a>&gt;<br>&gt;&gt;&gt;To: Igor Bryskin &
lt
> ;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">i_
br
> [email-masked]</a>&gt;; Yakov Rekhter <br>&gt;&gt;&gt;&lt;<a ymailto="mailto
:y
> [email-masked]"
> >  href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;
<a
> ymailto="mailto:[email-masked]" href="mailto:[email-masked]">lberger@labn
.
> net</a>&gt;<br>&gt;&gt;&gt;Cc: Yakov Rekhter &lt;<a ymailto="mailto:yakov@jun
ip
> er.net" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian Far
re
> l <br>&gt;&gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:ad
ri
> [email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:[email-masked]
tf
> .org" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="ma
il
> to:[email-masked]" href="mailto:[email-masked]">[email-masked]</a
><
> br>&gt;&gt;&gt;Sent: Friday, August 29, 2008 11:20:16 AM<br>&gt;&gt;&gt;Subje
ct
> : RE: [Softwires] BGP TE attr last call by softwires WG (2nd<br>&gt;&gt;&gt;q
ue
> stion)<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Igor,<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Do
es
> n't this defeat auto-discovery?&nbsp; I.e., how is a new PE <br>&gt;added to 
a 
> <br>&gt;&gt;&gt;given
> >  L1VPN?<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Thanks,<br>&gt;&gt;&gt;<br>&gt;&gt;&
gt
> ;John<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;-----Original Message-----<br>&gt;&g
t;
> &gt;&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" hr
ef
> ="mailto:[email-masked]">[email-masked]</a>]<br>&gt;&gt;&gt;&gt;Sen
t:
> Friday, August 29, 2008 5:51 AM<br>&gt;&gt;&gt;&gt;To: Yakov Rekhter; Lou Ber
g
> er<br>&gt;&gt;&gt;&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:cc
am
> [email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>
&g
> t;&gt;&gt;&gt;<a ymailto="mailto:[email-masked]" href="mailto:softwires@i
et
> f.org">[email-masked]</a><br>&gt;&gt;&gt;&gt;Subject: Re: [Softwires] BGP
T
> E attr last call by softwires WG (2nd<br>&gt;&gt;&gt;&gt;question)<br>&gt;&gt
;&
> gt;&gt;<br>&gt;&gt;&gt;&gt;Yakov,<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;You 
sa
> id:<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;... And while 
on
> the subject of
> >  scaling, please keep in mind<br>&gt;&gt;that BGP<br>&gt;&gt;&gt;&gt;only s
to
> res L1VPN routes on PEs that have sites of that VPN<br>&gt;&gt;connected<br>&
gt
> ;&gt;&gt;&gt;to them, and on an RR if used, but *not* on any of the P <br>&gt
;r
> outers. In <br>&gt;&gt;&gt;&gt;contrast, rfc5252 (OSPF for L1VPN<br>&gt;&gt;&
gt
> ;&gt;autodiscovery) results in storing *all VPN TE information <br>&gt;for al
l 
> the<br>&gt;&gt;&gt;&gt;VPNs* on *all* the IGP nodes, both P and PE. So, clear
ly
> BGP-based <br>&gt;&gt;&gt;&gt;approach scales better than OSPF-based approach
.
> <br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;Yakov.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt
;&
> gt;&gt;This is not true in case of multi-instance OSPF: one can build an <br>
&g
> t;&gt;&gt;&gt;overlay interconnecting PEs via one or small number of Ps<br>&g
t;
> &gt;&gt;using IPinIP<br>&gt;&gt;&gt;&gt;tunnels and run in this overlay an in
st
> ance of OSPF specifically <br>&gt;&gt;&gt;&gt;designated for distribution of 
L1
> VPN information. In
> >  this<br>&gt;&gt;&gt;case the OSPF<br>&gt;&gt;&gt;&gt;solution won't scale 
an
> y worse than the BGP approach. Note. <br>&gt;&gt;&gt;that rfc252<br>&gt;&gt;&
gt
> ;&gt;never said that the instance of OSPF used for flooding of the L1VPN <br>
&g
> t;&gt;&gt;&gt;information must be the same instance that is used for the<br>&
gt
> ;&gt;&gt;distribution<br>&gt;&gt;&gt;&gt;of IP-related LSAs.<br>&gt;&gt;&gt;&
gt
> ;<br>&gt;&gt;&gt;&gt;Regards,<br>&gt;&gt;&gt;&gt;Igor<br>&gt;&gt;&gt;&gt;<br>
&g
> t;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt
;&
> gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<b
r>
> &gt;<br>&gt;<br>&gt;<br>&gt;<br><br></div></div></div><br>
> > 
> >       </body></html>
> > --0-1141253910-1220449648=:97601--
> 
> 
> 
>      
> --0-1852435290-1220452662=:19087
> Content-Type: text/html; charset=us-ascii
> 
> <html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><
body><div style="font-family:times new roman, new york, times, serif;font-size:
12pt"><div>Yaokov,<br><br>Please,&nbsp; see in-line.<br></div><div style="font-
family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style=
"font-family: arial,helvetica,sans-serif; font-size: 13px;">----- Original Mess
age ----<br>From: Yakov Rekhter &lt;[email-masked]&gt;<br>To: Igor Bryskin &
lt;[email-masked]&gt;<br>Cc: "Drake, John E" &lt;[email-masked]&
gt;; Lou Berger &lt;[email-masked]&gt;; Adrian Farrel &lt;[email-masked]
&gt;; [email-masked]; [email-masked]<br>Sent: Wednesday, September 3, 2
008 9:55:49 AM<br>Subject: Re: [Softwires] BGP TE attr last call by softwires W
G (2nd question) <br><br>
> Igor,<br><br>&gt; And I am not arguing that sufficient redundancy must be pro
vided. However you<br>&gt; said:<br>&gt; &gt;For your suggested approach to wor
k with sufficient <br>&gt; &gt;redundancy, the topology of the overlay needs to
be configured <br>&gt; &gt;such that every selected P router is connected to a
t least two <br>&gt; &gt;other selected P routers and every PE router needs to 
be <br>&gt; &gt;connected to at least two selected P routers.<br>&gt; <br>&gt; 
If you just simply interconnect all VPN-aware PEs into a single<br>&gt; ring vi
a IPin IP tunnels and run an instance of OSPF to distribute<br>&gt; VPN-related
information between them, it will provide sufficient<br>&gt; redundancy and in
volve exactly *zero* Ps.<br>&gt;<br>&gt; So, I want you to drop your lecturing 
tone for a minute and simply<br>&gt; tell in what respect in your opinion this 
approach is not perfect<br>&gt; fo the L1VPN application. Otherwise, I am not i
nterested in
>  this<br>&gt; discussion any longer. I do like to hear comments from other pe
ople.<br><br>Since you asked, one problem with using OSPF, as John correctly<br
>pointed out, is that you are left with a situation in which *every* PE <br>rou
ter will have *all* L1VPN routes for all the L1VPNs. Of course, <br>this is "pe
rfect" in a sense that you can do no worse than that :-)<br><br>IB&gt;&gt; Ok. 
Several points here. Note that neither Ps nor VPN-unaware PEs participate in th
e distribution/maintenance of VPN information, which is already significantly b
etter than what you said about the OSPF solution in your previous mail:<br><br>
&gt;... And while on the subject of scaling, please keep in mind that BGP<br>&g
t;&nbsp;&nbsp; only stores L1VPN routes on PEs that have sites of that VPN<br>&
gt;&nbsp;&nbsp; connected to them, and on an RR if used, but *not* on any of th
e P <br>&gt;&nbsp;&nbsp; routers. In contrast, rfc5252 (OSPF for L1VPN<br>&gt;&
nbsp;&nbsp;
>  autodiscovery) results in storing *all VPN TE information <br>&gt;&nbsp;&nbs
p; for all the VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-bas
ed <br>&gt;&nbsp;&nbsp; approach scales better than OSPF-based approach.<br><br
>&gt; &gt;&gt;&gt;&gt;Yakov.<br><br>I do agree that if you use a single ring ov
erlay interconnecting all VPN aware PEs you will have LSDBs at all PEs contain 
VPN info about all VPNs. However, in case of L1VPN this is not VPN routes, rath
er VPN Provider-To-Customer port mappings which I believe will prove to be sugn
ifficantly smaller, so I am not sure yet how bad is that. In any case, if it do
es present a problem on a network with large number of VPNs, who said that it h
as to be a single overlay? Why not to configure several overlays - each contain
ing a single ring that interconnects PEs participating in a common sub-set of V
PNs, and run a seperate instance of OSPF in each overlay?<br><br>Igor<br><br><b
r>&nbsp;<br>&gt;
>  <br>&gt; <br>&gt; <br>&gt; <br>&gt; ----- Original Message ----<br>&gt; From
: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" href="mailto
:[email-masked]">[email-masked]</a>&gt;<br>&gt; To: Igor Br
yskin &lt;<a ymailto="mailto:[email-masked]" href="mailto:i_bryskin@yahoo.
com">[email-masked]</a>&gt;; Yakov Rekhter &lt;<a ymailto="mailto:yakov@ju
niper.net" href="mailto:[email-masked]">[email-masked]</a>&gt;; Lo<br>u B
erger &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">l
[email-masked]</a>&gt;<br>&gt; Cc: Yakov Rekhter &lt;<a ymailto="mailto:yakov@
juniper.net" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian 
Farrel &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]
o.uk">[email-masked]</a>&gt;; c<br><a ymailto="mailto:[email-masked]" h
ref="mailto:[email-masked]">[email-masked]</a>; <a ymailto="mailto:softwi
[email-masked]"
>  href="mailto:[email-masked]">[email-masked]</a><br>&gt; Sent: Wednes
day, September 3, 2008 8:10:07 AM<br>&gt; Subject: RE: [Softwires] BGP TE attr 
last call by softwires WG (2nd question)<br>&gt; <br>&gt; Igor,<br>&gt; <br>&gt
; Actually, I am not sure that you do understand what I wrote, because you<br>&
gt; are providing examples of the redundancy that I specified - every PE<br>&gt
; router needs to have connectivity to two other routers in the IGP<br>&gt; ins
tance.<br>&gt; <br>&gt; Thanks,<br>&gt; <br>&gt; John <br>&gt; <br>&gt; &gt;---
--Original Message-----<br>&gt; &gt;From: Igor Bryskin [mailto:<a ymailto="mail
to:[email-masked]" href="mailto:[email-masked]">[email-masked]</
a>] <br>&gt; &gt;Sent: Tuesday, September 02, 2008 3:06 PM<br>&gt; &gt;To: Drak
e, John E; Yakov Rekhter; Lou Berger<br>&gt; &gt;Cc: Yakov Rekhter; Adrian Farr
el; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">cca
[email-masked]</a>;
>  <br>&gt; &gt;<a ymailto="mailto:[email-masked]" href="mailto:softwires@i
etf.org">[email-masked]</a><br>&gt; &gt;Subject: Re: [Softwires] BGP TE att
r last call by softwires WG <br>&gt; &gt;(2nd question)<br>&gt; &gt;<br>&gt; &g
t;Hi John,<br>&gt; &gt;<br>&gt; &gt;I understand what you are saying and disagr
ee. The overlay I <br>&gt; &gt;am talking about logically is a separate network
and as any <br>&gt; &gt;network it should be sufficiently redundant to functio
n. There <br>&gt; &gt;is a number of ways how you can address the redundancy <b
r>&gt; &gt;concerns. Look at the examples below:<br>&gt; &gt;<br>&gt; &gt;a) in
terconnect all VPN-aware PEs into a single ring: <br>&gt; &gt;PE=======PE<br>&g
t; &gt; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||<br>
&gt; &gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  PE <br>&gt; &gt;||
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||<br>&gt; &gt;
PE&nbsp; &nbsp; &nbsp;
>  &nbsp; &nbsp; &nbsp; &nbsp;  PE <br>&gt; &gt;||&nbsp; &nbsp; &nbsp; &nbsp; &
nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||<br>&gt; &gt;...&nbsp; &nbsp; &nbsp; &nbsp
; &nbsp; &nbsp; &nbsp; &nbsp; ....<br>&gt; &gt;PE=======PE<br>&gt; &gt;<br>&gt;
&gt;b) connect each PE to two interconnected Ps <br>&gt; &gt;<br>&gt; &gt;PE&n
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  P&nbsp; &nbsp; &nbsp; &nbsp; &n
bsp; &nbsp; &nbsp; &nbsp;  PE<br>&gt; &gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n
bsp; &nbsp; &nbsp; &nbsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n
bsp; &nbsp; &nbsp; <br>&gt; &gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb
sp;  ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PE <br>&g
t; &gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>&gt; &gt;PE&
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||&nbsp; &nbsp; &nbsp; &nbsp; 
&nbsp; &nbsp; &nbsp;
>  &nbsp; &nbsp; PE <br>&gt; &gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs
p; &nbsp; &nbsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs
p; &nbsp; <br>&gt; &gt;...&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs
p;  ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ....<br>&
gt; &gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  P&nbsp; &nbsp; &nbs
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  PE<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt
;Note that tunnels can traverse any number of VPN-unaware Ps and PEs.<br>&gt; &
gt;<br>&gt; &gt;Igor<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;----- Original Messa
ge ----<br>&gt; &gt;From: "Drake, John E" &lt;<a ymailto="mailto:John.E.Drake2@
boeing.com" href="mailto:[email-masked]">[email-masked]</a>
&gt;<br>&gt; &gt;To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" h
ref="mailto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter <br
>&gt; &gt;&lt;<a
>  ymailto="mailto:[email-masked]" href="mailto:[email-masked]">yakov@jun
iper.net</a>&gt;; Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="mai
lto:[email-masked]">[email-masked]</a>&gt;<br>&gt; &gt;Cc: Yakov Rekhter &l
t;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">yakov@j
uniper.net</a>&gt;; Adrian Farrel <br>&gt; &gt;&lt;<a ymailto="mailto:adrian@ol
ddog.co.uk" href="mailto:[email-masked]">[email-masked]</a>&gt;; <a y
mailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]
etf.org</a>; <a ymailto="mailto:[email-masked]" href="mailto:softwires@ietf
.org">[email-masked]</a><br>&gt; &gt;Sent: Tuesday, September 2, 2008 2:24:
26 PM<br>&gt; &gt;Subject: RE: [Softwires] BGP TE attr last call by softwires W
G <br>&gt; &gt;(2nd question)<br>&gt; &gt;<br>&gt; &gt;Igor,<br>&gt; &gt;<br>&g
t; &gt;Several years ago when OSPF was first proposed as an <br>&gt; &gt;autodi
scovery mechanism for
>  L1VPNs, you were told that it was <br>&gt; &gt;a bad idea due to its scaling
properties and impact on the IGP.<br>&gt; &gt;<br>&gt; &gt;You are now tacitly
agreeing with those who told you it was a bad idea.<br>&gt; &gt;<br>&gt; &gt;F
or your suggested approach to work with sufficient <br>&gt; &gt;redundancy, the
topology of the overlay needs to be configured <br>&gt; &gt;such that every se
lected P router is connected to at least two <br>&gt; &gt;other selected P rout
ers and every PE router needs to be <br>&gt; &gt;connected to at least two sele
cted P routers.<br>&gt; &gt;<br>&gt; &gt;When you are done with this configurat
ion, you are left with a <br>&gt; &gt;situation in which *every* PE and selecte
d P router will have <br>&gt; &gt;*all* L1VPN routes.<br>&gt; &gt;<br>&gt; &gt;
Thanks,<br>&gt; &gt;<br>&gt; &gt;John <br>&gt; &gt;<br>&gt; &gt;&gt;-----Origin
al Message-----<br>&gt; &gt;&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:i
[email-masked]"
>  href="mailto:[email-masked]">[email-masked]</a>]<br>&gt; &gt;&gt;S
ent: Friday, August 29, 2008 12:10 PM<br>&gt; &gt;&gt;To: Drake, John E; Yakov 
Rekhter; Lou Berger<br>&gt; &gt;&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailt
o="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]
rg</a>; <br>&gt; &gt;&gt;<a ymailto="mailto:[email-masked]" href="mailto:so
[email-masked]">[email-masked]</a><br>&gt; &gt;&gt;Subject: Re: [Softwire
s] BGP TE attr last call by softwires WG (2nd <br>&gt; &gt;&gt;question)<br>&gt
; &gt;&gt;<br>&gt; &gt;&gt;Are you calling me silly? Are you coming to Minneapo
lis? :=)<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;Seriously, what is wrong in your opin
ion with this approach? <br>&gt; &gt;&gt;Many people are talking about multi-in
stance IGPs. What they have in <br>&gt; &gt;&gt;mind is improving the IGP scala
bility:<br>&gt; &gt;&gt;a) by removing non-IP advertisements from the instance 
of IGP that <br>&gt;
>  &gt;&gt;manages IP routing/forwarding tables into separate IGP instance(s);<
br>&gt; &gt;&gt;b) by distributing non-IP information only to and via <br>&gt; 
&gt;inerested parties <br>&gt; &gt;&gt;leaving the bulk of Ps out of the proces
s.<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;In my opinion this is exactly what is neede
d for the OSPF-based L1VPN <br>&gt; &gt;&gt;application.<br>&gt; &gt;&gt;<br>&g
t; &gt;&gt;Igor<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;
&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;----- Original Message -
---<br>&gt; &gt;&gt;From: "Drake, John E" &lt;<a ymailto="mailto:John.E.Drake2@
boeing.com" href="mailto:[email-masked]">[email-masked]</a>
&gt;<br>&gt; &gt;&gt;To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]
m" href="mailto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter
<br>&gt; &gt;&gt;&lt;<a ymailto="mailto:[email-masked]"
>  href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;<a
ymailto="mailto:[email-masked]" href="mailto:[email-masked]">lberger@labn.
net</a>&gt;<br>&gt; &gt;&gt;Cc: Yakov Rekhter &lt;<a ymailto="mailto:yakov@juni
per.net" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian Farr
el <br>&gt; &gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:ad
[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:[email-masked]
tf.org" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="ma
ilto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a
><br>&gt; &gt;&gt;Sent: Friday, August 29, 2008 2:31:36 PM<br>&gt; &gt;&gt;Subj
ect: RE: [Softwires] BGP TE attr last call by softwires WG (2nd <br>&gt; &gt;&g
t;question)<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;So you are proposing an OSPF route
reflector?&nbsp; At what point does the <br>&gt; &gt;&gt;silliness stop?<br>&g
t; &gt;&gt;<br>&gt;
>  &gt;&gt;&gt;-----Original Message-----<br>&gt; &gt;&gt;&gt;From: Igor Bryski
n [mailto:<a ymailto="mailto:[email-masked]" href="mailto:i_bryskin@yahoo.
com">[email-masked]</a>]<br>&gt; &gt;&gt;&gt;Sent: Friday, August 29, 2008
11:29 AM<br>&gt; &gt;&gt;&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&
gt; &gt;&gt;&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:ccamp@ops.
ietf.org" href="mailto:[email-masked]">[email-masked]</a>; <br>&gt; &gt
;&gt;&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]
">[email-masked]</a><br>&gt; &gt;&gt;&gt;Subject: Re: [Softwires] BGP TE at
tr last call by softwires WG (2nd<br>&gt; &gt;&gt;&gt;question)<br>&gt; &gt;&gt
;&gt;<br>&gt; &gt;&gt;&gt;Hi John,<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;No,
not really. When you add a PE you configure local<br>&gt; &gt;&gt;interfaces, 
local<br>&gt; &gt;&gt;&gt;VPN port mappings, stuff like that. While doing this 
you will also <br>&gt;
>  &gt;&gt;&gt;configure an IPinIP tunnel to one of your spoke Ps and enable L1
VPN <br>&gt; &gt;&gt;&gt;OSPF instance on the tunnel.<br>&gt; &gt;&gt;&gt;Once 
you did that the local VPN information will be flooded<br>&gt; &gt;&gt;accross 
the<br>&gt; &gt;&gt;&gt;overlay, likewise, the new PE will get all the necessar
y information <br>&gt; &gt;&gt;&gt;from other PEs.<br>&gt; &gt;&gt;&gt;<br>&gt;
&gt;&gt;&gt;Cheers,<br>&gt; &gt;&gt;&gt;Igor<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;
&gt;&gt;<br>&gt; &gt;&gt;&gt;----- Original Message ----<br>&gt; &gt;&gt;&gt;Fr
om: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" href="mail
to:[email-masked]">[email-masked]</a>&gt;<br>&gt; &gt;&gt;&
gt;To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" href="mailto:i_
[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt; &gt;&gt;
&gt;&lt;<a ymailto="mailto:[email-masked]"
>  href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;<a
ymailto="mailto:[email-masked]" href="mailto:[email-masked]">lberger@labn.
net</a>&gt;<br>&gt; &gt;&gt;&gt;Cc: Yakov Rekhter &lt;<a ymailto="mailto:yakov@
juniper.net" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian 
Farrel <br>&gt; &gt;&gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="m
ailto:[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:ccam
[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <a yma
ilto="mailto:[email-masked]" href="mailto:[email-masked]">softwires@iet
f.org</a><br>&gt; &gt;&gt;&gt;Sent: Friday, August 29, 2008 11:20:16 AM<br>&gt;
&gt;&gt;&gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2n
d<br>&gt; &gt;&gt;&gt;question)<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;Igor,<
br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;Doesn't this defeat auto-discovery?&nb
sp; I.e., how is a new
>  PE <br>&gt; &gt;added to a <br>&gt; &gt;&gt;&gt;given L1VPN?<br>&gt; &gt;&gt
;&gt;<br>&gt; &gt;&gt;&gt;Thanks,<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;John
<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;-----Original Message-----<br>&gt
; &gt;&gt;&gt;&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:i_bryskin@yahoo
.com" href="mailto:[email-masked]">[email-masked]</a>]<br>&gt; &gt;&g
t;&gt;&gt;Sent: Friday, August 29, 2008 5:51 AM<br>&gt; &gt;&gt;&gt;&gt;To: Yak
ov Rekhter; Lou Berger<br>&gt; &gt;&gt;&gt;&gt;Cc: Yakov Rekhter; Adrian Farrel
; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">ccamp
@ops.ietf.org</a>; <br>&gt; &gt;&gt;&gt;&gt;<a ymailto="mailto:[email-masked]
rg" href="mailto:[email-masked]">[email-masked]</a><br>&gt; &gt;&gt;&gt
;&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd<br>&gt
; &gt;&gt;&gt;&gt;question)<br>&gt; &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;Ya
kov,<br>&gt;
>  &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;You said:<br>&gt; &gt;&gt;&gt;&gt;<
br>&gt; &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;... And while on the subject o
f scaling, please keep in mind<br>&gt; &gt;&gt;that BGP<br>&gt; &gt;&gt;&gt;&gt
;only stores L1VPN routes on PEs that have sites of that VPN<br>&gt; &gt;&gt;co
nnected<br>&gt; &gt;&gt;&gt;&gt;to them, and on an RR if used, but *not* on any
of the P <br>&gt; &gt;routers. In <br>&gt; &gt;&gt;&gt;&gt;contrast, rfc5252 (
OSPF for L1VPN<br>&gt; &gt;&gt;&gt;&gt;autodiscovery) results in storing *all V
PN TE information <br>&gt; &gt;for all the<br>&gt; &gt;&gt;&gt;&gt;VPNs* on *al
l* the IGP nodes, both P and PE. So, clearly BGP-based <br>&gt; &gt;&gt;&gt;&gt
;approach scales better than OSPF-based approach.<br>&gt; &gt;&gt;&gt;&gt;<br>&
gt; &gt;&gt;&gt;&gt;Yakov.<br>&gt; &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;Thi
s is not true in case of multi-instance OSPF: one can build an <br>&gt; &gt;&gt
;&gt;&gt;overlay
>  interconnecting PEs via one or small number of Ps<br>&gt; &gt;&gt;&gt;using 
IPinIP<br>&gt; &gt;&gt;&gt;&gt;tunnels and run in this overlay an instance of O
SPF specifically <br>&gt; &gt;&gt;&gt;&gt;designated for distribution of L1VPN 
information. In this<br>&gt; &gt;&gt;&gt;case the OSPF<br>&gt; &gt;&gt;&gt;&gt;
solution won't scale any worse than the BGP approach. Note. <br>&gt; &gt;&gt;&g
t;that rfc252<br>&gt; &gt;&gt;&gt;&gt;never said that the instance of OSPF used
for flooding of the L1VPN <br>&gt; &gt;&gt;&gt;&gt;information must be the sam
e instance that is used for the<br>&gt; &gt;&gt;&gt;distribution<br>&gt; &gt;&g
t;&gt;&gt;of IP-related LSAs.<br>&gt; &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;
Regards,<br>&gt; &gt;&gt;&gt;&gt;Igor<br>&gt; &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;
&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;
<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt
;<br>&gt;
>  &gt;&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt
;<br>&gt; <br>&gt; <br>&gt;&nbsp; &nbsp; &nbsp;  <br>&gt; --0-1141253910-122044
9648=:97601<br>&gt; Content-Type: text/html; charset=us-ascii<br>&gt; <br>&gt; 
&lt;html&gt;&lt;head&gt;&lt;style type="text/css"&gt;&lt;!-- DIV {margin:0px;} 
--&gt;&lt;/style&gt;&lt;/head&gt;&lt;<br>body&gt;&lt;div style="font-family:tim
es new roman, new york, times, serif;font-size:<br>12pt"&gt;&lt;div&gt;And I am
not arguing that sufficient redundancy must be provided. Ho<br>wever you said:
&lt;br&gt;&amp;gt;For your suggested approach to work with sufficient &lt;br&gt
;<br>&amp;gt;redundancy, the topology of the overlay needs to be configured &lt
;br&gt;&amp;gt;such<br> that every selected P router is connected to at least t
wo &lt;br&gt;&amp;gt;other select<br>ed P routers and every PE router needs to 
be &lt;br&gt;&amp;gt;connected to at least two <br>selected P routers.&lt;br&gt
;&lt;br&gt;If you just
>  simply interconnect all VPN-aware PEs in<br>to a single ring via IPinIP tunn
els and run an instance of OSPF to distribute V<br>PN-related information betwe
en them, it will provide sufficient redundancy and <br>involve exactly *zero* P
s.&lt;br&gt;So, I want you to drop your lecturing tone for a <br>minute and sim
ply tell in what respect in your opinion this approach is not per<br>fect fo th
e L1VPN<br>&gt;&nbsp; application. Otherwise, I am not interested in this discu
ssion any longer. I<br> do like to hear comments from other people.&lt;br&gt;&l
t;br&gt;Igor &lt;br&gt;&lt;br&gt;&lt;/div&gt;&lt;div sty<br>le="font-family: ti
mes new roman,new york,times,serif; font-size: 12pt;"&gt;&lt;br&gt;&lt;d<br>iv 
style="font-family: arial,helvetica,sans-serif; font-size: 13px;"&gt;----- Orig
<br>inal Message ----&lt;br&gt;From: "Drake, John E" &amp;lt;<a ymailto="mailto
:[email-masked]"
>  href="mailto:[email-masked]">[email-masked]</a>&amp;gt;&
lt;br&gt;<br>To: Igor Bryskin &amp;lt;<a ymailto="mailto:[email-masked]" h
ref="mailto:[email-masked]">[email-masked]</a>&amp;gt;; Yakov Rekhter
&amp;lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">yako
[email-masked]</a><br>et&amp;gt;; Lou Berger &amp;lt;<a ymailto="mailto:lberger@la
bn.net" href="mailto:[email-masked]">[email-masked]</a>&amp;gt;&lt;br&gt;Cc
: Yakov Rekhter &amp;lt;yakov@juni<br>per.net&amp;gt;; Adrian Farrel &amp;lt;<a
ymailto="mailto:[email-masked]" href="mailto:[email-masked]">adrian@
olddog.co.uk</a>&amp;gt;; <a ymailto="mailto:[email-masked]" href="mailto:c
[email-masked]">[email-masked]</a>; sof<br><a ymailto="mailto:twires@iet
f.org" href="mailto:[email-masked]">[email-masked]</a>&lt;br&gt;Sent: Wednesd
ay, September 3, 2008 8:10:07 AM&lt;br&gt;Subject: RE<br>: [Softwires] BGP TE a
ttr last call by
>  softwires WG (2nd question)&lt;br&gt;&lt;br&gt;<br>&gt; Igor,&lt;br&gt;&lt;b
r&gt;Actually, I am not sure that you do understand what I wrote, bec<br>ause y
ou&lt;br&gt;are providing examples of the redundancy that I specified - every P
<br>E&lt;br&gt;router needs to have connectivity to two other routers in the IG
P&lt;br&gt;insta<br>nce.&lt;br&gt;&lt;br&gt;Thanks,&lt;br&gt;&lt;br&gt;John &lt
;br&gt;&lt;br&gt;&amp;gt;-----Original Message-----&lt;br&gt;&amp;gt;F<br>rom: 
Igor Bryskin [mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]
om" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<br
><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">i_br
[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:i_
[email-masked]">[email-masked]</a>&lt;/a&gt;] &lt;br&gt;&amp;gt;Sent: T
uesday, September <br>02, 2008 3:06 PM&lt;br&gt;&amp;gt;To: Drake, John E; Yako
v Rekhter; Lou
>  Berger&lt;br&gt;&amp;gt;Cc:<br> Yakov Rekhter; Adrian Farrel; &lt;a ymailto=
"mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]"
>[email-masked]</a>" href="mai<br>lto:<a ymailto="mailto:[email-masked]
" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailt
o:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&l
t;/a&gt;; &lt;br&gt;&amp;gt;&lt;a ymailto="mailto:soft<br><a ymailto="mailto:wi
[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a 
ymailto="mailto:[email-masked]" href="mailto:[email-masked]">softwires@
ietf.org</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:softwires@
ietf.org">[email-masked]</a>&lt;/a&gt;&lt;br&gt;&amp;gt;<br>Subject: Re: [S
oftwires] BGP TE attr last call by softwires WG &lt;br&gt;&amp;gt;(2nd que<br>s
tion)&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;Hi John,&lt;br&gt;&amp;gt;&lt;br&gt;&a
mp;gt;I understand
>  what you are saying <br>and disagree. The<br>&gt;&nbsp; overlay I &lt;br&gt;
&amp;gt;am talking about logically is a separate network and as an<br>y &lt;br&
gt;&amp;gt;network it should be sufficiently redundant to function. There &lt;b
r&gt;&amp;g<br>t;is a number of ways how you can address the redundancy &lt;br&
gt;&amp;gt;concerns. Look<br> at the examples below:&lt;br&gt;&amp;gt;&lt;br&gt
;&amp;gt;a) interconnect all VPN-aware PEs into a<br> single ring: &lt;br&gt;&a
mp;gt;PE=======PE&lt;br&gt;&amp;gt; ||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbs
p; &amp;nbsp; <br>&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; ||&lt;br&gt;&amp;
gt;PE&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbs<br>p; &amp
;nbsp;&nbsp; PE &lt;br&gt;&amp;gt;||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;
&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;<br> &amp;nbsp;&nbsp; ||&lt;br&gt;&
amp;gt;PE&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp
;nbsp;&nbsp; PE
>  &lt;br&gt;&amp;<br>gt;||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbs
p; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; ||&lt;br&gt;&amp;gt;<br>..
.&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &
amp;nbsp; ....&lt;br&gt;&amp;gt;PE======<br>=PE&lt;br&gt;&amp;gt;&lt;br&gt;&amp
;gt;b) connect each PE to two interconnected Ps &lt;br&gt;&amp;gt;&lt;br&gt;&am
p;gt;<br>PE&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &a
mp;nbsp;&nbsp; P&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp<br>; &amp;nbsp; &amp
;nbsp; &amp;nbsp;<br>&gt;&nbsp; &amp;nbsp;&nbsp; PE&lt;br&gt;&amp;gt;&amp;nbsp;
&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &
amp;n<br>bsp; &amp;nbsp; ||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbs
p; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; &lt;<br>br&gt;&amp;gt;PE&a
mp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp
; ||&amp;nbsp;
>  &amp;nbsp; &amp;nbs<br>p; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;n
bsp; &amp;nbsp; PE &lt;br&gt;&amp;gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;n<br
>bsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; ||&amp;
nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;n<br>bsp; &amp;nbsp; &amp;nbsp; &am
p;nbsp; &amp;nbsp; &lt;br&gt;&amp;gt;PE&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nb
sp; &amp;nbsp; &amp;<br>nbsp; &amp;nbsp;&nbsp; ||&amp;nbsp; &amp;nbsp; &amp;nbs
p; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; <br>PE &lt
;br&gt;&amp;gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp
; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp<br>; ||&amp;nbsp; &amp;nbsp; &amp;
nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &lt;br&
gt;&amp;gt;...&amp;<br>nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;n
bsp; &amp;nbsp; &amp;nbsp;&nbsp; ||&amp;nbsp; &amp;nbsp; &amp;nbsp; <br>&amp;nb
sp; &amp;nbsp;
>  &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; ....&lt;br&gt;&amp;gt;PE&a
mp;nbsp; &amp;nbsp; &amp;nbsp; &amp;<br>nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&
nbsp; P&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;n
bsp; &amp;<br>nbsp; <br>&gt;&nbsp; PE&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;&lt;br
&gt;&amp;gt;Note that tunnels can traverse any number of VPN-u<br>naware Ps and
PEs.&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;Igor&lt;br&gt;&amp;gt;&lt;br&gt;&amp;g
t;&lt;br&gt;&amp;gt;----- Original Me<br>ssage ----&lt;br&gt;&amp;gt;From: "Dra
ke, John E" &amp;lt;&lt;a ymailto="mailto:John.E.Drake2@bo<br><a target="_blank
" href="http://eing.com">eing.com</a>" href="mailto:<a ymailto="mailto:John.E.D
[email-masked]" href="mailto:[email-masked]">[email-masked]
om</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:John.E.Dra
[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;g<br>t;&lt;br&gt;&am
p;gt;To: Igor Bryskin
>  &amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="
mailto:[email-masked]">[email-masked]</a>" href="ma<br>ilto:<a ymailt
o="mailto:[email-masked]" href="mailto:[email-masked]">i_bryskin@yaho
o.com</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:i_bryskin@ya
hoo.com">[email-masked]</a>&lt;/a&gt;&amp;gt;; Yakov Rekhter &lt;br&gt;&am
p;gt;&amp;l<br>t;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" hr
ef="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="m
ailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"
&gt;yakov@j<br><a target="_blank" href="http://uniper.net">uniper.net</a>&lt;/a
&gt;&amp;gt;; Lou Berger &amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:lberg
[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="m<br>ai
lto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">lberger
@labn.net</a>"&gt;<a
>  ymailto="mailto:[email-masked]" href="mailto:[email-masked]">lberger@lab
n.net</a>&lt;/a&gt;&amp;gt;&lt;br&gt;&amp;gt;Cc: Yakov Rekhter &amp;lt;&lt;<br>
a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:yakov@juni
per.net">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]
et" href="mailto:[email-masked]">[email-masked]</a>"&gt;yakov@juni<br><a 
target="_blank" href="http://per.net">per.net</a>&lt;/a&gt;&amp;gt;; Adrian Far
rel &lt;br&gt;&amp;gt;&amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:adrian@o
lddog.co" href="mailto:[email-masked]">[email-masked]</a>.<br>uk" href="mai
lto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">a
[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto
:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; &lt;a<br>&gt;&
nbsp; ymailto="mailto:<a ymailto="mailto:[email-masked]"
>  href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a yma
ilto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]
f.org</a>"&gt;ccamp@o<br><a target="_blank" href="http://ps.ietf.org">ps.ietf.o
rg</a>&lt;/a&gt;; &lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" 
href="mailto:[email-masked]">[email-masked]</a>" href="mailto:softwires
@<br><a target="_blank" href="http://ietf.org">ietf.org</a>"&gt;<a ymailto="mai
lto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>
&lt;/a&gt;&lt;br&gt;&amp;gt;Sent: Tuesday, September 2, 2008 2:24:2<br>6 PM&lt;
br&gt;&amp;gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG &l
t;br&gt;<br>&amp;gt;(2nd question)&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;Igor,&lt;
br&gt;&amp;gt;&lt;br&gt;&amp;gt;Several years ago when O<br>SPF was first propo
sed as an &lt;br&gt;&amp;gt;autodiscovery mechanism for L1VPNs, you we<br>re to
ld that it was
>  &lt;br&gt;&amp;gt;a bad idea due to its scaling properties and impact<br> on
the IGP.&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;You are now tacitly agreeing with 
those who told yo<br>u it was a bad idea.&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;Fo
r your suggested approach to work with su<br>fficient &lt;br&gt;&amp;gt;redunda
ncy, the topology of the overlay needs to be configured<br> &lt;br&gt;&amp;gt;s
uch that every selected P router is connected to at least two &lt;br&gt;&amp;gt
<br>;other selected P routers and every PE router needs to be &lt;br&gt;&amp;gt
;connected to <br>at least two selected<br>&gt;&nbsp; P routers.&lt;br&gt;&amp;
gt;&lt;br&gt;&amp;gt;When you are done with this configuration, you are<br> lef
t with a &lt;br&gt;&amp;gt;situation in which *every* PE and selected P router 
will h<br>ave &lt;br&gt;&amp;gt;*all* L1VPN routes.&lt;br&gt;&amp;gt;&lt;br&gt;
&amp;gt;Thanks,&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;John
>  &lt;br&gt;<br>&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;-----Original Message-----&l
t;br&gt;&amp;gt;&amp;gt;From: Igor Bryskin [mailt<br>o:&lt;a ymailto="mailto:<a
ymailto="mailto:[email-masked]" href="mailto:[email-masked]">i_brysk
[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="ma
ilto:[email-masked]">[email-masked]</a>"&gt;i_b<br><a ymailto="mailto
:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt
;]&lt;br&gt;&amp;gt;&amp;gt;Sent: Friday, August 29, 2008 12:10 PM&lt;br&gt;&am
p;gt;<br>&amp;gt;To: Drake, John E; Yakov Rekhter; Lou Berger&lt;br&gt;&amp;gt;
&amp;gt;Cc: Yakov Rekhter; <br>Adrian Farrel; &lt;a ymailto="mailto:<a ymailto=
"mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]
</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">
[email-masked]</a><br><a target="_blank" href="http://tf.org">tf.org</a>"&gt;<a
>  ymailto="mailto:[email-masked]" href="mailto:[email-masked]">ccamp@o
ps.ietf.org</a>&lt;/a&gt;; &lt;br&gt;&amp;gt;&amp;gt;&lt;a ymailto="mailto:<a y
mailto="mailto:[email-masked]" href="mailto:[email-masked]">softwires@ietf.
o</a><br>rg" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:s
[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:softwires@ietf
.org" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&lt;br&g
t;&amp;gt;&amp;gt;Subject:<br> Re: [Softwires] BGP TE attr last call by softwir
es WG (2nd &lt;br&gt;&amp;gt;&amp;gt;questio<br>n)&lt;br&gt;&amp;gt;&amp;gt;&lt
;br&gt;&amp;gt;&amp;gt;Are you calling me silly? Are you coming to Minneapol<br
>is?<br>&gt;&nbsp; :=)&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;Serio
usly, what is wrong in your opinion with thi<br>s approach? &lt;br&gt;&amp;gt;&
amp;gt;Many people are talking about multi-instance IGPs. What<br> they have in
>  &lt;br&gt;&amp;gt;&amp;gt;mind is improving the IGP scalability:&lt;br&gt;&a
mp;gt;&amp;gt;a) <br>by removing non-IP advertisements from the instance of IGP
that &lt;br&gt;&amp;gt;&amp;gt;man<br>ages IP routing/forwarding tables into s
eparate IGP instance(s);&lt;br&gt;&amp;gt;&amp;gt;b) <br>by distributing non-IP
information only to and via &lt;br&gt;&amp;gt;inerested parties &lt;b<br>r&gt;
&amp;gt;&amp;gt;leaving the bulk of Ps out of the process.&lt;br&gt;&amp;gt;&am
p;gt;&lt;br&gt;&amp;gt;&amp;gt;In <br>my opinion this is exactly what is needed
for the OSPF-based L1VPN &lt;br&gt;&amp;gt;&amp;gt;<br>application.&lt;br&gt;&
amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;Igor&lt;br&gt;&amp;gt;&amp;gt;&lt;br&g
t;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&lt;br<br>&gt;&amp;gt;&amp;gt;&lt;b
r&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;----- 
Original Message ----&lt;br&gt;&amp;gt<br>;&amp;gt;From: "Drake, John E" &amp;l
t;&lt;a
>  ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:Jo
[email-masked]">[email-masked]</a>" hre<br>f="mailto:<a ymail
to="mailto:[email-masked]" href="mailto:[email-masked]">Joh
[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href
="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;g
t;&lt;br&gt;&amp;gt;&amp;gt<br>;To: Igor Bryskin<br>&gt;&nbsp; &amp;lt;&lt;a ym
ailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:i_bryskin@ya
hoo.com">[email-masked]</a>" href="mailto:<a ymailto="mailto:i_bryskin@yah
oo.com" href="mailto:[email-masked]">[email-masked]</a><br>"&gt;<a ym
ailto="mailto:[email-masked]" href="mailto:[email-masked]">i_bryskin@
yahoo.com</a>&lt;/a&gt;&amp;gt;; Yakov Rekhter &lt;br&gt;&amp;gt;&amp;gt;&amp;l
t;&lt;a ymailto="mailto<br>:<a ymailto="mailto:[email-masked]"
>  href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymail
to="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]
</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">
[email-masked]</a>&lt;/a&gt;&amp;gt;; <br>Lou Berger &amp;lt;&lt;a ymailto="
mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">lber
[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:
[email-masked]">[email-masked]</a><br>et"&gt;<a ymailto="mailto:[email-masked]
t" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;&lt;br&
gt;&amp;gt;&amp;gt;Cc: Yakov Rekhter &amp;lt;&lt;a ymailto="mailt<br>o:<a ymail
to="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]
</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:yakov@jun
iper.net">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]"
>  href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;;<br>
Adrian Farrel &lt;br&gt;&amp;gt;&amp;gt;&amp;lt;&lt;a ymailto="mailto:<a ymail
to="mailto:[email-masked]" href="mailto:[email-masked]">adrian@olddog
.co.uk</a>" href="ma<br>ilto:<a ymailto="mailto:[email-masked]" href="mail
to:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:adrian@o
lddog.co.uk" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt
;&amp;gt;; &lt;a ymailto="mailto:ccamp<br>@ops.ietf.org" href="mailto:<a ymailt
o="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]
rg</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]
rg">[email-masked]</a>&lt;/a&gt;; &lt;a ymai<br>lto="mailto:<a ymailto="mai
lto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>
" href="mailto:<a ymailto="mailto:[email-masked]"
>  href="mailto:[email-masked]">[email-masked]</a>"&gt;softwires@ietf<b
r>.org&lt;/a&gt;&lt;br&gt;&amp;gt;&amp;gt;Sent: Friday, August 29, 2008 2:31:36
PM&lt;br&gt;&amp;gt;&amp;gt;Subject<br>: RE: [Softwires] BGP TE attr last call
by softwires WG (2nd<br>&gt;&nbsp; &lt;br&gt;&amp;gt;&amp;gt;question)&lt;br&g
t;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;So you are proposing an OSPF ro<br>
ute reflector?&amp;nbsp; At what point does the &lt;br&gt;&amp;gt;&amp;gt;silli
ness stop?&lt;br&gt;&amp;gt;<br>&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;-----
Original Message-----&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;From: Igor Bryski<br>n [
mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mail
to:[email-masked]">[email-masked]</a>" href="mailto:i_bryskin@yahoo.<
br>com"&gt;<a ymailto="mailto:[email-masked]" href="mailto:i_bryskin@yahoo
.com">[email-masked]</a>&lt;/a&gt;]&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Sent:
Friday, August 29,
>  2008 11:2<br>9 AM&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;To: Drake, John E; Yakov 
Rekhter; Lou Berger&lt;br&gt;&amp;gt;&amp;gt;&amp;gt<br>;Cc: Yakov Rekhter; Adr
ian Farrel; &lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="
mailto:[email-masked]">[email-masked]</a>" href=<br>"mailto:<a ymailto=
"mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]
</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]
">[email-masked]</a>&lt;/a&gt;; &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;a yma
ilto=<br>"mailto:<a ymailto="mailto:[email-masked]" href="mailto:softwires@
ietf.org">[email-masked]</a>" href="mailto:<a ymailto="mailto:softwires@iet
f.org" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="
mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]<
/a><br>&lt;/a&gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Subject: Re: [Softwires] BGP
TE attr last call by
>  softwires<br> WG (2nd&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;question)&lt;br&gt;&a
mp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Hi John,&lt;br&gt;&amp;
g<br>t;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;No, not really. When y
ou add a PE you configure<br>&gt;&nbsp; local&lt;br&gt;&amp;gt;&amp;gt;interfac
es, local&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;VPN port mappings, stuff l<br>ike th
at. While doing this you will also &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;configure 
an IPinIP tu<br>nnel to one of your spoke Ps and enable L1VPN &lt;br&gt;&amp;gt
;&amp;gt;&amp;gt;OSPF instance on <br>the tunnel.&lt;br&gt;&amp;gt;&amp;gt;&amp
;gt;Once you did that the local VPN information will be <br>flooded&lt;br&gt;&a
mp;gt;&amp;gt;accross the&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;overlay, likewise, t
he new PE wil<br>l get all the necessary information &lt;br&gt;&amp;gt;&amp;gt;
&amp;gt;from other
>  PEs.&lt;br&gt;&amp;gt;&amp;gt;<br>&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;
Cheers,&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Igor&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;<br>&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;----- O
riginal Message ----&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;From: "Drake, John E<br>"
&amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" hre
f="mailto:[email-masked]">[email-masked]</a>" href="mailto:
John.E.Drake2@b<br><a target="_blank" href="http://oeing.com">oeing.com</a>"&gt
;<a ymailto="mailto:[email-masked]" href="mailto:John.E.Drake2@boeing
.com">[email-masked]</a>&lt;/a&gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&
amp;gt;To: Igor Bryskin &amp;lt<br>;&lt;a ymailto="mailto:<a ymailto="mailto:i_
[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" h
ref="mailto:<a ymailto="mailto:[email-masked]"
>  href="mailto:[email-masked]">[email-masked]</a>"&gt;i_br<br><a yma
ilto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>
&lt;/a&gt;&amp;gt;; Yakov Rekhter &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;lt;&lt
;a ymailto="mailto:y<br><a ymailto="mailto:[email-masked]" href="mailto:akov@
juniper.net">[email-masked]</a>"<br>&gt;&nbsp; href="mailto:<a ymailto="mailt
o:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;
<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">yakov@jun
iper.net</a>&lt;/a&gt;&amp;gt;; Lou Berger &amp;lt;&lt;a<br> ymailto="mailto:<a
ymailto="mailto:[email-masked]" href="mailto:[email-masked]">lberger@labn.
net</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:lberger
@labn.net">[email-masked]</a>"&gt;lberger@labn.<br>net&lt;/a&gt;&amp;gt;&lt;b
r&gt;&amp;gt;&amp;gt;&amp;gt;Cc: Yakov Rekhter &amp;lt;&lt;a ymailto="mailto:ya
kov@junip<br><a
>  target="_blank" href="http://er.net">er.net</a>" href="mailto:<a ymailto="ma
ilto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&
gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">yakov@
juniper.net</a>&lt;/a&gt;&amp;gt;; Adrian Farre<br>l &lt;br&gt;&amp;gt;&amp;gt;
&amp;gt;&amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" h
ref="mailto:[email-masked]">[email-masked]</a>" href="mailto:adri<br>
<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked].
uk</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]
o.uk">[email-masked]</a>&lt;/a&gt;&amp;gt;; &lt;a ymailto="mailto:<a ymail
to="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>.
org" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:ccamp@ops
.ietf.org">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]"
>  href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;; &lt;a yma
ilto="mail<br>to:<a ymailto="mailto:[email-masked]" href="mailto:softwires@
ietf.org">[email-masked]</a>" href="mailto:<a ymailto="mailto:softwires@iet
f.org" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="
mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]<
/a>&lt;/a&gt;&lt;<br>br&gt;&amp;gt;&amp;gt;&amp;gt;Sent: Friday, August 29, 200
8 11:20:16 AM&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Subject<br>: RE: [Softwires] BGP
TE attr last call by softwires WG (2nd&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;que<br
>stion)&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Igor
,&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Does<br>n'
t this defeat auto-discovery?&amp;nbsp; I.e., how is a new PE &lt;br&gt;&amp;gt
;added to a <br>&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;given<br>&gt;&nbsp;
>  L1VPN?&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Th
anks,&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt<br>;Jo
hn&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;-
----Original Message-----&lt;br&gt;&amp;gt;&amp;gt;<br>&amp;gt;&amp;gt;From: Ig
or Bryskin [mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]
" href="mailto:[email-masked]">[email-masked]</a>" href<br>="mailto:<
a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">i_brys
[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:i_br
[email-masked]">[email-masked]</a>&lt;/a&gt;]&lt;br&gt;&amp;gt;&amp;gt;&a
mp;gt;&amp;gt;Sent:<br> Friday, August 29, 2008 5:51 AM&lt;br&gt;&amp;gt;&amp;g
t;&amp;gt;&amp;gt;To: Yakov Rekhter; Lou Berg<br>er&lt;br&gt;&amp;gt;&amp;gt;&a
mp;gt;&amp;gt;Cc: Yakov Rekhter; Adrian Farrel; &lt;a ymailto="mailto:ccam<br><
a
>  ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]<
/a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:ccamp@ops
.ietf.org">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" hr
ef="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;; &lt;br&gt;&amp
;g<br>t;&amp;gt;&amp;gt;&amp;gt;&lt;a ymailto="mailto:<a ymailto="mailto:softwi
[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="ma
ilto:softwires@iet<br><a target="_blank" href="http://f.org">f.org</a>"&gt;<a y
mailto="mailto:[email-masked]" href="mailto:[email-masked]">softwires@i
etf.org</a>&lt;/a&gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Subject: Re: [So
ftwires] BGP T<br>E attr last call by softwires WG
>  (2nd&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;question)&lt;br&gt;&amp;gt;&am
p;gt;&amp;<br>gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Yakov,&lt;br
&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Y
ou sa<br>id:&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt
;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;... And while on<br>
the subject of<br>&gt;&nbsp; scaling, please keep in mind&lt;br&gt;&amp;gt;&am
p;gt;that BGP&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;only sto<br>res L1VPN ro
utes on PEs that have sites of that VPN&lt;br&gt;&amp;gt;&amp;gt;connected&lt;b
r&gt;&amp;gt<br>;&amp;gt;&amp;gt;&amp;gt;to them, and on an RR if used, but *no
t* on any of the P &lt;br&gt;&amp;gt;r<br>outers. In &lt;br&gt;&amp;gt;&amp;gt;
&amp;gt;&amp;gt;contrast, rfc5252 (OSPF for L1VPN&lt;br&gt;&amp;gt;&amp;gt;&amp
;gt<br>;&amp;gt;autodiscovery) results in storing *all VPN TE information &lt;b
r&gt;&amp;gt;for all
>  <br>the&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;VPNs* on *all* the IGP node
s, both P and PE. So, clearly<br> BGP-based &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&
amp;gt;approach scales better than OSPF-based approach.<br>&lt;br&gt;&amp;gt;&a
mp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Yakov.&lt;br&gt
;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;<br>gt;&amp;gt;
This is not true in case of multi-instance OSPF: one can build an &lt;br&gt;&am
p;g<br>t;&amp;gt;&amp;gt;&amp;gt;overlay interconnecting PEs via one or small n
umber of Ps&lt;br&gt;&amp;gt;<br>&amp;gt;&amp;gt;using IPinIP&lt;br&gt;&amp;gt;
&amp;gt;&amp;gt;&amp;gt;tunnels and run in this overlay an inst<br>ance of OSPF
specifically &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;designated for distribu
tion of L1<br>VPN information. In<br>&gt;&nbsp; this&lt;br&gt;&amp;gt;&amp;gt;&
amp;gt;case the OSPF&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;solution won't sc
ale an<br>y worse than
>  the BGP approach. Note. &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;that rfc252&lt;br&
gt;&amp;gt;&amp;gt;&amp;gt<br>;&amp;gt;never said that the instance of OSPF use
d for flooding of the L1VPN &lt;br&gt;&amp;g<br>t;&amp;gt;&amp;gt;&amp;gt;infor
mation must be the same instance that is used for the&lt;br&gt;&amp;gt<br>;&amp
;gt;&amp;gt;distribution&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;of IP-related
>  LSAs.&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt<br>;&lt;br&gt;&amp;gt;&amp;gt
;&amp;gt;&amp;gt;Regards,&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Igor&lt;br&g
t;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;g<br>t;&amp;gt;&amp;gt;&amp;gt
;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&a
mp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;<br>gt;&amp;gt;&
lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&a
mp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;<br
>&amp;gt;&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;&lt;br&gt;&lt;br
&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;br&gt;<br>&gt; <br>&gt;&nbsp; &nbsp
; &nbsp;  &lt;/body&gt;&lt;/html&gt;<br>&gt; --0-1141253910-1220449648=:97601--
<br></div></div></div><br>
> 
> 
> 
>       </body></html>
> --0-1852435290-1220452662=:19087--
> 

--0-1935299916-1220456544=:20196
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div>Yakov,<br><br>Please, see in line<br><br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;">----- Original Message ----<br>From: Yakov Rekhter &lt;[email-masked]&gt;<br>To: Igor Bryskin &lt;[email-masked]&gt;<br>Cc: "Drake, John E" &lt;[email-masked]&gt;; Lou Berger &lt;[email-masked]&gt;; Adrian Farrel &lt;[email-masked]&gt;; [email-masked]; [email-masked]<br>Sent: Wednesday, September 3, 2008 11:13:04 AM<br>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) <br><br>Igor,<br><br>&gt; Yakov,<br>&gt; <br>&gt; Please,&nbsp; see in-line.<br><br>see in-line...<br><br>&gt; ----- Original Message ----<br>&gt; From: Yakov Rekhter
 &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt; To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt; Cc: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>; Adrian Farrel &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt; Sent: Wednesday, September 3, 2008 9:55:49 AM<br>&gt; Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)<br> <br>&gt; <br>&gt;
 Igor,<br>&gt; <br>&gt; &gt; And I am not arguing that sufficient redundancy must be provided. However <br>&gt; &gt; you said:<br>&gt; &gt; &gt;For your suggested approach to work with sufficient <br>&gt; &gt; &gt;redundancy, the topology of the overlay needs to be configured <br>&gt; &gt; &gt;such that every selected P router is connected to at least two <br>&gt; &gt; &gt;other selected P routers and every PE router needs to be <br>&gt; &gt; &gt;connected to at least two selected P routers.<br>&gt; &gt; <br>&gt; &gt; If you just simply interconnect all VPN-aware PEs into a single<br>&gt; &gt; ring via IPin IP tunnels and run an instance of OSPF to distribute<br>&gt; &gt; VPN-related information between them, it will provide sufficient<br>&gt; &gt; redundancy and involve exactly *zero* Ps.<br>&gt; &gt;<br>&gt; &gt; So, I want you to drop your lecturing tone for a minute and simply<br>&gt; &gt; tell in what respect in your opinion this approach is not
 perfect<br>&gt; &gt; fo the L1VPN application. Otherwise, I am not interested in this<br>&gt; &gt; discussion any longer. I do like to hear comments from other people.<br>&gt; <br>&gt; Since you asked, one problem with using OSPF, as John correctly<br>&gt; pointed out, is that you are left with a situation in which *every* PE <br>&gt; router will have *all* L1VPN routes for all the L1VPNs. Of course, <br>&gt; this is "perfect" in a sense that you can do no worse than that :-)<br>&gt; <br>&gt; IB&gt;&gt; Ok. Several points here. Note that neither Ps nor VPN-unaware PEs <br>&gt; IB&gt;&gt; participate in the distribution/maintenance of VPN information, <br>&gt; IB&gt;&gt; which is already significantly better than what you said about <br>&gt; IB&gt;&gt; the OSPF solution in your previous mail:<br>&gt; <br>&gt; &gt;... And while on the subject of scaling, please keep in mind that BGP<br>&gt; &gt;&nbsp;  only stores L1VPN routes on PEs that have sites of
 that VPN<br>&gt; &gt;&nbsp;  connected to them, and on an RR if used, but *not* on any of the P <br>&gt; &gt;&nbsp;  routers. In contrast, rfc5252 (OSPF for L1VPN<br>&gt; &gt;&nbsp;  autodiscovery) results in storing *all VPN TE information <br>&gt; &gt;&nbsp;  for all the VPNs* on *all* the IGP nodes, both P and PE. So, clearly <br>&gt; &gt;<br>&gt; &gt;&nbsp;  BGP-based approach scales better than OSPF-based approach.<br>&gt; &gt; &gt;&gt;&gt;&gt;Yakov.<br>&gt; <br>&gt; I do agree that if you use a single ring overlay interconnecting<br>&gt; all VPN aware PEs you will have LSDBs at all PEs contain VPN info<br>&gt; about all VPNs. However, in case of L1VPN this is not VPN routes,<br>&gt; rather VPN Provider-To-Customer port mappings which I believe will<br>&gt; prove to be significantly smaller, so I am not sure yet how bad<br>&gt; is that. In any case, if it does present a problem on a network<br>&gt; with large number of VPNs, who said that it has to
 be a single<br>&gt; overlay? Why not to configure several overlays - each containing a<br>&gt; single ring that interconnects PEs participating in a common sub-set<br>&gt; of VPNs, and run a seperate instance o f OSPF in each overlay?<br><br>Sure. And this would be a good illustration of the fact that the<br>whole idea of using OSPF for L1VPN auto-discovery falls into the<br>paradigm of inherently flawed designs whose weakness can be solved<br>only by the usage of elaborate features, that, in turn, introduce <br>a new set of problems.<br><br>Yakov.<br><br>Sorry, Yakov, those are just words. All I am trying to achieve is to use a link state protocol for reliable distribution of information between interested parties and exclusively via interested parties with all other network participants remaining oblivious to the process. With multiple instances of OSPF running in separate overlays of VPN-aware PEs, I believe, this goal could be achieved close to
 perfection. All we can argue about is which approach - BGP or OSPF - requires a lesser configuration effort to achieve the same goals, but you can not claim better scalability properties for the BGP solution.<br><br>Igor<br><br>&gt; &gt; <br>&gt; &gt; <br>&gt; &gt; <br>&gt; &gt; <br>&gt; &gt; ----- Original Message ----<br>&gt; &gt; From: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt; &gt; To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; <br>Lo<br>&gt; u Berger &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt; &gt; Cc: Yakov Rekhter &lt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian Farrel &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;;<br> c<br>&gt; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt; &gt; Sent: Wednesday, September 3, 2008 8:10:07 AM<br>&gt; &gt; Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd questio<br>n)<br>&gt; &gt; <br>&gt; &gt; Igor,<br>&gt; &gt; <br>&gt; &gt; Actually, I am not sure that you do understand what I wrote, because you<br>&gt; &gt; are providing examples of the redundancy that I specified - every PE<br>&gt; &gt; router needs to have connectivity to two other routers in the IGP<br>&gt; &gt; instance.<br>&gt; &gt; <br>&gt; &gt; Thanks,<br>&gt; &gt; <br>&gt; &gt; John <br>&gt; &gt; <br>&gt; &gt; &gt;-----Original
 Message-----<br>&gt; &gt; &gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>] <br>&gt; &gt; &gt;Sent: Tuesday, September 02, 2008 3:06 PM<br>&gt; &gt; &gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt; &gt; &gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>&gt; &gt; &gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt; &gt; &gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG <br>&gt; &gt; &gt;(2nd question)<br>&gt; &gt; &gt;<br>&gt; &gt; &gt;Hi John,<br>&gt; &gt; &gt;<br>&gt; &gt; &gt;I understand what you are saying and disagree. The overlay I <br>&gt; &gt; &gt;am talking about logically is a separate network and as any <br>&gt; &gt; &gt;network it should be sufficiently redundant to function. There <br>&gt; &gt;
 &gt;is a number of ways how you can address the redundancy <br>&gt; &gt; &gt;concerns. Look at the examples below:<br>&gt; &gt; &gt;<br>&gt; &gt; &gt;a) interconnect all VPN-aware PEs into a single ring: <br>&gt; &gt; &gt;PE=======PE<br>&gt; &gt; &gt; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||<br>&gt; &gt; &gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  PE <br>&gt; &gt; &gt;||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||<br>&gt; &gt; &gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  PE <br>&gt; &gt; &gt;||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||<br>&gt; &gt; &gt;...&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ....<br>&gt; &gt; &gt;PE=======PE<br>&gt; &gt; &gt;<br>&gt; &gt; &gt;b) connect each PE to two interconnected Ps <br>&gt; &gt; &gt;<br>&gt; &gt; &gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  P&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
 &nbsp;  PE<br>&gt; &gt; &gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>&gt; &gt; &gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PE <br>&gt; &gt; &gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>&gt; &gt; &gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PE <br>&gt; &gt; &gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>&gt; &gt; &gt;...&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ....<br>&gt; &gt; &gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
 P&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  PE<br>&gt; &gt; &gt;<br>&gt; &gt; &gt;<br>&gt; &gt; &gt;Note that tunnels can traverse any number of VPN-unaware Ps and PEs.<br>&gt; &gt; &gt;<br>&gt; &gt; &gt;Igor<br>&gt; &gt; &gt;<br>&gt; &gt; &gt;<br>&gt; &gt; &gt;----- Original Message ----<br>&gt; &gt; &gt;From: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt; &gt; &gt;To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt; &gt; &gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt; &gt; &gt;Cc: Yakov Rekhter &lt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian Farrel <br>&gt; &gt; &gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt; &gt; &gt;Sent: Tuesday, September 2, 2008 2:24:26 PM<br>&gt; &gt; &gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG <br>&gt; &gt; &gt;(2nd question)<br>&gt; &gt; &gt;<br>&gt; &gt; &gt;Igor,<br>&gt; &gt; &gt;<br>&gt; &gt; &gt;Several years ago when OSPF was first proposed as an <br>&gt; &gt; &gt;autodiscovery mechanism for L1VPNs, you were told that it was <br>&gt; &gt; &gt;a bad idea due to its scaling properties and impact on the IGP.<br>&gt; &gt; &gt;<br>&gt; &gt; &gt;You are now tacitly agreeing with those who told you it was a bad
 idea.<br>&gt; &gt; &gt;<br>&gt; &gt; &gt;For your suggested approach to work with sufficient <br>&gt; &gt; &gt;redundancy, the topology of the overlay needs to be configured <br>&gt; &gt; &gt;such that every selected P router is connected to at least two <br>&gt; &gt; &gt;other selected P routers and every PE router needs to be <br>&gt; &gt; &gt;connected to at least two selected P routers.<br>&gt; &gt; &gt;<br>&gt; &gt; &gt;When you are done with this configuration, you are left with a <br>&gt; &gt; &gt;situation in which *every* PE and selected P router will have <br>&gt; &gt; &gt;*all* L1VPN routes.<br>&gt; &gt; &gt;<br>&gt; &gt; &gt;Thanks,<br>&gt; &gt; &gt;<br>&gt; &gt; &gt;John <br>&gt; &gt; &gt;<br>&gt; &gt; &gt;&gt;-----Original Message-----<br>&gt; &gt; &gt;&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>]<br>&gt; &gt; &gt;&gt;Sent: Friday, August 29, 2008 12:10
 PM<br>&gt; &gt; &gt;&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt; &gt; &gt;&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>&gt; &gt; &gt;&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt; &gt; &gt;&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd <br>&gt; &gt; &gt;&gt;question)<br>&gt; &gt; &gt;&gt;<br>&gt; &gt; &gt;&gt;Are you calling me silly? Are you coming to Minneapolis? :=)<br>&gt; &gt; &gt;&gt;<br>&gt; &gt; &gt;&gt;Seriously, what is wrong in your opinion with this approach? <br>&gt; &gt; &gt;&gt;Many people are talking about multi-instance IGPs. What they have in <br>&gt; &gt; &gt;&gt;mind is improving the IGP scalability:<br>&gt; &gt; &gt;&gt;a) by removing non-IP advertisements from the instance of IGP that <br>&gt; &gt; &gt;&gt;manages IP routing/forwarding tables
 into separate IGP instance(s);<br>&gt; &gt; &gt;&gt;b) by distributing non-IP information only to and via <br>&gt; &gt; &gt;inerested parties <br>&gt; &gt; &gt;&gt;leaving the bulk of Ps out of the process.<br>&gt; &gt; &gt;&gt;<br>&gt; &gt; &gt;&gt;In my opinion this is exactly what is needed for the OSPF-based L1VPN <br>&gt; &gt; &gt;&gt;application.<br>&gt; &gt; &gt;&gt;<br>&gt; &gt; &gt;&gt;Igor<br>&gt; &gt; &gt;&gt;<br>&gt; &gt; &gt;&gt;<br>&gt; &gt; &gt;&gt;<br>&gt; &gt; &gt;&gt;<br>&gt; &gt; &gt;&gt;<br>&gt; &gt; &gt;&gt;<br>&gt; &gt; &gt;&gt;----- Original Message ----<br>&gt; &gt; &gt;&gt;From: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt; &gt; &gt;&gt;To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt; &gt; &gt;&gt;&lt;<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt; &gt; &gt;&gt;Cc: Yakov Rekhter &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian Farrel <br>&gt; &gt; &gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt; &gt; &gt;&gt;Sent: Friday, August 29, 2008 2:31:36 PM<br>&gt; &gt; &gt;&gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd <br>&gt; &gt; &gt;&gt;question)<br>&gt; &gt; &gt;&gt;<br>&gt; &gt; &gt;&gt;So you are proposing an OSPF route reflector?&nbsp; At what point
 does the <br>&gt; &gt; &gt;&gt;silliness stop?<br>&gt; &gt; &gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;-----Original Message-----<br>&gt; &gt; &gt;&gt;&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>]<br>&gt; &gt; &gt;&gt;&gt;Sent: Friday, August 29, 2008 11:29 AM<br>&gt; &gt; &gt;&gt;&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt; &gt; &gt;&gt;&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>&gt; &gt; &gt;&gt;&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt; &gt; &gt;&gt;&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd<br>&gt; &gt; &gt;&gt;&gt;question)<br>&gt; &gt; &gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;Hi John,<br>&gt; &gt; &gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;No, not really. When you add a PE you
 configure local<br>&gt; &gt; &gt;&gt;interfaces, local<br>&gt; &gt; &gt;&gt;&gt;VPN port mappings, stuff like that. While doing this you will also <br>&gt; &gt; &gt;&gt;&gt;configure an IPinIP tunnel to one of your spoke Ps and enable L1VPN <br>&gt; &gt; &gt;&gt;&gt;OSPF instance on the tunnel.<br>&gt; &gt; &gt;&gt;&gt;Once you did that the local VPN information will be flooded<br>&gt; &gt; &gt;&gt;accross the<br>&gt; &gt; &gt;&gt;&gt;overlay, likewise, the new PE will get all the necessary information <br>&gt; &gt; &gt;&gt;&gt;from other PEs.<br>&gt; &gt; &gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;Cheers,<br>&gt; &gt; &gt;&gt;&gt;Igor<br>&gt; &gt; &gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;----- Original Message ----<br>&gt; &gt; &gt;&gt;&gt;From: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt; &gt; &gt;&gt;&gt;To: Igor Bryskin &lt;<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt; &gt; &gt;&gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt; &gt; &gt;&gt;&gt;Cc: Yakov Rekhter &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian Farrel <br>&gt; &gt; &gt;&gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt; &gt; &gt;&gt;&gt;Sent: Friday, August 29, 2008 11:20:16 AM<br>&gt; &gt; &gt;&gt;&gt;Subject: RE: [Softwires] BGP TE attr last
 call by softwires WG (2nd<br>&gt; &gt; &gt;&gt;&gt;question)<br>&gt; &gt; &gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;Igor,<br>&gt; &gt; &gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;Doesn't this defeat auto-discovery?&nbsp; I.e., how is a new PE <br>&gt; &gt; &gt;added to a <br>&gt; &gt; &gt;&gt;&gt;given L1VPN?<br>&gt; &gt; &gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;Thanks,<br>&gt; &gt; &gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;John<br>&gt; &gt; &gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;&gt;-----Original Message-----<br>&gt; &gt; &gt;&gt;&gt;&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>]<br>&gt; &gt; &gt;&gt;&gt;&gt;Sent: Friday, August 29, 2008 5:51 AM<br>&gt; &gt; &gt;&gt;&gt;&gt;To: Yakov Rekhter; Lou Berger<br>&gt; &gt; &gt;&gt;&gt;&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>&gt; &gt;
 &gt;&gt;&gt;&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt; &gt; &gt;&gt;&gt;&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd<br>&gt; &gt; &gt;&gt;&gt;&gt;question)<br>&gt; &gt; &gt;&gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;&gt;Yakov,<br>&gt; &gt; &gt;&gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;&gt;You said:<br>&gt; &gt; &gt;&gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;&gt;... And while on the subject of scaling, please keep in mind<br>&gt; &gt; &gt;&gt;that BGP<br>&gt; &gt; &gt;&gt;&gt;&gt;only stores L1VPN routes on PEs that have sites of that VPN<br>&gt; &gt; &gt;&gt;connected<br>&gt; &gt; &gt;&gt;&gt;&gt;to them, and on an RR if used, but *not* on any of the P <br>&gt; &gt; &gt;routers. In <br>&gt; &gt; &gt;&gt;&gt;&gt;contrast, rfc5252 (OSPF for L1VPN<br>&gt; &gt; &gt;&gt;&gt;&gt;autodiscovery) results in storing *all VPN TE information <br>&gt; &gt;
 &gt;for all the<br>&gt; &gt; &gt;&gt;&gt;&gt;VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based <br>&gt; &gt; &gt;&gt;&gt;&gt;approach scales better than OSPF-based approach.<br>&gt; &gt; &gt;&gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;&gt;Yakov.<br>&gt; &gt; &gt;&gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;&gt;This is not true in case of multi-instance OSPF: one can build an <br>&gt; &gt; &gt;&gt;&gt;&gt;overlay interconnecting PEs via one or small number of Ps<br>&gt; &gt; &gt;&gt;&gt;using IPinIP<br>&gt; &gt; &gt;&gt;&gt;&gt;tunnels and run in this overlay an instance of OSPF specifically <br>&gt; &gt; &gt;&gt;&gt;&gt;designated for distribution of L1VPN information. In this<br>&gt; &gt; &gt;&gt;&gt;case the OSPF<br>&gt; &gt; &gt;&gt;&gt;&gt;solution won't scale any worse than the BGP approach. Note. <br>&gt; &gt; &gt;&gt;&gt;that rfc252<br>&gt; &gt; &gt;&gt;&gt;&gt;never said that the instance of OSPF used for flooding of the L1VPN <br>&gt; &gt;
 &gt;&gt;&gt;&gt;information must be the same instance that is used for the<br>&gt; &gt; &gt;&gt;&gt;distribution<br>&gt; &gt; &gt;&gt;&gt;&gt;of IP-related LSAs.<br>&gt; &gt; &gt;&gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;&gt;Regards,<br>&gt; &gt; &gt;&gt;&gt;&gt;Igor<br>&gt; &gt; &gt;&gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;&gt;<br>&gt; &gt; &gt;&gt;<br>&gt; &gt; &gt;&gt;<br>&gt; &gt; &gt;&gt;<br>&gt; &gt; &gt;<br>&gt; &gt; &gt;<br>&gt; &gt; &gt;<br>&gt; &gt; &gt;<br>&gt; &gt; <br>&gt; &gt; <br>&gt; &gt;&nbsp; &nbsp; &nbsp; <br>&gt; &gt; --0-1141253910-1220449648=:97601<br>&gt; &gt; Content-Type: text/html; charset=us-ascii<br>&gt; &gt; <br>&gt; &gt; &lt;html&gt;&lt;head&gt;&lt;style type="text/css"&gt;&lt;!-- DIV {margin:0px;} --&gt;&lt;/style&gt;&lt;/head<br>&gt;&lt;<br>&gt; body&gt;&lt;div
 style="font-family:times new roman, new york, times, serif;font-siz<br>e:<br>&gt; 12pt"&gt;&lt;div&gt;And I am not arguing that sufficient redundancy must be provided. <br>Ho<br>&gt; wever you said:&lt;br&gt;&amp;gt;For your suggested approach to work with sufficient &lt;b<br>r&gt;<br>&gt; &amp;gt;redundancy, the topology of the overlay needs to be configured &lt;br&gt;&amp;gt;su<br>ch<br>&gt; that every selected P router is connected to at least two &lt;br&gt;&amp;gt;other selec<br>t<br>&gt; ed P routers and every PE router needs to be &lt;br&gt;&amp;gt;connected to at least tw<br>o <br>&gt; selected P routers.&lt;br&gt;&lt;br&gt;If you just simply interconnect all VPN-aware PEs <br>in<br>&gt; to a single ring via IPinIP tunnels and run an instance of OSPF to distribute<br> V<br>&gt; PN-related information between them, it will provide sufficient redundancy an<br>d <br>&gt; involve exactly *zero* Ps.&lt;br&gt;So, I want you to drop your lecturing tone
 for <br>a <br>&gt; minute and simply tell in what respect in your opinion this approach is not p<br>er<br>&gt; fect fo the L1VPN<br>&gt; &gt;&nbsp; application. Otherwise, I am not interested in this discussion any longer.<br> I<br>&gt; do like to hear comments from other people.&lt;br&gt;&lt;br&gt;Igor &lt;br&gt;&lt;br&gt;&lt;/div&gt;&lt;div st<br>y<br>&gt; le="font-family: times new roman,new york,times,serif; font-size: 12pt;"&gt;&lt;br&gt;<br>&lt;d<br>&gt; iv style="font-family: arial,helvetica,sans-serif; font-size: 13px;"&gt;----- Or<br>ig<br>&gt; inal Message ----&lt;br&gt;From: "Drake, John E" &amp;lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&amp;gt;&lt;b<br>r&gt;<br>&gt; To: Igor Bryskin &amp;lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&amp;gt;; Yakov Rekhter &amp;lt;yakov@juniper<br>.n<br>&gt; et&amp;gt;; Lou Berger
 &amp;lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&amp;gt;&lt;br&gt;Cc: Yakov Rekhter &amp;lt;yakov@ju<br>ni<br>&gt; per.net&amp;gt;; Adrian Farrel &amp;lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&amp;gt;; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; s<br>of<br>&gt; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;br&gt;Sent: Wednesday, September 3, 2008 8:10:07 AM&lt;br&gt;Subject: <br>RE<br>&gt; : [Softwires] BGP TE attr last call by softwires WG (2nd question)&lt;br&gt;&lt;br&gt;<br>&gt; &gt; Igor,&lt;br&gt;&lt;br&gt;Actually, I am not sure that you do understand what I wrote, b<br>ec<br>&gt; ause you&lt;br&gt;are providing examples of the redundancy that I specified - every<br> P<br>&gt; E&lt;br&gt;router needs to have connectivity to two other routers in the
 IGP&lt;br&gt;ins<br>ta<br>&gt; nce.&lt;br&gt;&lt;br&gt;Thanks,&lt;br&gt;&lt;br&gt;John &lt;br&gt;&lt;br&gt;&amp;gt;-----Original Message-----&lt;br&gt;&amp;gt<br>;F<br>&gt; rom: Igor Bryskin [mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailt<br>o:<br>&gt; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;] &lt;br&gt;&amp;gt;Sent: Tuesday, Septembe<br>r <br>&gt; 02, 2008 3:06 PM&lt;br&gt;&amp;gt;To: Drake, John E; Yakov Rekhter; Lou Berger&lt;br&gt;&amp;gt;C<br>c:<br>&gt; Yakov Rekhter; Adrian Farrel; &lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="ma<br>i<br>&gt; lto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;; &lt;br&gt;&amp;gt;&lt;a ymailto="mailto:so<br>ft<br>&gt; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&lt;br&gt;&amp;g<br>t;<br>&gt; Subject: Re: [Softwires] BGP TE attr last call by softwires WG &lt;br&gt;&amp;gt;(2nd q<br>ue<br>&gt; stion)&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;Hi John,&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;I understand what you are sayin<br>g <br>&gt; and disagree. The<br>&gt; &gt;&nbsp; overlay I &lt;br&gt;&amp;gt;am talking about logically is a separate network and as <br>an<br>&gt; y &lt;br&gt;&amp;gt;network it should be
 sufficiently redundant to function. There &lt;br&gt;<br>&amp;g<br>&gt; t;is a number of ways how you can address the redundancy &lt;br&gt;&amp;gt;concerns. Lo<br>ok<br>&gt; at the examples below:&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;a) interconnect all VPN-aware PEs into <br>a<br>&gt; single ring: &lt;br&gt;&amp;gt;PE=======PE&lt;br&gt;&amp;gt; ||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;<br> <br>&gt; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; ||&lt;br&gt;&amp;gt;PE&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;n<br>bs<br>&gt; p; &amp;nbsp;&nbsp; PE &lt;br&gt;&amp;gt;||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbs<br>p;<br>&gt; &amp;nbsp;&nbsp; ||&lt;br&gt;&amp;gt;PE&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; PE &lt;br&gt;<br>&amp;<br>&gt; gt;||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp;
 ||&lt;br&gt;&amp;g<br>t;<br>&gt; ...&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; ....&lt;br&gt;&amp;gt;PE====<br>==<br>&gt; =PE&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;b) connect each PE to two interconnected Ps &lt;br&gt;&amp;gt;&lt;br&gt;&amp;g<br>t;<br>&gt; PE&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; P&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nb<br>sp<br>&gt; ; &amp;nbsp; &amp;nbsp; &amp;nbsp;<br>&gt; &gt;&nbsp; &amp;nbsp;&nbsp; PE&lt;br&gt;&amp;gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; <br>&amp;n<br>&gt; bsp; &amp;nbsp; ||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; <br> &lt;<br>&gt; br&gt;&amp;gt;PE&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; ||&amp;nbsp; &amp;nbsp; &amp;n<br>bs<br>&gt; p; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;
 &amp;nbsp; &amp;nbsp; PE &lt;br&gt;&amp;gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; <br>&amp;n<br>&gt; bsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; ||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; <br>&amp;n<br>&gt; bsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &lt;br&gt;&amp;gt;PE&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;<br> &amp;<br>&gt; nbsp; &amp;nbsp;&nbsp; ||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp<br>; <br>&gt; PE &lt;br&gt;&amp;gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nb<br>sp<br>&gt; ; ||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &lt;br&gt;&amp;gt;..<br>.&amp;<br>&gt; nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; ||&amp;nbsp; &amp;nbsp; &amp;nbsp<br>; <br>&gt; &amp;nbsp; &amp;nbsp; &amp;nbsp;
 &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; ....&lt;br&gt;&amp;gt;PE&amp;nbsp; &amp;nbsp; &amp;nbsp;<br> &amp;<br>&gt; nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; P&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;<br> &amp;<br>&gt; nbsp; <br>&gt; &gt;&nbsp; PE&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;Note that tunnels can traverse any number of VPN<br>-u<br>&gt; naware Ps and PEs.&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;Igor&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;----- Original <br>Me<br>&gt; ssage ----&lt;br&gt;&amp;gt;From: "Drake, John E" &amp;lt;&lt;a ymailto="mailto:John.E.Drake2@<br>bo<br>&gt; eing.com" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;<br>&amp;g<br>&gt; t;&lt;br&gt;&amp;gt;To: Igor
 Bryskin &amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="<br>ma<br>&gt; ilto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; Yakov Rekhter &lt;br&gt;&amp;gt;<br>&amp;l<br>&gt; t;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;yakov<br>@j<br>&gt; uniper.net&lt;/a&gt;&amp;gt;; Lou Berger &amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href=<br>"m<br>&gt; ailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;&lt;br&gt;&amp;gt;Cc: Yakov Rekhter &amp;lt<br>;&lt;<br>&gt; a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;yakov@ju<br>ni<br>&gt; per.net&lt;/a&gt;&amp;gt;; Adrian Farrel &lt;br&gt;&amp;gt;&amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>o.<br>&gt; uk" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; &lt;a<br>&gt; &gt;&nbsp; ymailto="mailto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;ccamp<br>@o<br>&gt; ps.ietf.org&lt;/a&gt;; &lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:softwire<br>s@<br>&gt; ietf.org"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&lt;br&gt;&amp;gt;Sent: Tuesday, September 2, 2008 2:24<br>:2<br>&gt; 6 PM&lt;br&gt;&amp;gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG &lt;b<br>r&gt;<br>&gt; &amp;gt;(2nd question)&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;Igor,&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;Several years ago when<br> O<br>&gt; SPF was first proposed as an &lt;br&gt;&amp;gt;autodiscovery mechanism for L1VPNs, you <br>we<br>&gt; re told that it was &lt;br&gt;&amp;gt;a bad idea due to its scaling
 properties and impa<br>ct<br>&gt; on the IGP.&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;You are now tacitly agreeing with those who told y<br>o<br>&gt; u it was a bad idea.&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;For your suggested approach to work with <br>su<br>&gt; fficient &lt;br&gt;&amp;gt;redundancy, the topology of the overlay needs to be configur<br>ed<br>&gt; &lt;br&gt;&amp;gt;such that every selected P router is connected to at least two &lt;br&gt;&amp;g<br>t<br>&gt; ;other selected P routers and every PE router needs to be &lt;br&gt;&amp;gt;connected t<br>o <br>&gt; at least two selected<br>&gt; &gt;&nbsp; P routers.&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;When you are done with this configuration, you a<br>re<br>&gt; left with a &lt;br&gt;&amp;gt;situation in which *every* PE and selected P router will <br>h<br>&gt; ave &lt;br&gt;&amp;gt;*all* L1VPN routes.&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;Thanks,&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;John
 &lt;b<br>r&gt;<br>&gt; &amp;gt;&lt;br&gt;&amp;gt;&amp;gt;-----Original Message-----&lt;br&gt;&amp;gt;&amp;gt;From: Igor Bryskin [mai<br>lt<br>&gt; o:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;i<br>_b<br>&gt; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;]&lt;br&gt;&amp;gt;&amp;gt;Sent: Friday, August 29, 2008 12:10 PM&lt;br&gt;&amp;g<br>t;<br>&gt; &amp;gt;To: Drake, John E; Yakov Rekhter; Lou Berger&lt;br&gt;&amp;gt;&amp;gt;Cc: Yakov Rekhter<br>; <br>&gt; Adrian Farrel; &lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:ccamp@ops.<br>ie<br>&gt; tf.org"&gt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;; &lt;br&gt;&amp;gt;&amp;gt;&lt;a ymailto="mailto:softwires@ietf<br>.o<br>&gt; rg" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&lt;br&gt;&amp;gt;&amp;gt;Subjec<br>t:<br>&gt; Re: [Softwires] BGP TE attr last call by softwires WG (2nd &lt;br&gt;&amp;gt;&amp;gt;questi<br>o<br>&gt; n)&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;Are you calling me silly? Are you coming to Minneap<br>ol<br>&gt; is?<br>&gt; &gt;&nbsp; :=)&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;Seriously, what is wrong in your opinion with t<br>hi<br>&gt; s approach? &lt;br&gt;&amp;gt;&amp;gt;Many people are talking about multi-instance IGPs. Wh<br>at<br>&gt; they have in &lt;br&gt;&amp;gt;&amp;gt;mind is improving the IGP
 scalability:&lt;br&gt;&amp;gt;&amp;gt;a)<br> <br>&gt; by removing non-IP advertisements from the instance of IGP that &lt;br&gt;&amp;gt;&amp;gt;m<br>an<br>&gt; ages IP routing/forwarding tables into separate IGP instance(s);&lt;br&gt;&amp;gt;&amp;gt;b<br>) <br>&gt; by distributing non-IP information only to and via &lt;br&gt;&amp;gt;inerested parties <br>&lt;b<br>&gt; r&gt;&amp;gt;&amp;gt;leaving the bulk of Ps out of the process.&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;I<br>n <br>&gt; my opinion this is exactly what is needed for the OSPF-based L1VPN &lt;br&gt;&amp;gt;&amp;g<br>t;<br>&gt; application.&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;Igor&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&lt;<br>br<br>&gt; &gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;----- Original Message ----&lt;br&gt;&amp;<br>gt<br>&gt; ;&amp;gt;From: "Drake, John E"
 &amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" h<br>re<br>&gt; f="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;<br>gt<br>&gt; ;To: Igor Bryskin<br>&gt; &gt;&nbsp; &amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>om<br>&gt; "&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; Yakov Rekhter &lt;br&gt;&amp;gt;&amp;gt;&amp;lt;&lt;a ymailto="mail<br>to<br>&gt; :<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;<br>; <br>&gt; Lou Berger &amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:lberger@labn<br>.n<br>&gt; et"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;Cc: Yakov Rekhter &amp;lt;&lt;a ymailto="mai<br>lt<br>&gt; o:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt<br>;;<br>&gt; Adrian Farrel &lt;br&gt;&amp;gt;&amp;gt;&amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="m<br>a<br>&gt; ilto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; &lt;a ymailto="mailto:cca<br>mp<br>&gt; @ops.ietf.org" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;; &lt;a ym<br>ai<br>&gt; lto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>"&gt;softwires@ie<br>tf<br>&gt; .org&lt;/a&gt;&lt;br&gt;&amp;gt;&amp;gt;Sent: Friday, August 29, 2008 2:31:36 PM&lt;br&gt;&amp;gt;&amp;gt;Subje<br>ct<br>&gt; : RE: [Softwires] BGP TE attr last call by softwires WG (2nd<br>&gt; &gt;&nbsp; &lt;br&gt;&amp;gt;&amp;gt;question)&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;So you are proposing an OSPF <br>ro<br>&gt; ute reflector?&amp;nbsp; At what point does the &lt;br&gt;&amp;gt;&amp;gt;silliness stop?&lt;br&gt;&amp;g<br>t;<br>&gt; &amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;-----Original Message-----&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;From: Igor Brys<br>ki<br>&gt; n [mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:i_bryskin@yaho<br>o.<br>&gt; com"&gt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;]&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Sent: Friday, August 29, 2008 11<br>:2<br>&gt; 9 AM&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;To: Drake, John E; Yakov Rekhter; Lou Berger&lt;br&gt;&amp;gt;&amp;gt;&amp;<br>gt<br>&gt; ;Cc: Yakov Rekhter; Adrian Farrel; &lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" hre<br>f=<br>&gt; "mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;; &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;a ymailt<br>o=<br>&gt; "mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>rg<br>&gt; &lt;/a&gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Subject: Re: [Softwires] BGP TE attr last call by softwir<br>es<br>&gt; WG (2nd&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;question)&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Hi John,&lt;br&gt;&amp;<br>g<br>&gt; t;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;No, not really. When you add a PE you configure<br>&gt; &gt;&nbsp; local&lt;br&gt;&amp;gt;&amp;gt;interfaces, local&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;VPN port mappings, stuff<br> l<br>&gt; ike that. While doing this you will also &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;configure an IPinIP <br>tu<br>&gt; nnel to one of your spoke Ps and enable L1VPN &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;OSPF instance o<br>n <br>&gt; the tunnel.&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Once you did that the local VPN information will b<br>e <br>&gt;
 flooded&lt;br&gt;&amp;gt;&amp;gt;accross the&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;overlay, likewise, the new PE w<br>il<br>&gt; l get all the necessary information &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;from other PEs.&lt;br&gt;&amp;gt;&amp;g<br>t;<br>&gt; &amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Cheers,&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Igor&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;g<br>t;<br>&gt; &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;----- Original Message ----&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;From: "Drake, John<br> E<br>&gt; " &amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:John.E.Drake2<br>@b<br>&gt; oeing.com"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;To: Igor Bryskin &amp;<br>lt<br>&gt; ;&lt;a
 ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;i_<br>br<br>&gt; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; Yakov Rekhter &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;lt;&lt;a ymailto="mailto<br>:y<br>&gt; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"<br>&gt; &gt;&nbsp; href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; Lou Berger &amp;lt;<br>&lt;a<br>&gt; ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>"&gt;lberger@labn<br>.<br>&gt; net&lt;/a&gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Cc: Yakov Rekhter &amp;lt;&lt;a ymailto="mailto:yakov@jun<br>ip<br>&gt; er.net" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; Adrian Far<br>re<br>&gt; l &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:ad<br>ri<br>&gt; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; &lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a><br>tf<br>&gt; .org" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;; &lt;a ymailto="ma<br>il<br>&gt; to:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a<br>&gt;&lt;<br>&gt; br&gt;&amp;gt;&amp;gt;&amp;gt;Sent: Friday, August 29, 2008 11:20:16 AM&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Subje<br>ct<br>&gt; : RE: [Softwires] BGP TE attr last call by softwires WG (2nd&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;q<br>ue<br>&gt;
 stion)&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Igor,&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Do<br>es<br>&gt; n't this defeat auto-discovery?&amp;nbsp; I.e., how is a new PE &lt;br&gt;&amp;gt;added to <br>a <br>&gt; &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;given<br>&gt; &gt;&nbsp; L1VPN?&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Thanks,&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;<br>gt<br>&gt; ;John&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;-----Original Message-----&lt;br&gt;&amp;gt;&amp;g<br>t;<br>&gt; &amp;gt;&amp;gt;From: Igor Bryskin [mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" hr<br>ef<br>&gt; ="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;]&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Sen<br>t:<br>&gt; Friday, August 29, 2008 5:51 AM&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;To: Yakov Rekhter; Lou Ber<br>g<br>&gt; er&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Cc: Yakov Rekhter; Adrian Farrel; &lt;a ymailto="mailto:cc<br>am<br>&gt; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;; &lt;br&gt;<br>&amp;g<br>&gt; t;&amp;gt;&amp;gt;&amp;gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:softwires@i<br>et<br>&gt; f.org"&gt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Subject: Re: [Softwires] BGP<br> T<br>&gt; E attr last call by softwires WG (2nd&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;question)&lt;br&gt;&amp;gt;&amp;gt<br>;&amp;<br>&gt; gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Yakov,&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;You <br>sa<br>&gt; id:&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;... And while <br>on<br>&gt; the subject of<br>&gt; &gt;&nbsp; scaling, please keep in mind&lt;br&gt;&amp;gt;&amp;gt;that BGP&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;only s<br>to<br>&gt; res L1VPN routes on PEs that have sites of that VPN&lt;br&gt;&amp;gt;&amp;gt;connected&lt;br&gt;&amp;<br>gt<br>&gt; ;&amp;gt;&amp;gt;&amp;gt;to them, and on an RR if used, but *not* on any of the P
 &lt;br&gt;&amp;gt<br>;r<br>&gt; outers. In &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;contrast, rfc5252 (OSPF for L1VPN&lt;br&gt;&amp;gt;&amp;gt;&amp;<br>gt<br>&gt; ;&amp;gt;autodiscovery) results in storing *all VPN TE information &lt;br&gt;&amp;gt;for al<br>l <br>&gt; the&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;VPNs* on *all* the IGP nodes, both P and PE. So, clear<br>ly<br>&gt; BGP-based &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;approach scales better than OSPF-based approach<br>.<br>&gt; &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Yakov.&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt<br>;&amp;<br>&gt; gt;&amp;gt;This is not true in case of multi-instance OSPF: one can build an &lt;br&gt;<br>&amp;g<br>&gt; t;&amp;gt;&amp;gt;&amp;gt;overlay interconnecting PEs via one or small number of Ps&lt;br&gt;&amp;g<br>t;<br>&gt; &amp;gt;&amp;gt;using
 IPinIP&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;tunnels and run in this overlay an in<br>st<br>&gt; ance of OSPF specifically &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;designated for distribution of <br>L1<br>&gt; VPN information. In<br>&gt; &gt;&nbsp; this&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;case the OSPF&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;solution won't scale <br>an<br>&gt; y worse than the BGP approach. Note. &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;that rfc252&lt;br&gt;&amp;gt;&amp;gt;&amp;<br>gt<br>&gt; ;&amp;gt;never said that the instance of OSPF used for flooding of the L1VPN &lt;br&gt;<br>&amp;g<br>&gt; t;&amp;gt;&amp;gt;&amp;gt;information must be the same instance that is used for the&lt;br&gt;&amp;<br>gt<br>&gt; ;&amp;gt;&amp;gt;distribution&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;of IP-related LSAs.&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;<br>gt<br>&gt;
 ;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Regards,&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Igor&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;<br>&amp;g<br>&gt; t;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt<br>;&amp;<br>&gt; gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&lt;b<br>r&gt;<br>&gt; &amp;gt;&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;&lt;br&gt;&lt;br&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;br&gt;<br>&gt; &gt; <br>&gt; &gt;&nbsp; &nbsp; &nbsp;  &lt;/body&gt;&lt;/html&gt;<br>&gt; &gt; --0-1141253910-1220449648=:97601--<br>&gt; <br>&gt; <br>&gt; <br>&gt;&nbsp; &nbsp; &nbsp;  <br>&gt; --0-1852435290-1220452662=:19087<br>&gt; Content-Type: text/html; charset=us-ascii<br>&gt; <br>&gt;
 &lt;html&gt;&lt;head&gt;&lt;style type="text/css"&gt;&lt;!-- DIV {margin:0px;} --&gt;&lt;/style&gt;&lt;/head&gt;&lt;<br>body&gt;&lt;div style="font-family:times new roman, new york, times, serif;font-size:<br>12pt"&gt;&lt;div&gt;Yaokov,&lt;br&gt;&lt;br&gt;Please,&amp;nbsp; see in-line.&lt;br&gt;&lt;/div&gt;&lt;div style="font-<br>family: times new roman,new york,times,serif; font-size: 12pt;"&gt;&lt;br&gt;&lt;div style=<br>"font-family: arial,helvetica,sans-serif; font-size: 13px;"&gt;----- Original Mess<br>age ----&lt;br&gt;From: Yakov Rekhter &amp;lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&amp;gt;&lt;br&gt;To: Igor Bryskin &amp;<br>lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&amp;gt;&lt;br&gt;Cc: "Drake, John E" &amp;lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&amp;<br>gt;;
 Lou Berger &amp;lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&amp;gt;; Adrian Farrel &amp;lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&amp;gt;; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;br&gt;Sent: Wednesday, September 3, 2<br>008 9:55:49 AM&lt;br&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires W<br>G (2nd question) &lt;br&gt;&lt;br&gt;<br>&gt; Igor,&lt;br&gt;&lt;br&gt;&amp;gt; And I am not arguing that sufficient redundancy must be pro<br>vided. However you&lt;br&gt;&amp;gt; said:&lt;br&gt;&amp;gt; &amp;gt;For your suggested approach to wor<br>k with sufficient &lt;br&gt;&amp;gt; &amp;gt;redundancy, the topology of the overlay needs to<br> be configured &lt;br&gt;&amp;gt; &amp;gt;such
 that every selected P router is connected to a<br>t least two &lt;br&gt;&amp;gt; &amp;gt;other selected P routers and every PE router needs to <br>be &lt;br&gt;&amp;gt; &amp;gt;connected to at least two selected P routers.&lt;br&gt;&amp;gt; &lt;br&gt;&amp;gt; <br>If you just simply interconnect all VPN-aware PEs into a single&lt;br&gt;&amp;gt; ring vi<br>a IPin IP tunnels and run an instance of OSPF to distribute&lt;br&gt;&amp;gt; VPN-related<br> information between them, it will provide sufficient&lt;br&gt;&amp;gt; redundancy and in<br>volve exactly *zero* Ps.&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt; So, I want you to drop your lecturing <br>tone for a minute and simply&lt;br&gt;&amp;gt; tell in what respect in your opinion this <br>approach is not perfect&lt;br&gt;&amp;gt; fo the L1VPN application. Otherwise, I am not i<br>nterested in<br>&gt;&nbsp; this&lt;br&gt;&amp;gt; discussion any longer. I do like to hear comments from other
 pe<br>ople.&lt;br&gt;&lt;br&gt;Since you asked, one problem with using OSPF, as John correctly&lt;br<br>&gt;pointed out, is that you are left with a situation in which *every* PE &lt;br&gt;rou<br>ter will have *all* L1VPN routes for all the L1VPNs. Of course, &lt;br&gt;this is "pe<br>rfect" in a sense that you can do no worse than that :-)&lt;br&gt;&lt;br&gt;IB&amp;gt;&amp;gt; Ok. <br>Several points here. Note that neither Ps nor VPN-unaware PEs participate in th<br>e distribution/maintenance of VPN information, which is already significantly b<br>etter than what you said about the OSPF solution in your previous mail:&lt;br&gt;&lt;br&gt;<br>&amp;gt;... And while on the subject of scaling, please keep in mind that BGP&lt;br&gt;&amp;g<br>t;&amp;nbsp;&amp;nbsp; only stores L1VPN routes on PEs that have sites of that VPN&lt;br&gt;&amp;<br>gt;&amp;nbsp;&amp;nbsp; connected to them, and on an RR if used, but *not* on any of th<br>e P
 &lt;br&gt;&amp;gt;&amp;nbsp;&amp;nbsp; routers. In contrast, rfc5252 (OSPF for L1VPN&lt;br&gt;&amp;gt;&amp;<br>nbsp;&amp;nbsp;<br>&gt;&nbsp; autodiscovery) results in storing *all VPN TE information &lt;br&gt;&amp;gt;&amp;nbsp;&amp;nbs<br>p; for all the VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-bas<br>ed &lt;br&gt;&amp;gt;&amp;nbsp;&amp;nbsp; approach scales better than OSPF-based approach.&lt;br&gt;&lt;br<br>&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;Yakov.&lt;br&gt;&lt;br&gt;I do agree that if you use a single ring ov<br>erlay interconnecting all VPN aware PEs you will have LSDBs at all PEs contain <br>VPN info about all VPNs. However, in case of L1VPN this is not VPN routes, rath<br>er VPN Provider-To-Customer port mappings which I believe will prove to be sugn<br>ifficantly smaller, so I am not sure yet how bad is that. In any case, if it do<br>es present a problem on a network with large number of VPNs, who said that it h<br>as
 to be a single overlay? Why not to configure several overlays - each contain<br>ing a single ring that interconnects PEs participating in a common sub-set of V<br>PNs, and run a seperate instance of OSPF in each overlay?&lt;br&gt;&lt;br&gt;Igor&lt;br&gt;&lt;br&gt;&lt;b<br>r&gt;&amp;nbsp;&lt;br&gt;&amp;gt;<br>&gt;&nbsp; &lt;br&gt;&amp;gt; &lt;br&gt;&amp;gt; &lt;br&gt;&amp;gt; &lt;br&gt;&amp;gt; ----- Original Message ----&lt;br&gt;&amp;gt; From<br>: "Drake, John E" &amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto<br>:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;&lt;br&gt;&amp;gt; To: Igor Br<br>yskin &amp;lt;&lt;a ymailto="mailto:<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:i_bryskin@yahoo.<br>com"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; Yakov Rekhter &amp;lt;&lt;a ymailto="mailto:yakov@ju<br>niper.net" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; Lo&lt;br&gt;u B<br>erger &amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;l<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;&lt;br&gt;&amp;gt; Cc: Yakov Rekhter &amp;lt;&lt;a
 ymailto="mailto:yakov@<br>juniper.net" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; Adrian <br>Farrel &amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>o.uk"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; c&lt;br&gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" h<br>ref="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;; &lt;a ymailto="mailto:softwi<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"<br>&gt;&nbsp; href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&lt;br&gt;&amp;gt; Sent: Wednes<br>day, September 3, 2008 8:10:07 AM&lt;br&gt;&amp;gt; Subject: RE: [Softwires] BGP TE attr <br>last call by softwires WG (2nd question)&lt;br&gt;&amp;gt; &lt;br&gt;&amp;gt; Igor,&lt;br&gt;&amp;gt; &lt;br&gt;&amp;gt<br>; Actually, I am not sure that you do understand what I wrote, because you&lt;br&gt;&amp;<br>gt; are providing examples of the redundancy that I specified - every PE&lt;br&gt;&amp;gt<br>; router needs to have connectivity to two other routers in the IGP&lt;br&gt;&amp;gt; ins<br>tance.&lt;br&gt;&amp;gt;
 &lt;br&gt;&amp;gt; Thanks,&lt;br&gt;&amp;gt; &lt;br&gt;&amp;gt; John &lt;br&gt;&amp;gt; &lt;br&gt;&amp;gt; &amp;gt;---<br>--Original Message-----&lt;br&gt;&amp;gt; &amp;gt;From: Igor Bryskin [mailto:&lt;a ymailto="mail<br>to:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/<br>a&gt;] &lt;br&gt;&amp;gt; &amp;gt;Sent: Tuesday, September 02, 2008 3:06 PM&lt;br&gt;&amp;gt; &amp;gt;To: Drak<br>e, John E; Yakov Rekhter; Lou Berger&lt;br&gt;&amp;gt; &amp;gt;Cc: Yakov Rekhter; Adrian Farr<br>el; &lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>"&gt;cca<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;;<br>&gt;&nbsp; &lt;br&gt;&amp;gt; &amp;gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:softwires@i<br>etf.org"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&lt;br&gt;&amp;gt; &amp;gt;Subject: Re: [Softwires] BGP TE att<br>r last call by softwires WG &lt;br&gt;&amp;gt; &amp;gt;(2nd question)&lt;br&gt;&amp;gt; &amp;gt;&lt;br&gt;&amp;gt; &amp;g<br>t;Hi John,&lt;br&gt;&amp;gt; &amp;gt;&lt;br&gt;&amp;gt; &amp;gt;I understand what you are saying and disagr<br>ee. The overlay I &lt;br&gt;&amp;gt; &amp;gt;am talking about logically is a separate network<br> and as any &lt;br&gt;&amp;gt; &amp;gt;network it should be sufficiently redundant to functio<br>n.
 There &lt;br&gt;&amp;gt; &amp;gt;is a number of ways how you can address the redundancy &lt;b<br>r&gt;&amp;gt; &amp;gt;concerns. Look at the examples below:&lt;br&gt;&amp;gt; &amp;gt;&lt;br&gt;&amp;gt; &amp;gt;a) in<br>terconnect all VPN-aware PEs into a single ring: &lt;br&gt;&amp;gt; &amp;gt;PE=======PE&lt;br&gt;&amp;g<br>t; &amp;gt; ||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; ||&lt;br&gt;<br>&amp;gt; &amp;gt;PE&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; PE &lt;br&gt;&amp;gt; &amp;gt;||<br>&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; ||&lt;br&gt;&amp;gt; &amp;gt;<br>PE&amp;nbsp; &amp;nbsp; &amp;nbsp;<br>&gt;&nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; PE &lt;br&gt;&amp;gt; &amp;gt;||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;<br>nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;
 &amp;nbsp;&nbsp; ||&lt;br&gt;&amp;gt; &amp;gt;...&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp<br>; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; ....&lt;br&gt;&amp;gt; &amp;gt;PE=======PE&lt;br&gt;&amp;gt; &amp;gt;&lt;br&gt;&amp;gt;<br> &amp;gt;b) connect each PE to two interconnected Ps &lt;br&gt;&amp;gt; &amp;gt;&lt;br&gt;&amp;gt; &amp;gt;PE&amp;n<br>bsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; P&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;n<br>bsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; PE&lt;br&gt;&amp;gt; &amp;gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;n<br>bsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; ||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;n<br>bsp; &amp;nbsp; &amp;nbsp; &lt;br&gt;&amp;gt; &amp;gt;PE&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nb<br>sp;&nbsp; ||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;
 &amp;nbsp; &amp;nbsp; &amp;nbsp; PE &lt;br&gt;&amp;g<br>t; &amp;gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; ||<br>&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &lt;br&gt;&amp;gt; &amp;gt;PE&amp;<br>nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; ||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; <br>&amp;nbsp; &amp;nbsp; &amp;nbsp;<br>&gt;&nbsp; &amp;nbsp; &amp;nbsp; PE &lt;br&gt;&amp;gt; &amp;gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbs<br>p; &amp;nbsp; &amp;nbsp; &amp;nbsp; ||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbs<br>p; &amp;nbsp; &lt;br&gt;&amp;gt; &amp;gt;...&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbs<br>p;&nbsp; ||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;
 &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; ....&lt;br&gt;&amp;<br>gt; &amp;gt;PE&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; P&amp;nbsp; &amp;nbsp; &amp;nbs<br>p; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; PE&lt;br&gt;&amp;gt; &amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&lt;br&gt;&amp;gt; &amp;gt<br>;Note that tunnels can traverse any number of VPN-unaware Ps and PEs.&lt;br&gt;&amp;gt; &amp;<br>gt;&lt;br&gt;&amp;gt; &amp;gt;Igor&lt;br&gt;&amp;gt; &amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&lt;br&gt;&amp;gt; &amp;gt;----- Original Messa<br>ge ----&lt;br&gt;&amp;gt; &amp;gt;From: "Drake, John E" &amp;lt;&lt;a ymailto="mailto:John.E.Drake2@<br>boeing.com" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;<br>&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;To: Igor Bryskin &amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" h<br>ref="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; Yakov Rekhter &lt;br<br>&gt;&amp;gt; &amp;gt;&amp;lt;&lt;a<br>&gt;&nbsp; ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;yakov@jun<br>iper.net&lt;/a&gt;&amp;gt;; Lou Berger &amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"
 href="mai<br>lto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;Cc: Yakov Rekhter &amp;l<br>t;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;yakov@j<br>uniper.net&lt;/a&gt;&amp;gt;; Adrian Farrel &lt;br&gt;&amp;gt; &amp;gt;&amp;lt;&lt;a ymailto="mailto:adrian@ol<br>ddog.co.uk" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; &lt;a y<br>mailto="mailto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>etf.org&lt;/a&gt;; &lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:softwires@ietf<br>.org"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&lt;br&gt;&amp;gt; &amp;gt;Sent: Tuesday, September 2, 2008 2:24:<br>26 PM&lt;br&gt;&amp;gt; &amp;gt;Subject: RE: [Softwires] BGP TE attr last call by softwires W<br>G &lt;br&gt;&amp;gt; &amp;gt;(2nd question)&lt;br&gt;&amp;gt; &amp;gt;&lt;br&gt;&amp;gt; &amp;gt;Igor,&lt;br&gt;&amp;gt; &amp;gt;&lt;br&gt;&amp;g<br>t; &amp;gt;Several years ago when OSPF was first proposed as an &lt;br&gt;&amp;gt; &amp;gt;autodi<br>scovery mechanism
 for<br>&gt;&nbsp; L1VPNs, you were told that it was &lt;br&gt;&amp;gt; &amp;gt;a bad idea due to its scaling<br> properties and impact on the IGP.&lt;br&gt;&amp;gt; &amp;gt;&lt;br&gt;&amp;gt; &amp;gt;You are now tacitly<br> agreeing with those who told you it was a bad idea.&lt;br&gt;&amp;gt; &amp;gt;&lt;br&gt;&amp;gt; &amp;gt;F<br>or your suggested approach to work with sufficient &lt;br&gt;&amp;gt; &amp;gt;redundancy, the<br> topology of the overlay needs to be configured &lt;br&gt;&amp;gt; &amp;gt;such that every se<br>lected P router is connected to at least two &lt;br&gt;&amp;gt; &amp;gt;other selected P rout<br>ers and every PE router needs to be &lt;br&gt;&amp;gt; &amp;gt;connected to at least two sele<br>cted P routers.&lt;br&gt;&amp;gt; &amp;gt;&lt;br&gt;&amp;gt; &amp;gt;When you are done with this configurat<br>ion, you are left with a &lt;br&gt;&amp;gt; &amp;gt;situation in which *every* PE and selecte<br>d P router will have
 &lt;br&gt;&amp;gt; &amp;gt;*all* L1VPN routes.&lt;br&gt;&amp;gt; &amp;gt;&lt;br&gt;&amp;gt; &amp;gt;<br>Thanks,&lt;br&gt;&amp;gt; &amp;gt;&lt;br&gt;&amp;gt; &amp;gt;John &lt;br&gt;&amp;gt; &amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;-----Origin<br>al Message-----&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;From: Igor Bryskin [mailto:&lt;a ymailto="mailto:i<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"<br>&gt;&nbsp; href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;]&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;S<br>ent: Friday, August 29, 2008 12:10 PM&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;To: Drake, John E; Yakov <br>Rekhter; Lou Berger&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;Cc: Yakov Rekhter; Adrian Farrel; &lt;a ymailt<br>o="mailto:<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>rg&lt;/a&gt;; &lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:so<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;Subject: Re: [Softwire<br>s] BGP TE attr last call by softwires WG (2nd &lt;br&gt;&amp;gt; &amp;gt;&amp;gt;question)&lt;br&gt;&amp;gt<br>; &amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;Are you calling me silly? Are you coming to Minneapo<br>lis?
 :=)&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;Seriously, what is wrong in your opin<br>ion with this approach? &lt;br&gt;&amp;gt; &amp;gt;&amp;gt;Many people are talking about multi-in<br>stance IGPs. What they have in &lt;br&gt;&amp;gt; &amp;gt;&amp;gt;mind is improving the IGP scala<br>bility:&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;a) by removing non-IP advertisements from the instance <br>of IGP that &lt;br&gt;&amp;gt;<br>&gt;&nbsp; &amp;gt;&amp;gt;manages IP routing/forwarding tables into separate IGP instance(s);&lt;<br>br&gt;&amp;gt; &amp;gt;&amp;gt;b) by distributing non-IP information only to and via &lt;br&gt;&amp;gt; <br>&amp;gt;inerested parties &lt;br&gt;&amp;gt; &amp;gt;&amp;gt;leaving the bulk of Ps out of the proces<br>s.&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;In my opinion this is exactly what is neede<br>d for the OSPF-based L1VPN &lt;br&gt;&amp;gt;
 &amp;gt;&amp;gt;application.&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&lt;br&gt;&amp;g<br>t; &amp;gt;&amp;gt;Igor&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;<br>&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;----- Original Message -<br>---&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;From: "Drake, John E" &amp;lt;&lt;a ymailto="mailto:John.E.Drake2@<br>boeing.com" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;<br>&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;To: Igor Bryskin &amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>m" href="mailto:<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; Yakov Rekhter<br> &lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"<br>&gt;&nbsp; href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; Lou Berger &amp;lt;&lt;a<br> ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;lberger@labn.<br>net&lt;/a&gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;Cc: Yakov Rekhter
 &amp;lt;&lt;a ymailto="mailto:yakov@juni<br>per.net" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; Adrian Farr<br>el &lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:ad<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; &lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>tf.org" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;; &lt;a ymailto="ma<br>ilto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a<br>&gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;Sent: Friday, August 29, 2008 2:31:36 PM&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;Subj<br>ect: RE: [Softwires] BGP TE attr last call by softwires WG (2nd &lt;br&gt;&amp;gt; &amp;gt;&amp;g<br>t;question)&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;So you are proposing an OSPF route<br> reflector?&amp;nbsp; At what point does the &lt;br&gt;&amp;gt; &amp;gt;&amp;gt;silliness stop?&lt;br&gt;&amp;g<br>t; &amp;gt;&amp;gt;&lt;br&gt;&amp;gt;<br>&gt;&nbsp; &amp;gt;&amp;gt;&amp;gt;-----Original
 Message-----&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;From: Igor Bryski<br>n [mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:i_bryskin@yahoo.<br>com"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;]&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;Sent: Friday, August 29, 2008<br> 11:29 AM&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;To: Drake, John E; Yakov Rekhter; Lou Berger&lt;br&gt;&amp;<br>gt; &amp;gt;&amp;gt;&amp;gt;Cc: Yakov Rekhter; Adrian Farrel; &lt;a ymailto="mailto:ccamp@ops.<br>ietf.org" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;; &lt;br&gt;&amp;gt; &amp;gt<br>;&amp;gt;&amp;gt;&lt;a ymailto="mailto:<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;Subject: Re: [Softwires] BGP TE at<br>tr last call by softwires WG (2nd&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;question)&lt;br&gt;&amp;gt; &amp;gt;&amp;gt<br>;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;Hi John,&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;No,<br> not really. When you add a PE you configure local&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;interfaces, <br>local&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;VPN port mappings, stuff like that. While doing this <br>you will also &lt;br&gt;&amp;gt;<br>&gt;&nbsp; &amp;gt;&amp;gt;&amp;gt;configure an IPinIP
 tunnel to one of your spoke Ps and enable L1<br>VPN &lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;OSPF instance on the tunnel.&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;Once <br>you did that the local VPN information will be flooded&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;accross <br>the&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;overlay, likewise, the new PE will get all the necessar<br>y information &lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;from other PEs.&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;<br> &amp;gt;&amp;gt;&amp;gt;Cheers,&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;Igor&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;<br>&amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;----- Original Message ----&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;Fr<br>om: "Drake, John E" &amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>" href="mail<br>to:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;<br>gt;To: Igor Bryskin &amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:i_<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; Yakov Rekhter &lt;br&gt;&amp;gt; &amp;gt;&amp;gt;<br>&amp;gt;&amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"<br>&gt;&nbsp;
 href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; Lou Berger &amp;lt;&lt;a<br> ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;lberger@labn.<br>net&lt;/a&gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;Cc: Yakov Rekhter &amp;lt;&lt;a ymailto="mailto:yakov@<br>juniper.net" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; Adrian <br>Farrel &lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>" href="m<br>ailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; &lt;a ymailto="mailto:ccam<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;; &lt;a yma<br>ilto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;softwires@iet<br>f.org&lt;/a&gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;Sent: Friday, August 29, 2008
 11:20:16 AM&lt;br&gt;&amp;gt;<br> &amp;gt;&amp;gt;&amp;gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2n<br>d&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;question)&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;Igor,&lt;<br>br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;Doesn't this defeat auto-discovery?&amp;nb<br>sp; I.e., how is a new<br>&gt;&nbsp; PE &lt;br&gt;&amp;gt; &amp;gt;added to a &lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;given L1VPN?&lt;br&gt;&amp;gt; &amp;gt;&amp;gt<br>;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;Thanks,&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;John<br>&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;-----Original Message-----&lt;br&gt;&amp;gt<br>; &amp;gt;&amp;gt;&amp;gt;&amp;gt;From: Igor Bryskin [mailto:&lt;a
 ymailto="mailto:i_bryskin@yahoo<br>.com" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;]&lt;br&gt;&amp;gt; &amp;gt;&amp;g<br>t;&amp;gt;&amp;gt;Sent: Friday, August 29, 2008 5:51 AM&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;To: Yak<br>ov Rekhter; Lou Berger&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;Cc: Yakov Rekhter; Adrian Farrel<br>; &lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;ccamp<br>@ops.ietf.org&lt;/a&gt;; &lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>rg"
 href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt<br>;&amp;gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd&lt;br&gt;&amp;gt<br>; &amp;gt;&amp;gt;&amp;gt;&amp;gt;question)&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;Ya<br>kov,&lt;br&gt;&amp;gt;<br>&gt;&nbsp; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;You said:&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;<br>br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;... And while on the subject o<br>f scaling, please keep in mind&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;that BGP&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt<br>;only
 stores L1VPN routes on PEs that have sites of that VPN&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;co<br>nnected&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;to them, and on an RR if used, but *not* on any<br> of the P &lt;br&gt;&amp;gt; &amp;gt;routers. In &lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;contrast, rfc5252 (<br>OSPF for L1VPN&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;autodiscovery) results in storing *all V<br>PN TE information &lt;br&gt;&amp;gt; &amp;gt;for all the&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;VPNs* on *al<br>l* the IGP nodes, both P and PE. So, clearly BGP-based &lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt<br>;approach scales better than OSPF-based approach.&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;<br>gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;Yakov.&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;Thi<br>s is not true in case of
 multi-instance OSPF: one can build an &lt;br&gt;&amp;gt; &amp;gt;&amp;gt<br>;&amp;gt;&amp;gt;overlay<br>&gt;&nbsp; interconnecting PEs via one or small number of Ps&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;using <br>IPinIP&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;tunnels and run in this overlay an instance of O<br>SPF specifically &lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;designated for distribution of L1VPN <br>information. In this&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;case the OSPF&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;<br>solution won't scale any worse than the BGP approach. Note. &lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;g<br>t;that rfc252&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;never said that the instance of OSPF used<br> for flooding of the L1VPN &lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;information must be the sam<br>e instance that is used for the&lt;br&gt;&amp;gt;
 &amp;gt;&amp;gt;&amp;gt;distribution&lt;br&gt;&amp;gt; &amp;gt;&amp;g<br>t;&amp;gt;&amp;gt;of IP-related LSAs.&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;<br>Regards,&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;Igor&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;<br>&amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;<br>&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt<br>;&lt;br&gt;&amp;gt;<br>&gt;&nbsp; &amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&lt;br&gt;&amp;gt; &amp;gt;&lt;br&gt;&amp;gt; &amp;gt<br>;&lt;br&gt;&amp;gt; &lt;br&gt;&amp;gt; &lt;br&gt;&amp;gt;&amp;nbsp;
 &amp;nbsp; &amp;nbsp;&nbsp; &lt;br&gt;&amp;gt; --0-1141253910-122044<br>9648=:97601&lt;br&gt;&amp;gt; Content-Type: text/html; charset=us-ascii&lt;br&gt;&amp;gt; &lt;br&gt;&amp;gt; <br>&amp;lt;html&amp;gt;&amp;lt;head&amp;gt;&amp;lt;style type="text/css"&amp;gt;&amp;lt;!-- DIV {margin:0px;} <br>--&amp;gt;&amp;lt;/style&amp;gt;&amp;lt;/head&amp;gt;&amp;lt;&lt;br&gt;body&amp;gt;&amp;lt;div style="font-family:tim<br>es new roman, new york, times, serif;font-size:&lt;br&gt;12pt"&amp;gt;&amp;lt;div&amp;gt;And I am<br> not arguing that sufficient redundancy must be provided. Ho&lt;br&gt;wever you said:<br>&amp;lt;br&amp;gt;&amp;amp;gt;For your suggested approach to work with sufficient &amp;lt;br&amp;gt<br>;&lt;br&gt;&amp;amp;gt;redundancy, the topology of the overlay needs to be configured &amp;lt<br>;br&amp;gt;&amp;amp;gt;such&lt;br&gt; that every selected P router is connected to at least t<br>wo &amp;lt;br&amp;gt;&amp;amp;gt;other select&lt;br&gt;ed P
 routers and every PE router needs to <br>be &amp;lt;br&amp;gt;&amp;amp;gt;connected to at least two &lt;br&gt;selected P routers.&amp;lt;br&amp;gt<br>;&amp;lt;br&amp;gt;If you just<br>&gt;&nbsp; simply interconnect all VPN-aware PEs in&lt;br&gt;to a single ring via IPinIP tunn<br>els and run an instance of OSPF to distribute V&lt;br&gt;PN-related information betwe<br>en them, it will provide sufficient redundancy and &lt;br&gt;involve exactly *zero* P<br>s.&amp;lt;br&amp;gt;So, I want you to drop your lecturing tone for a &lt;br&gt;minute and sim<br>ply tell in what respect in your opinion this approach is not per&lt;br&gt;fect fo th<br>e L1VPN&lt;br&gt;&amp;gt;&amp;nbsp; application. Otherwise, I am not interested in this discu<br>ssion any longer. I&lt;br&gt; do like to hear comments from other people.&amp;lt;br&amp;gt;&amp;l<br>t;br&amp;gt;Igor &amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&amp;lt;/div&amp;gt;&amp;lt;div sty&lt;br&gt;le="font-family: ti<br>mes
 new roman,new york,times,serif; font-size: 12pt;"&amp;gt;&amp;lt;br&amp;gt;&amp;lt;d&lt;br&gt;iv <br>style="font-family: arial,helvetica,sans-serif; font-size: 13px;"&amp;gt;----- Orig<br>&lt;br&gt;inal Message ----&amp;lt;br&amp;gt;From: "Drake, John E" &amp;amp;lt;&lt;a ymailto="mailto<br>:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"<br>&gt;&nbsp; href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;amp;gt;&amp;<br>lt;br&amp;gt;&lt;br&gt;To: Igor Bryskin &amp;amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" h<br>ref="mailto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;amp;gt;; Yakov Rekhter<br> &amp;amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;yako<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&lt;br&gt;et&amp;amp;gt;; Lou Berger &amp;amp;lt;&lt;a ymailto="mailto:lberger@la<br>bn.net" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;amp;gt;&amp;lt;br&amp;gt;Cc<br>: Yakov Rekhter &amp;amp;lt;yakov@juni&lt;br&gt;per.net&amp;amp;gt;; Adrian Farrel &amp;amp;lt;&lt;a<br>
 ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;adrian@<br>olddog.co.uk&lt;/a&gt;&amp;amp;gt;; &lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:c<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;; sof&lt;br&gt;&lt;a ymailto="mailto:twires@iet<br>f.org" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;lt;br&amp;gt;Sent: Wednesd<br>ay, September 3, 2008 8:10:07 AM&amp;lt;br&amp;gt;Subject:
 RE&lt;br&gt;: [Softwires] BGP TE a<br>ttr last call by<br>&gt;&nbsp; softwires WG (2nd question)&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br&gt;&amp;gt; Igor,&amp;lt;br&amp;gt;&amp;lt;b<br>r&amp;gt;Actually, I am not sure that you do understand what I wrote, bec&lt;br&gt;ause y<br>ou&amp;lt;br&amp;gt;are providing examples of the redundancy that I specified - every P<br>&lt;br&gt;E&amp;lt;br&amp;gt;router needs to have connectivity to two other routers in the IG<br>P&amp;lt;br&amp;gt;insta&lt;br&gt;nce.&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;Thanks,&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;John &amp;lt<br>;br&amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;-----Original Message-----&amp;lt;br&amp;gt;&amp;amp;gt;F&lt;br&gt;rom: <br>Igor Bryskin [mailto:&amp;lt;a ymailto="mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>om" href="mailto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;" href="mailto:&lt;br<br>&gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;i_br<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;"&amp;gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:i_<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;lt;/a&amp;gt;] &amp;lt;br&amp;gt;&amp;amp;gt;Sent: T<br>uesday, September
 &lt;br&gt;02, 2008 3:06 PM&amp;lt;br&amp;gt;&amp;amp;gt;To: Drake, John E; Yako<br>v Rekhter; Lou<br>&gt;&nbsp; Berger&amp;lt;br&amp;gt;&amp;amp;gt;Cc:&lt;br&gt; Yakov Rekhter; Adrian Farrel; &amp;lt;a ymailto=<br>"mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"<br>&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;" href="mai&lt;br&gt;lto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;"&amp;gt;&lt;a ymailto="mailt<br>o:<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;l<br>t;/a&amp;gt;; &amp;lt;br&amp;gt;&amp;amp;gt;&amp;lt;a ymailto="mailto:soft&lt;br&gt;&lt;a ymailto="mailto:wi<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;" href="mailto:&lt;a <br>ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>"&gt;softwires@<br>ietf.org&lt;/a&gt;"&amp;gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:softwires@<br>ietf.org"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;lt;/a&amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&lt;br&gt;Subject: Re: [S<br>oftwires] BGP TE attr last call by softwires WG &amp;lt;br&amp;gt;&amp;amp;gt;(2nd que&lt;br&gt;s<br>tion)&amp;lt;br&amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;Hi John,&amp;lt;br&amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;a<br>mp;gt;I understand<br>&gt;&nbsp; what you are saying &lt;br&gt;and disagree. The&lt;br&gt;&amp;gt;&amp;nbsp; overlay I &amp;lt;br&amp;gt;<br>&amp;amp;gt;am talking about logically is a separate network and as an&lt;br&gt;y &amp;lt;br&amp;<br>gt;&amp;amp;gt;network it should be sufficiently
 redundant to function. There &amp;lt;b<br>r&amp;gt;&amp;amp;g&lt;br&gt;t;is a number of ways how you can address the redundancy &amp;lt;br&amp;<br>gt;&amp;amp;gt;concerns. Look&lt;br&gt; at the examples below:&amp;lt;br&amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt<br>;&amp;amp;gt;a) interconnect all VPN-aware PEs into a&lt;br&gt; single ring: &amp;lt;br&amp;gt;&amp;a<br>mp;gt;PE=======PE&amp;lt;br&amp;gt;&amp;amp;gt; ||&amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbs<br>p; &amp;amp;nbsp; &lt;br&gt;&amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; ||&amp;lt;br&amp;gt;&amp;amp;<br>gt;PE&amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbs&lt;br&gt;p; &amp;amp<br>;nbsp;&amp;nbsp; PE &amp;lt;br&amp;gt;&amp;amp;gt;||&amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp;<br> &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp;&lt;br&gt; &amp;amp;nbsp;&amp;nbsp;
 ||&amp;lt;br&amp;gt;&amp;<br>amp;gt;PE&amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp<br>;nbsp;&amp;nbsp; PE<br>&gt;&nbsp; &amp;lt;br&amp;gt;&amp;amp;&lt;br&gt;gt;||&amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbs<br>p; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp;&amp;nbsp; ||&amp;lt;br&amp;gt;&amp;amp;gt;&lt;br&gt;..<br>.&amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;<br>amp;nbsp; ....&amp;lt;br&amp;gt;&amp;amp;gt;PE======&lt;br&gt;=PE&amp;lt;br&amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp<br>;gt;b) connect each PE to two interconnected Ps &amp;lt;br&amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;am<br>p;gt;&lt;br&gt;PE&amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;a<br>mp;nbsp;&amp;nbsp; P&amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp&lt;br&gt;;
 &amp;amp;nbsp; &amp;amp<br>;nbsp; &amp;amp;nbsp;&lt;br&gt;&amp;gt;&amp;nbsp; &amp;amp;nbsp;&amp;nbsp; PE&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;nbsp;<br> &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;<br>amp;n&lt;br&gt;bsp; &amp;amp;nbsp; ||&amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbs<br>p; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp;&amp;nbsp; &amp;lt;&lt;br&gt;br&amp;gt;&amp;amp;gt;PE&amp;a<br>mp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp;&amp;nbsp<br>; ||&amp;amp;nbsp;<br>&gt;&nbsp; &amp;amp;nbsp; &amp;amp;nbs&lt;br&gt;p; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;n<br>bsp; &amp;amp;nbsp; PE &amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;n&lt;br<br>&gt;bsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp;
 &amp;amp;nbsp; ||&amp;amp;<br>nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;n&lt;br&gt;bsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;am<br>p;nbsp; &amp;amp;nbsp; &amp;lt;br&amp;gt;&amp;amp;gt;PE&amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nb<br>sp; &amp;amp;nbsp; &amp;amp;&lt;br&gt;nbsp; &amp;amp;nbsp;&amp;nbsp; ||&amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbs<br>p; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &lt;br&gt;PE &amp;lt<br>;br&amp;gt;&amp;amp;gt;&amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp<br>; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp&lt;br&gt;; ||&amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;<br>nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;lt;br&amp;<br>gt;&amp;amp;gt;...&amp;amp;&lt;br&gt;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;n<br>bsp;
 &amp;amp;nbsp; &amp;amp;nbsp;&amp;nbsp; ||&amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &lt;br&gt;&amp;amp;nb<br>sp; &amp;amp;nbsp;<br>&gt;&nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp;&amp;nbsp; ....&amp;lt;br&amp;gt;&amp;amp;gt;PE&amp;a<br>mp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;&lt;br&gt;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp;&amp;<br>nbsp; P&amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;nbsp; &amp;amp;n<br>bsp; &amp;amp;&lt;br&gt;nbsp; &lt;br&gt;&amp;gt;&amp;nbsp; PE&amp;lt;br&amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;lt;br<br>&amp;gt;&amp;amp;gt;Note that tunnels can traverse any number of VPN-u&lt;br&gt;naware Ps and<br> PEs.&amp;lt;br&amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;Igor&amp;lt;br&amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;g<br>t;&amp;lt;br&amp;gt;&amp;amp;gt;----- Original Me&lt;br&gt;ssage ----&amp;lt;br&amp;gt;&amp;amp;gt;From:
 "Dra<br>ke, John E" &amp;amp;lt;&amp;lt;a ymailto="mailto:John.E.Drake2@bo&lt;br&gt;&lt;a target="_blank<br>" href="<a href="http://eing.com" target="_blank">http://eing.com</a>"&gt;eing.com&lt;/a&gt;" href="mailto:&lt;a ymailto="mailto:John.E.D<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>om&lt;/a&gt;"&amp;gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:John.E.Dra<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;lt;/a&amp;gt;&amp;amp;g&lt;br&gt;t;&amp;lt;br&amp;gt;&amp;am<br>p;gt;To: Igor Bryskin<br>&gt;&nbsp; &amp;amp;lt;&amp;lt;a ymailto="mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="<br>mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;" href="ma&lt;br&gt;ilto:&lt;a ymailt<br>o="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;i_bryskin@yaho<br>o.com&lt;/a&gt;"&amp;gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>" href="mailto:i_bryskin@ya<br>hoo.com"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;lt;/a&amp;gt;&amp;amp;gt;; Yakov Rekhter &amp;lt;br&amp;gt;&amp;am<br>p;gt;&amp;amp;l&lt;br&gt;t;&amp;lt;a ymailto="mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" hr<br>ef="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;" href="mailto:&lt;a ymailto="m<br>ailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;"<br>&amp;gt;yakov@j&lt;br&gt;&lt;a target="_blank" href="<a href="http://uniper.net" target="_blank">http://uniper.net</a>"&gt;uniper.net&lt;/a&gt;&amp;lt;/a<br>&amp;gt;&amp;amp;gt;; Lou Berger &amp;amp;lt;&amp;lt;a ymailto="mailto:&lt;a ymailto="mailto:lberg<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;" href="m&lt;br&gt;ai<br>lto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;lberger<br>@labn.net&lt;/a&gt;"&amp;gt;&lt;a<br>&gt;&nbsp; ymailto="mailto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;lberger@lab<br>n.net&lt;/a&gt;&amp;lt;/a&amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;Cc: Yakov Rekhter &amp;amp;lt;&amp;lt;&lt;br&gt;<br>a ymailto="mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:yakov@juni<br>per.net"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;" href="mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>et" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;"&amp;gt;yakov@juni&lt;br&gt;&lt;a
 <br>target="_blank" href="<a href="http://per.net" target="_blank">http://per.net</a>"&gt;per.net&lt;/a&gt;&amp;lt;/a&amp;gt;&amp;amp;gt;; Adrian Far<br>rel &amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;lt;&amp;lt;a ymailto="mailto:&lt;a ymailto="mailto:adrian@o<br>lddog.co" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;.&lt;br&gt;uk" href="mai<br>lto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;a<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;"&amp;gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>" href="mailto<br>:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;lt;/a&amp;gt;&amp;amp;gt;; &amp;lt;a&lt;br&gt;&amp;gt;&amp;<br>nbsp; ymailto="mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"<br>&gt;&nbsp; href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;" href="mailto:&lt;a yma<br>ilto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>f.org&lt;/a&gt;"&amp;gt;ccamp@o&lt;br&gt;&lt;a target="_blank" href="<a href="http://ps.ietf.org" target="_blank">http://ps.ietf.org</a>"&gt;ps.ietf.o<br>rg&lt;/a&gt;&amp;lt;/a&amp;gt;; &amp;lt;a ymailto="mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" <br>href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;" href="mailto:softwires<br>@&lt;br&gt;&lt;a target="_blank" href="<a href="http://ietf.org" target="_blank">http://ietf.org</a>"&gt;ietf.org&lt;/a&gt;"&amp;gt;&lt;a ymailto="mai<br>lto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;<br>&amp;lt;/a&amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;Sent: Tuesday, September 2, 2008 2:24:2&lt;br&gt;6 PM&amp;lt;<br>br&amp;gt;&amp;amp;gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG &amp;l<br>t;br&amp;gt;&lt;br&gt;&amp;amp;gt;(2nd question)&amp;lt;br&amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;Igor,&amp;lt;<br>br&amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;Several years ago when O&lt;br&gt;SPF was first propo<br>sed as an &amp;lt;br&amp;gt;&amp;amp;gt;autodiscovery mechanism for L1VPNs, you we&lt;br&gt;re to<br>ld that it was<br>&gt;&nbsp; &amp;lt;br&amp;gt;&amp;amp;gt;a bad idea due to its scaling properties and impact&lt;br&gt; on<br> the
 IGP.&amp;lt;br&amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;You are now tacitly agreeing with <br>those who told yo&lt;br&gt;u it was a bad idea.&amp;lt;br&amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;Fo<br>r your suggested approach to work with su&lt;br&gt;fficient &amp;lt;br&amp;gt;&amp;amp;gt;redunda<br>ncy, the topology of the overlay needs to be configured&lt;br&gt; &amp;lt;br&amp;gt;&amp;amp;gt;s<br>uch that every selected P router is connected to at least two &amp;lt;br&amp;gt;&amp;amp;gt<br>&lt;br&gt;;other selected P routers and every PE router needs to be &amp;lt;br&amp;gt;&amp;amp;gt<br>;connected to &lt;br&gt;at least two selected&lt;br&gt;&amp;gt;&amp;nbsp; P routers.&amp;lt;br&amp;gt;&amp;amp;<br>gt;&amp;lt;br&amp;gt;&amp;amp;gt;When you are done with this configuration, you are&lt;br&gt; lef<br>t with a &amp;lt;br&amp;gt;&amp;amp;gt;situation in which *every* PE and selected P router <br>will h&lt;br&gt;ave
 &amp;lt;br&amp;gt;&amp;amp;gt;*all* L1VPN routes.&amp;lt;br&amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;<br>&amp;amp;gt;Thanks,&amp;lt;br&amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;John<br>&gt;&nbsp; &amp;lt;br&amp;gt;&lt;br&gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;-----Original Message-----&amp;l<br>t;br&amp;gt;&amp;amp;gt;&amp;amp;gt;From: Igor Bryskin [mailt&lt;br&gt;o:&amp;lt;a ymailto="mailto:&lt;a<br> ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;i_brysk<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;" href="mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="ma<br>ilto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;"&amp;gt;i_b&lt;br&gt;&lt;a ymailto="mailto<br>:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;lt;/a&amp;gt<br>;]&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;Sent: Friday, August 29, 2008 12:10 PM&amp;lt;br&amp;gt;&amp;am<br>p;gt;&lt;br&gt;&amp;amp;gt;To: Drake, John E; Yakov Rekhter; Lou Berger&amp;lt;br&amp;gt;&amp;amp;gt;<br>&amp;amp;gt;Cc: Yakov Rekhter; &lt;br&gt;Adrian Farrel; &amp;lt;a ymailto="mailto:&lt;a ymailto=<br>"mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&lt;/a&gt;" href="mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&lt;br&gt;&lt;a target="_blank" href="<a href="http://tf.org" target="_blank">http://tf.org</a>"&gt;tf.org&lt;/a&gt;"&amp;gt;&lt;a<br>&gt;&nbsp; ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;ccamp@o<br>ps.ietf.org&lt;/a&gt;&amp;lt;/a&amp;gt;;
 &amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;a ymailto="mailto:&lt;a y<br>mailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;softwires@ietf.<br>o&lt;/a&gt;&lt;br&gt;rg" href="mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:s<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;"&amp;gt;&lt;a ymailto="mailto:softwires@ietf<br>.org" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;lt;/a&amp;gt;&amp;lt;br&amp;g<br>t;&amp;amp;gt;&amp;amp;gt;Subject:&lt;br&gt; Re: [Softwires] BGP TE attr last call by softwir<br>es WG (2nd &amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;questio&lt;br&gt;n)&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt<br>;br&amp;gt;&amp;amp;gt;&amp;amp;gt;Are you calling me silly? Are you coming to Minneapol&lt;br<br>&gt;is?&lt;br&gt;&amp;gt;&amp;nbsp; :=)&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;Serio<br>usly, what is wrong in your opinion with thi&lt;br&gt;s approach? &amp;lt;br&amp;gt;&amp;amp;gt;&amp;<br>amp;gt;Many people are talking about multi-instance IGPs. What&lt;br&gt; they have in<br>&gt;&nbsp; &amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;mind is improving the IGP scalability:&amp;lt;br&amp;gt;&amp;a<br>mp;gt;&amp;amp;gt;a) &lt;br&gt;by removing non-IP advertisements from the instance of IGP<br> that
 &amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;man&lt;br&gt;ages IP routing/forwarding tables into s<br>eparate IGP instance(s);&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;b) &lt;br&gt;by distributing non-IP<br> information only to and via &amp;lt;br&amp;gt;&amp;amp;gt;inerested parties &amp;lt;b&lt;br&gt;r&amp;gt;<br>&amp;amp;gt;&amp;amp;gt;leaving the bulk of Ps out of the process.&amp;lt;br&amp;gt;&amp;amp;gt;&amp;am<br>p;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;In &lt;br&gt;my opinion this is exactly what is needed<br> for the OSPF-based L1VPN
 &amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&lt;br&gt;application.&amp;lt;br&amp;gt;&amp;<br>amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;Igor&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;g<br>t;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&lt;br&gt;&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;b<br>r&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;----- <br>Original Message ----&amp;lt;br&amp;gt;&amp;amp;gt&lt;br&gt;;&amp;amp;gt;From: "Drake, John E" &amp;amp;l<br>t;&amp;lt;a<br>&gt;&nbsp; ymailto="mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:Jo<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;" hre&lt;br&gt;f="mailto:&lt;a ymail<br>to="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;Joh<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;"&amp;gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href<br>="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;lt;/a&amp;gt;&amp;amp;g<br>t;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt&lt;br&gt;;To: Igor Bryskin&lt;br&gt;&amp;gt;&amp;nbsp; &amp;amp;lt;&amp;lt;a ym<br>ailto="mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:i_bryskin@ya<br>hoo.com"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;" href="mailto:&lt;a ymailto="mailto:i_bryskin@yah<br>oo.com" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&lt;br&gt;"&amp;gt;&lt;a ym<br>ailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;i_bryskin@<br>yahoo.com&lt;/a&gt;&amp;lt;/a&amp;gt;&amp;amp;gt;; Yakov Rekhter &amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;l<br>t;&amp;lt;a ymailto="mailto&lt;br&gt;:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"<br>&gt;&nbsp; href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;" href="mailto:&lt;a ymail<br>to="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a><br>&lt;/a&gt;"&amp;gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;lt;/a&amp;gt;&amp;amp;gt;; &lt;br&gt;Lou Berger &amp;amp;lt;&amp;lt;a ymailto="<br>mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;lber<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;" href="mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<br><a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&lt;br&gt;et"&amp;gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>t" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;lt;/a&amp;gt;&amp;amp;gt;&amp;lt;br&amp;<br>gt;&amp;amp;gt;&amp;amp;gt;Cc: Yakov Rekhter &amp;amp;lt;&amp;lt;a ymailto="mailt&lt;br&gt;o:&lt;a ymail<br>to="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a><br>&lt;/a&gt;" href="mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:yakov@jun<br>iper.net"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;"&amp;gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"<br>&gt;&nbsp; href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;lt;/a&amp;gt;&amp;amp;gt;;&lt;br&gt;<br> Adrian Farrel &amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;lt;&amp;lt;a ymailto="mailto:&lt;a ymail<br>to="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;adrian@olddog<br>.co.uk&lt;/a&gt;" href="ma&lt;br&gt;ilto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mail<br>to:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;"&amp;gt;&lt;a ymailto="mailto:adrian@o<br>lddog.co.uk" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;lt;/a&amp;gt<br>;&amp;amp;gt;; &amp;lt;a ymailto="mailto:ccamp&lt;br&gt;@ops.ietf.org" href="mailto:&lt;a ymailt<br>o="mailto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>rg&lt;/a&gt;"&amp;gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>rg"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;lt;/a&amp;gt;; &amp;lt;a ymai&lt;br&gt;lto="mailto:&lt;a ymailto="mai<br>lto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;<br>" href="mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"<br>&gt;&nbsp; href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;"&amp;gt;softwires@ietf&lt;b<br>r&gt;.org&amp;lt;/a&amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;Sent: Friday, August 29, 2008 2:31:36<br> PM&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;Subject&lt;br&gt;: RE: [Softwires] BGP TE attr last call<br> by softwires WG (2nd&lt;br&gt;&amp;gt;&amp;nbsp; &amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;question)&amp;lt;br&amp;g<br>t;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;So you are proposing an OSPF ro&lt;br&gt;<br>ute reflector?&amp;amp;nbsp; At what point does the
 &amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;silli<br>ness stop?&amp;lt;br&amp;gt;&amp;amp;gt;&lt;br&gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;-----<br>Original Message-----&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;From: Igor Bryski&lt;br&gt;n [<br>mailto:&amp;lt;a ymailto="mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mail<br>to:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;" href="mailto:i_bryskin@yahoo.&lt;<br>br&gt;com"&amp;gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:i_bryskin@yahoo<br>.com"&gt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;lt;/a&amp;gt;]&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;Sent:<br> Friday, August 29,<br>&gt;&nbsp; 2008 11:2&lt;br&gt;9 AM&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;To: Drake, John E; Yakov <br>Rekhter; Lou Berger&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt&lt;br&gt;;Cc: Yakov Rekhter; Adr<br>ian Farrel; &amp;lt;a ymailto="mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="<br>mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;" href=&lt;br&gt;"mailto:&lt;a ymailto=<br>"mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&lt;/a&gt;"&amp;gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;lt;/a&amp;gt;; &amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;a yma<br>ilto=&lt;br&gt;"mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:softwires@<br>ietf.org"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;" href="mailto:&lt;a
 ymailto="mailto:softwires@iet<br>f.org" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;"&amp;gt;&lt;a ymailto="<br>mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;<br>/a&gt;&lt;br&gt;&amp;lt;/a&amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;Subject: Re: [Softwires] BGP<br> TE attr last call by<br>&gt;&nbsp; softwires&lt;br&gt; WG (2nd&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;question)&amp;lt;br&amp;gt;&amp;a<br>mp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;Hi
 John,&amp;lt;br&amp;gt;&amp;amp;<br>g&lt;br&gt;t;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;No, not really. When y<br>ou add a PE you configure&lt;br&gt;&amp;gt;&amp;nbsp; local&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;interfac<br>es, local&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;VPN port mappings, stuff l&lt;br&gt;ike th<br>at. While doing this you will also &amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;configure <br>an IPinIP tu&lt;br&gt;nnel to one of your spoke Ps and enable L1VPN &amp;lt;br&amp;gt;&amp;amp;gt<br>;&amp;amp;gt;&amp;amp;gt;OSPF instance on &lt;br&gt;the tunnel.&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp<br>;gt;Once you did that the local VPN information will be &lt;br&gt;flooded&amp;lt;br&amp;gt;&amp;a<br>mp;gt;&amp;amp;gt;accross the&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;overlay, likewise, t<br>he new PE wil&lt;br&gt;l get all the necessary information
 &amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;<br>&amp;amp;gt;from other<br>&gt;&nbsp; PEs.&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&lt;br&gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;<br>Cheers,&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;Igor&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;<br>&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&lt;br&gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;----- O<br>riginal Message ----&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;From: "Drake, John E&lt;br&gt;"<br> &amp;amp;lt;&amp;lt;a ymailto="mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" hre<br>f="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;" href="mailto:<br>John.E.Drake2@b&lt;br&gt;&lt;a target="_blank" href="<a href="http://oeing.com" target="_blank">http://oeing.com</a>"&gt;oeing.com&lt;/a&gt;"&amp;gt<br>;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:John.E.Drake2@boeing<br>.com"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;lt;/a&amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;<br>amp;gt;To: Igor Bryskin &amp;amp;lt&lt;br&gt;;&amp;lt;a ymailto="mailto:&lt;a ymailto="mailto:i_<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;" h<br>ref="mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"<br>&gt;&nbsp; href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;"&amp;gt;i_br&lt;br&gt;&lt;a yma<br>ilto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;<br>&amp;lt;/a&amp;gt;&amp;amp;gt;; Yakov Rekhter &amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;lt;&amp;lt<br>;a
 ymailto="mailto:y&lt;br&gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:akov@<br>juniper.net"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;"&lt;br&gt;&amp;gt;&amp;nbsp; href="mailto:&lt;a ymailto="mailt<br>o:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;"&amp;gt;<br>&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;yakov@jun<br>iper.net&lt;/a&gt;&amp;lt;/a&amp;gt;&amp;amp;gt;; Lou Berger
 &amp;amp;lt;&amp;lt;a&lt;br&gt; ymailto="mailto:&lt;a<br> ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;lberger@labn.<br>net&lt;/a&gt;" href="mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:lberger<br>@labn.net"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;"&amp;gt;lberger@labn.&lt;br&gt;net&amp;lt;/a&amp;gt;&amp;amp;gt;&amp;lt;b<br>r&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;Cc: Yakov Rekhter &amp;amp;lt;&amp;lt;a ymailto="mailto:ya<br>kov@junip&lt;br&gt;&lt;a<br>&gt;&nbsp; target="_blank" href="<a href="http://er.net" target="_blank">http://er.net</a>"&gt;er.net&lt;/a&gt;" href="mailto:&lt;a ymailto="ma<br>ilto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;"&amp;<br>gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;yakov@<br>juniper.net&lt;/a&gt;&amp;lt;/a&amp;gt;&amp;amp;gt;; Adrian Farre&lt;br&gt;l &amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;<br>&amp;amp;gt;&amp;amp;lt;&amp;lt;a ymailto="mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" h<br>ref="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;" href="mailto:adri&lt;br&gt;<br>&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>.<br>uk&lt;/a&gt;"&amp;gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>o.uk"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;lt;/a&amp;gt;&amp;amp;gt;; &amp;lt;a ymailto="mailto:&lt;a ymail<br>to="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&lt;br&gt;.<br>org" href="mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:ccamp@ops<br>.ietf.org"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;"&amp;gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"<br>&gt;&nbsp; href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;lt;/a&amp;gt;; &amp;lt;a yma<br>ilto="mail&lt;br&gt;to:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>" href="mailto:softwires@<br>ietf.org"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;" href="mailto:&lt;a ymailto="mailto:softwires@iet<br>f.org" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;"&amp;gt;&lt;a ymailto="<br>mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;<br>/a&gt;&amp;lt;/a&amp;gt;&amp;lt;&lt;br&gt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;Sent: Friday, August 29, 200<br>8 11:20:16
 AM&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;Subject&lt;br&gt;: RE: [Softwires] BGP<br> TE attr last call by softwires WG (2nd&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;que&lt;br<br>&gt;stion)&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;Igor<br>,&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;Does&lt;br&gt;n'<br>t this defeat auto-discovery?&amp;amp;nbsp; I.e., how is a new PE &amp;lt;br&amp;gt;&amp;amp;gt<br>;added to a &lt;br&gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;given&lt;br&gt;&amp;gt;&amp;nbsp;<br>&gt;&nbsp;
 L1VPN?&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;Th<br>anks,&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt&lt;br&gt;;Jo<br>hn&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;-<br>----Original Message-----&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&lt;br&gt;&amp;amp;gt;&amp;amp;gt;From: Ig<br>or Bryskin [mailto:&amp;lt;a ymailto="mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;" href&lt;br&gt;="mailto:&lt;<br>a ymailto="mailto:<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;i_brys<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;"&amp;gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:i_br<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;lt;/a&amp;gt;]&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;a<br>mp;gt;&amp;amp;gt;Sent:&lt;br&gt; Friday, August 29, 2008 5:51 AM&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;g<br>t;&amp;amp;gt;&amp;amp;gt;To: Yakov Rekhter; Lou
 Berg&lt;br&gt;er&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;a<br>mp;gt;&amp;amp;gt;Cc: Yakov Rekhter; Adrian Farrel; &amp;lt;a ymailto="mailto:ccam&lt;br&gt;&lt;<br>a<br>&gt;&nbsp; ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;<br>/a&gt;" href="mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:ccamp@ops<br>.ietf.org"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;"&amp;gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" hr<br>ef="mailto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;lt;/a&amp;gt;; &amp;lt;br&amp;gt;&amp;amp<br>;g&lt;br&gt;t;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;a ymailto="mailto:&lt;a ymailto="mailto:softwi<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;" href="ma<br>ilto:softwires@iet&lt;br&gt;&lt;a target="_blank" href="<a href="http://f.org" target="_blank">http://f.org</a>"&gt;f.org&lt;/a&gt;"&amp;gt;&lt;a y<br>mailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>"&gt;softwires@i<br>etf.org&lt;/a&gt;&amp;lt;/a&amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;Subject: Re: [So<br>ftwires] BGP T&lt;br&gt;E attr last call by softwires WG<br>&gt;&nbsp; (2nd&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;question)&amp;lt;br&amp;gt;&amp;amp;gt;&amp;am<br>p;gt;&amp;amp;&lt;br&gt;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;Yakov,&amp;lt;br<br>&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;Y<br>ou sa&lt;br&gt;id:&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt<br>;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;... And while on&lt;br&gt;<br> the subject of&lt;br&gt;&amp;gt;&amp;nbsp; scaling, please keep in
 mind&amp;lt;br&amp;gt;&amp;amp;gt;&amp;am<br>p;gt;that BGP&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;only sto&lt;br&gt;res L1VPN ro<br>utes on PEs that have sites of that VPN&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;connected&amp;lt;b<br>r&amp;gt;&amp;amp;gt&lt;br&gt;;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;to them, and on an RR if used, but *no<br>t* on any of the P &amp;lt;br&amp;gt;&amp;amp;gt;r&lt;br&gt;outers. In &amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;<br>&amp;amp;gt;&amp;amp;gt;contrast, rfc5252 (OSPF for L1VPN&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp<br>;gt&lt;br&gt;;&amp;amp;gt;autodiscovery) results in storing *all VPN TE information &amp;lt;b<br>r&amp;gt;&amp;amp;gt;for all<br>&gt;&nbsp; &lt;br&gt;the&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;VPNs* on *all* the IGP node<br>s, both P and PE. So, clearly&lt;br&gt; BGP-based
 &amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;<br>amp;gt;approach scales better than OSPF-based approach.&lt;br&gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;a<br>mp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;Yakov.&amp;lt;br&amp;gt<br>;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;&lt;br&gt;gt;&amp;amp;gt;<br>This is not true in case of multi-instance OSPF: one can build an &amp;lt;br&amp;gt;&amp;am<br>p;g&lt;br&gt;t;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;overlay interconnecting PEs via one or small n<br>umber of Ps&amp;lt;br&amp;gt;&amp;amp;gt;&lt;br&gt;&amp;amp;gt;&amp;amp;gt;using IPinIP&amp;lt;br&amp;gt;&amp;amp;gt;<br>&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;tunnels and run in this overlay an inst&lt;br&gt;ance of OSPF<br> specifically &amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;designated for distribu<br>tion of
 L1&lt;br&gt;VPN information. In&lt;br&gt;&amp;gt;&amp;nbsp; this&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;<br>amp;gt;case the OSPF&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;solution won't sc<br>ale an&lt;br&gt;y worse than<br>&gt;&nbsp; the BGP approach. Note. &amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;that rfc252&amp;lt;br&amp;<br>gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt&lt;br&gt;;&amp;amp;gt;never said that the instance of OSPF use<br>d for flooding of the L1VPN &amp;lt;br&amp;gt;&amp;amp;g&lt;br&gt;t;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;infor<br>mation must be the same instance that is used for the&amp;lt;br&amp;gt;&amp;amp;gt&lt;br&gt;;&amp;amp<br>;gt;&amp;amp;gt;distribution&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;of IP-related<br>&gt;&nbsp;
 LSAs.&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt&lt;br&gt;;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt<br>;&amp;amp;gt;&amp;amp;gt;Regards,&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;Igor&amp;lt;br&amp;g<br>t;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;g&lt;br&gt;t;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt<br>;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;a<br>mp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;&lt;br&gt;gt;&amp;amp;gt;&amp;<br>lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;a<br>mp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&lt;br<br>&gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt
;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;amp;gt;&amp;lt;br&amp;gt;&amp;lt;br<br>&amp;gt;&amp;lt;/div&amp;gt;&amp;lt;/div&amp;gt;&amp;lt;/div&amp;gt;&amp;lt;br&amp;gt;&lt;br&gt;&amp;gt; &lt;br&gt;&amp;gt;&amp;nbsp; &amp;nbsp<br>; &amp;nbsp;&nbsp; &amp;lt;/body&amp;gt;&amp;lt;/html&amp;gt;&lt;br&gt;&amp;gt; --0-1141253910-1220449648=:97601--<br>&lt;br&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;br&gt;<br>&gt; <br>&gt; <br>&gt; <br>&gt;&nbsp; &nbsp; &nbsp;  &lt;/body&gt;&lt;/html&gt;<br>&gt; --0-1852435290-1220452662=:19087--<br>&gt; <br></div></div></div><br>

      </body></html>
--0-1935299916-1220456544=:20196--

Delivery-date: Wed, 03 Sep 2008 15:34:07 +0000
To: Lou Berger <[email-masked]>
cc: Adrian Farrel <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) 
Date: Wed, 03 Sep 2008 08:18:21 -0700
From: Yakov Rekhter <[email-masked]>

Lou,

> At 05:30 PM 9/2/2008, Yakov Rekhter wrote:
> 
> >Here is the text I'll add to the spec to discuss this issue:
> >
> >      Use of Traffic Engineering Attribute does not increase the number
> >      of routes.
> >
> >      When the routes differ in other than the Traffic Engineering
> >      Attribute (e.g., differ in the set of Route Targets, and/or
> >      NEXT_HOP), use of Traffic Engineering Attribute has no impact
> >      on the number of BGP Update messages required to carry the routes.
> >      Only when the routes have all, but the Traffic Engineering
> >      Attribute the same, use of the attribute may increase the number
> >      of BGP Update messages required to carry the routes.
> >
> >Yakov.
> 
> Is this from babel fish?  How about:
> 
> Use of Traffic Engineering Attribute does not increase the number
> of routes, but may increase the number of BGP Update messages
> required to distribute the routes.
> 
> When the routes differ in other than the Traffic Engineering
> Attribute (e.g., differ in the set of Route Targets, and/or
> NEXT_HOP), use of Traffic Engineering Attribute has no impact
> on the number of BGP Update messages required to carry the routes.
> There is also no impact when routes share all other attribute
> information and have an aggregated or identical Traffic Engineering Attribute
.
> When routes share all other attribute information and have different
> Traffic Engineering Attributes, routes must be distributed in
> per-route BGP Update messages rather than a single message.

Almost there... The only change is to the first paragraph,
as follows:

   Use of Traffic Engineering Attribute does not increase the number 
   of routes, but may increase the number of BGP Update messages 
   required to distribute the routes depending on whether these routes 
   share the same BGP Traffic Engineering attribute or not (see below).

The second paragraph is fine.

Yakov.

Delivery-date: Wed, 03 Sep 2008 15:19:08 +0000
To: Igor Bryskin <[email-masked]>
cc: "Drake, John E" <[email-masked]>, Lou Berger <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) 
Date: Wed, 03 Sep 2008 08:13:04 -0700
From: Yakov Rekhter <[email-masked]>

Igor,

> Yakov,
> Please,  see in-line.

see in-line...

> ----- Original Message ----
> From: Yakov Rekhter <[email-masked]>
> To: Igor Bryskin <[email-masked]>
> Cc: "Drake, John E" <[email-masked]>; Lou Berger <[email-masked]>
; Adrian Farrel <[email-masked]>; [email-masked]; [email-masked]
> Sent: Wednesday, September 3, 2008 9:55:49 AM
> Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)
 
> 
> Igor,
> 
> > And I am not arguing that sufficient redundancy must be provided. However 
> > you said:
> > >For your suggested approach to work with sufficient 
> > >redundancy, the topology of the overlay needs to be configured 
> > >such that every selected P router is connected to at least two 
> > >other selected P routers and every PE router needs to be 
> > >connected to at least two selected P routers.
> > 
> > If you just simply interconnect all VPN-aware PEs into a single
> > ring via IPin IP tunnels and run an instance of OSPF to distribute
> > VPN-related information between them, it will provide sufficient
> > redundancy and involve exactly *zero* Ps.
> >
> > So, I want you to drop your lecturing tone for a minute and simply
> > tell in what respect in your opinion this approach is not perfect
> > fo the L1VPN application. Otherwise, I am not interested in this
> > discussion any longer. I do like to hear comments from other people.
> 
> Since you asked, one problem with using OSPF, as John correctly
> pointed out, is that you are left with a situation in which *every* PE 
> router will have *all* L1VPN routes for all the L1VPNs. Of course, 
> this is "perfect" in a sense that you can do no worse than that :-)
> 
> IB>> Ok. Several points here. Note that neither Ps nor VPN-unaware PEs 
> IB>> participate in the distribution/maintenance of VPN information, 
> IB>> which is already significantly better than what you said about 
> IB>> the OSPF solution in your previous mail:
> 
> >... And while on the subject of scaling, please keep in mind that BGP
> >   only stores L1VPN routes on PEs that have sites of that VPN
> >   connected to them, and on an RR if used, but *not* on any of the P 
> >   routers. In contrast, rfc5252 (OSPF for L1VPN
> >   autodiscovery) results in storing *all VPN TE information 
> >   for all the VPNs* on *all* the IGP nodes, both P and PE. So, clearly 
> >
> >   BGP-based approach scales better than OSPF-based approach.
> > >>>>Yakov.
> 
> I do agree that if you use a single ring overlay interconnecting
> all VPN aware PEs you will have LSDBs at all PEs contain VPN info
> about all VPNs. However, in case of L1VPN this is not VPN routes,
> rather VPN Provider-To-Customer port mappings which I believe will
> prove to be significantly smaller, so I am not sure yet how bad
> is that. In any case, if it does present a problem on a network
> with large number of VPNs, who said that it has to be a single
> overlay? Why not to configure several overlays - each containing a
> single ring that interconnects PEs participating in a common sub-set
> of VPNs, and run a seperate instance o f OSPF in each overlay?

Sure. And this would be a good illustration of the fact that the
whole idea of using OSPF for L1VPN auto-discovery falls into the
paradigm of inherently flawed designs whose weakness can be solved
only by the usage of elaborate features, that, in turn, introduce 
a new set of problems.

Yakov.

> > 
> > 
> > 
> > 
> > ----- Original Message ----
> > From: "Drake, John E" <[email-masked]>
> > To: Igor Bryskin <[email-masked]>; Yakov Rekhter <[email-masked]>; 
Lo
> u Berger <[email-masked]>
> > Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel <[email-masked]>;
 c
> [email-masked]; [email-masked]
> > Sent: Wednesday, September 3, 2008 8:10:07 AM
> > Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd questio
n)
> > 
> > Igor,
> > 
> > Actually, I am not sure that you do understand what I wrote, because you
> > are providing examples of the redundancy that I specified - every PE
> > router needs to have connectivity to two other routers in the IGP
> > instance.
> > 
> > Thanks,
> > 
> > John 
> > 
> > >-----Original Message-----
> > >From: Igor Bryskin [mailto:[email-masked]] 
> > >Sent: Tuesday, September 02, 2008 3:06 PM
> > >To: Drake, John E; Yakov Rekhter; Lou Berger
> > >Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
> > >[email-masked]
> > >Subject: Re: [Softwires] BGP TE attr last call by softwires WG 
> > >(2nd question)
> > >
> > >Hi John,
> > >
> > >I understand what you are saying and disagree. The overlay I 
> > >am talking about logically is a separate network and as any 
> > >network it should be sufficiently redundant to function. There 
> > >is a number of ways how you can address the redundancy 
> > >concerns. Look at the examples below:
> > >
> > >a) interconnect all VPN-aware PEs into a single ring: 
> > >PE=======PE
> > > ||                  ||
> > >PE               PE 
> > >||                   ||
> > >PE               PE 
> > >||                   ||
> > >...                ....
> > >PE=======PE
> > >
> > >b) connect each PE to two interconnected Ps 
> > >
> > >PE               P                 PE
> > >                    ||                  
> > >PE               ||                  PE 
> > >                    ||                  
> > >PE               ||                  PE 
> > >                    ||                  
> > >...                 ||                   ....
> > >PE               P                 PE
> > >
> > >
> > >Note that tunnels can traverse any number of VPN-unaware Ps and PEs.
> > >
> > >Igor
> > >
> > >
> > >----- Original Message ----
> > >From: "Drake, John E" <[email-masked]>
> > >To: Igor Bryskin <[email-masked]>; Yakov Rekhter 
> > ><[email-masked]>; Lou Berger <[email-masked]>
> > >Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel 
> > ><[email-masked]>; [email-masked]; [email-masked]
> > >Sent: Tuesday, September 2, 2008 2:24:26 PM
> > >Subject: RE: [Softwires] BGP TE attr last call by softwires WG 
> > >(2nd question)
> > >
> > >Igor,
> > >
> > >Several years ago when OSPF was first proposed as an 
> > >autodiscovery mechanism for L1VPNs, you were told that it was 
> > >a bad idea due to its scaling properties and impact on the IGP.
> > >
> > >You are now tacitly agreeing with those who told you it was a bad idea.
> > >
> > >For your suggested approach to work with sufficient 
> > >redundancy, the topology of the overlay needs to be configured 
> > >such that every selected P router is connected to at least two 
> > >other selected P routers and every PE router needs to be 
> > >connected to at least two selected P routers.
> > >
> > >When you are done with this configuration, you are left with a 
> > >situation in which *every* PE and selected P router will have 
> > >*all* L1VPN routes.
> > >
> > >Thanks,
> > >
> > >John 
> > >
> > >>-----Original Message-----
> > >>From: Igor Bryskin [mailto:[email-masked]]
> > >>Sent: Friday, August 29, 2008 12:10 PM
> > >>To: Drake, John E; Yakov Rekhter; Lou Berger
> > >>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
> > >>[email-masked]
> > >>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd 
> > >>question)
> > >>
> > >>Are you calling me silly? Are you coming to Minneapolis? :=)
> > >>
> > >>Seriously, what is wrong in your opinion with this approach? 
> > >>Many people are talking about multi-instance IGPs. What they have in 
> > >>mind is improving the IGP scalability:
> > >>a) by removing non-IP advertisements from the instance of IGP that 
> > >>manages IP routing/forwarding tables into separate IGP instance(s);
> > >>b) by distributing non-IP information only to and via 
> > >inerested parties 
> > >>leaving the bulk of Ps out of the process.
> > >>
> > >>In my opinion this is exactly what is needed for the OSPF-based L1VPN 
> > >>application.
> > >>
> > >>Igor
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>----- Original Message ----
> > >>From: "Drake, John E" <[email-masked]>
> > >>To: Igor Bryskin <[email-masked]>; Yakov Rekhter 
> > >><[email-masked]>; Lou Berger <[email-masked]>
> > >>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel 
> > >><[email-masked]>; [email-masked]; [email-masked]
> > >>Sent: Friday, August 29, 2008 2:31:36 PM
> > >>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd 
> > >>question)
> > >>
> > >>So you are proposing an OSPF route reflector?  At what point does the 
> > >>silliness stop?
> > >>
> > >>>-----Original Message-----
> > >>>From: Igor Bryskin [mailto:[email-masked]]
> > >>>Sent: Friday, August 29, 2008 11:29 AM
> > >>>To: Drake, John E; Yakov Rekhter; Lou Berger
> > >>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
> > >>>[email-masked]
> > >>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
> > >>>question)
> > >>>
> > >>>Hi John,
> > >>>
> > >>>No, not really. When you add a PE you configure local
> > >>interfaces, local
> > >>>VPN port mappings, stuff like that. While doing this you will also 
> > >>>configure an IPinIP tunnel to one of your spoke Ps and enable L1VPN 
> > >>>OSPF instance on the tunnel.
> > >>>Once you did that the local VPN information will be flooded
> > >>accross the
> > >>>overlay, likewise, the new PE will get all the necessary information 
> > >>>from other PEs.
> > >>>
> > >>>Cheers,
> > >>>Igor
> > >>>
> > >>>
> > >>>----- Original Message ----
> > >>>From: "Drake, John E" <[email-masked]>
> > >>>To: Igor Bryskin <[email-masked]>; Yakov Rekhter 
> > >>><[email-masked]>; Lou Berger <[email-masked]>
> > >>>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel 
> > >>><[email-masked]>; [email-masked]; [email-masked]
> > >>>Sent: Friday, August 29, 2008 11:20:16 AM
> > >>>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd
> > >>>question)
> > >>>
> > >>>Igor,
> > >>>
> > >>>Doesn't this defeat auto-discovery?  I.e., how is a new PE 
> > >added to a 
> > >>>given L1VPN?
> > >>>
> > >>>Thanks,
> > >>>
> > >>>John
> > >>>
> > >>>>-----Original Message-----
> > >>>>From: Igor Bryskin [mailto:[email-masked]]
> > >>>>Sent: Friday, August 29, 2008 5:51 AM
> > >>>>To: Yakov Rekhter; Lou Berger
> > >>>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
> > >>>>[email-masked]
> > >>>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
> > >>>>question)
> > >>>>
> > >>>>Yakov,
> > >>>>
> > >>>>You said:
> > >>>>
> > >>>>
> > >>>>... And while on the subject of scaling, please keep in mind
> > >>that BGP
> > >>>>only stores L1VPN routes on PEs that have sites of that VPN
> > >>connected
> > >>>>to them, and on an RR if used, but *not* on any of the P 
> > >routers. In 
> > >>>>contrast, rfc5252 (OSPF for L1VPN
> > >>>>autodiscovery) results in storing *all VPN TE information 
> > >for all the
> > >>>>VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based 
> > >>>>approach scales better than OSPF-based approach.
> > >>>>
> > >>>>Yakov.
> > >>>>
> > >>>>This is not true in case of multi-instance OSPF: one can build an 
> > >>>>overlay interconnecting PEs via one or small number of Ps
> > >>>using IPinIP
> > >>>>tunnels and run in this overlay an instance of OSPF specifically 
> > >>>>designated for distribution of L1VPN information. In this
> > >>>case the OSPF
> > >>>>solution won't scale any worse than the BGP approach. Note. 
> > >>>that rfc252
> > >>>>never said that the instance of OSPF used for flooding of the L1VPN 
> > >>>>information must be the same instance that is used for the
> > >>>distribution
> > >>>>of IP-related LSAs.
> > >>>>
> > >>>>Regards,
> > >>>>Igor
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> > 
> > 
> >      
> > --0-1141253910-1220449648=:97601
> > Content-Type: text/html; charset=us-ascii
> > 
> > <html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head
><
> body><div style="font-family:times new roman, new york, times, serif;font-siz
e:
> 12pt"><div>And I am not arguing that sufficient redundancy must be provided. 
Ho
> wever you said:<br>&gt;For your suggested approach to work with sufficient <b
r>
> &gt;redundancy, the topology of the overlay needs to be configured <br>&gt;su
ch
> that every selected P router is connected to at least two <br>&gt;other selec
t
> ed P routers and every PE router needs to be <br>&gt;connected to at least tw
o 
> selected P routers.<br><br>If you just simply interconnect all VPN-aware PEs 
in
> to a single ring via IPinIP tunnels and run an instance of OSPF to distribute
 V
> PN-related information between them, it will provide sufficient redundancy an
d 
> involve exactly *zero* Ps.<br>So, I want you to drop your lecturing tone for 
a 
> minute and simply tell in what respect in your opinion this approach is not p
er
> fect fo the L1VPN
> >  application. Otherwise, I am not interested in this discussion any longer.
 I
> do like to hear comments from other people.<br><br>Igor <br><br></div><div st
y
> le="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br>
<d
> iv style="font-family: arial,helvetica,sans-serif; font-size: 13px;">----- Or
ig
> inal Message ----<br>From: "Drake, John E" &lt;[email-masked]&gt;<b
r>
> To: Igor Bryskin &lt;[email-masked]&gt;; Yakov Rekhter &lt;yakov@juniper
.n
> et&gt;; Lou Berger &lt;[email-masked]&gt;<br>Cc: Yakov Rekhter &lt;yakov@ju
ni
> per.net&gt;; Adrian Farrel &lt;[email-masked]&gt;; [email-masked]; s
of
> [email-masked]<br>Sent: Wednesday, September 3, 2008 8:10:07 AM<br>Subject: 
RE
> : [Softwires] BGP TE attr last call by softwires WG (2nd question)<br><br>
> > Igor,<br><br>Actually, I am not sure that you do understand what I wrote, b
ec
> ause you<br>are providing examples of the redundancy that I specified - every
 P
> E<br>router needs to have connectivity to two other routers in the IGP<br>ins
ta
> nce.<br><br>Thanks,<br><br>John <br><br>&gt;-----Original Message-----<br>&gt
;F
> rom: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href="mailt
o:
> [email-masked]">[email-masked]</a>] <br>&gt;Sent: Tuesday, Septembe
r 
> 02, 2008 3:06 PM<br>&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt;C
c:
> Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="ma
i
> lto:[email-masked]">[email-masked]</a>; <br>&gt;<a ymailto="mailto:so
ft
> [email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&g
t;
> Subject: Re: [Softwires] BGP TE attr last call by softwires WG <br>&gt;(2nd q
ue
> stion)<br>&gt;<br>&gt;Hi John,<br>&gt;<br>&gt;I understand what you are sayin
g 
> and disagree. The
> >  overlay I <br>&gt;am talking about logically is a separate network and as 
an
> y <br>&gt;network it should be sufficiently redundant to function. There <br>
&g
> t;is a number of ways how you can address the redundancy <br>&gt;concerns. Lo
ok
> at the examples below:<br>&gt;<br>&gt;a) interconnect all VPN-aware PEs into 
a
> single ring: <br>&gt;PE=======PE<br>&gt; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
 
> &nbsp; &nbsp; &nbsp; &nbsp; ||<br>&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n
bs
> p; &nbsp;  PE <br>&gt;||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs
p;
> &nbsp;  ||<br>&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  PE <br>
&
> gt;||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||<br>&g
t;
> ...&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ....<br>&gt;PE====
==
> =PE<br>&gt;<br>&gt;b) connect each PE to two interconnected Ps <br>&gt;<br>&g
t;
> PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  P&nbsp; &nbsp; &nbsp; &nb
sp
> ; &nbsp; &nbsp; &nbsp;
> >  &nbsp;  PE<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
&n
> bsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
 <
> br>&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||&nbsp; &nbsp; &n
bs
> p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PE <br>&gt;&nbsp; &nbsp; &nbsp; 
&n
> bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; 
&n
> bsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
 &
> nbsp; &nbsp;  ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp
; 
> PE <br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb
sp
> ; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>&gt;..
.&
> nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||&nbsp; &nbsp; &nbsp
; 
> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ....<br>&gt;PE&nbsp; &nbsp; &nbsp;
 &
> nbsp; &nbsp; &nbsp; &nbsp;  P&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
 &
> nbsp; 
> >  PE<br>&gt;<br>&gt;<br>&gt;Note that tunnels can traverse any number of VPN
-u
> naware Ps and PEs.<br>&gt;<br>&gt;Igor<br>&gt;<br>&gt;<br>&gt;----- Original 
Me
> ssage ----<br>&gt;From: "Drake, John E" &lt;<a ymailto="mailto:John.E.Drake2@
bo
> eing.com" href="mailto:[email-masked]">[email-masked]</a>
&g
> t;<br>&gt;To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" href="
ma
> ilto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt;
&l
> t;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">yakov
@j
> uniper.net</a>&gt;; Lou Berger &lt;<a ymailto="mailto:[email-masked]" href=
"m
> ailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;Cc: Yakov Rekhter &lt
;<
> a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">yakov@ju
ni
> per.net</a>&gt;; Adrian Farrel <br>&gt;&lt;<a ymailto="mailto:[email-masked]
o.
> uk" href="mailto:[email-masked]">[email-masked]</a>&gt;; <a
> >  ymailto="mailto:[email-masked]" href="mailto:[email-masked]">ccamp
@o
> ps.ietf.org</a>; <a ymailto="mailto:[email-masked]" href="mailto:softwire
s@
> ietf.org">[email-masked]</a><br>&gt;Sent: Tuesday, September 2, 2008 2:24
:2
> 6 PM<br>&gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG <b
r>
> &gt;(2nd question)<br>&gt;<br>&gt;Igor,<br>&gt;<br>&gt;Several years ago when
 O
> SPF was first proposed as an <br>&gt;autodiscovery mechanism for L1VPNs, you 
we
> re told that it was <br>&gt;a bad idea due to its scaling properties and impa
ct
> on the IGP.<br>&gt;<br>&gt;You are now tacitly agreeing with those who told y
o
> u it was a bad idea.<br>&gt;<br>&gt;For your suggested approach to work with 
su
> fficient <br>&gt;redundancy, the topology of the overlay needs to be configur
ed
> <br>&gt;such that every selected P router is connected to at least two <br>&g
t
> ;other selected P routers and every PE router needs to be <br>&gt;connected t
o 
> at least two selected
> >  P routers.<br>&gt;<br>&gt;When you are done with this configuration, you a
re
> left with a <br>&gt;situation in which *every* PE and selected P router will 
h
> ave <br>&gt;*all* L1VPN routes.<br>&gt;<br>&gt;Thanks,<br>&gt;<br>&gt;John <b
r>
> &gt;<br>&gt;&gt;-----Original Message-----<br>&gt;&gt;From: Igor Bryskin [mai
lt
> o:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">i
_b
> [email-masked]</a>]<br>&gt;&gt;Sent: Friday, August 29, 2008 12:10 PM<br>&g
t;
> &gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt;&gt;Cc: Yakov Rekhter
; 
> Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:ccamp@ops.
ie
> tf.org">[email-masked]</a>; <br>&gt;&gt;<a ymailto="mailto:softwires@ietf
.o
> rg" href="mailto:[email-masked]">[email-masked]</a><br>&gt;&gt;Subjec
t:
> Re: [Softwires] BGP TE attr last call by softwires WG (2nd <br>&gt;&gt;questi
o
> n)<br>&gt;&gt;<br>&gt;&gt;Are you calling me silly? Are you coming to Minneap
ol
> is?
> >  :=)<br>&gt;&gt;<br>&gt;&gt;Seriously, what is wrong in your opinion with t
hi
> s approach? <br>&gt;&gt;Many people are talking about multi-instance IGPs. Wh
at
> they have in <br>&gt;&gt;mind is improving the IGP scalability:<br>&gt;&gt;a)
 
> by removing non-IP advertisements from the instance of IGP that <br>&gt;&gt;m
an
> ages IP routing/forwarding tables into separate IGP instance(s);<br>&gt;&gt;b
) 
> by distributing non-IP information only to and via <br>&gt;inerested parties 
<b
> r>&gt;&gt;leaving the bulk of Ps out of the process.<br>&gt;&gt;<br>&gt;&gt;I
n 
> my opinion this is exactly what is needed for the OSPF-based L1VPN <br>&gt;&g
t;
> application.<br>&gt;&gt;<br>&gt;&gt;Igor<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<
br
> >&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;----- Original Message ----<br>&
gt
> ;&gt;From: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" h
re
> f="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;&
gt
> ;To: Igor Bryskin
> >  &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]
om
> ">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt;&gt;&lt;<a ymailto="mail
to
> :[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;
; 
> Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="mailto:lberger@labn
.n
> et">[email-masked]</a>&gt;<br>&gt;&gt;Cc: Yakov Rekhter &lt;<a ymailto="mai
lt
> o:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt
;;
> Adrian Farrel <br>&gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="m
a
> ilto:[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:cca
mp
> @ops.ietf.org" href="mailto:[email-masked]">[email-masked]</a>; <a ym
ai
> lto="mailto:[email-masked]" href="mailto:[email-masked]">softwires@ie
tf
> .org</a><br>&gt;&gt;Sent: Friday, August 29, 2008 2:31:36 PM<br>&gt;&gt;Subje
ct
> : RE: [Softwires] BGP TE attr last call by softwires WG (2nd
> >  <br>&gt;&gt;question)<br>&gt;&gt;<br>&gt;&gt;So you are proposing an OSPF 
ro
> ute reflector?&nbsp; At what point does the <br>&gt;&gt;silliness stop?<br>&g
t;
> &gt;<br>&gt;&gt;&gt;-----Original Message-----<br>&gt;&gt;&gt;From: Igor Brys
ki
> n [mailto:<a ymailto="mailto:[email-masked]" href="mailto:i_bryskin@yaho
o.
> com">[email-masked]</a>]<br>&gt;&gt;&gt;Sent: Friday, August 29, 2008 11
:2
> 9 AM<br>&gt;&gt;&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt;&gt;&
gt
> ;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" hre
f=
> "mailto:[email-masked]">[email-masked]</a>; <br>&gt;&gt;&gt;<a ymailt
o=
> "mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]
rg
> </a><br>&gt;&gt;&gt;Subject: Re: [Softwires] BGP TE attr last call by softwir
es
> WG (2nd<br>&gt;&gt;&gt;question)<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Hi John,<br>&
g
> t;&gt;&gt;<br>&gt;&gt;&gt;No, not really. When you add a PE you configure
> >  local<br>&gt;&gt;interfaces, local<br>&gt;&gt;&gt;VPN port mappings, stuff
 l
> ike that. While doing this you will also <br>&gt;&gt;&gt;configure an IPinIP 
tu
> nnel to one of your spoke Ps and enable L1VPN <br>&gt;&gt;&gt;OSPF instance o
n 
> the tunnel.<br>&gt;&gt;&gt;Once you did that the local VPN information will b
e 
> flooded<br>&gt;&gt;accross the<br>&gt;&gt;&gt;overlay, likewise, the new PE w
il
> l get all the necessary information <br>&gt;&gt;&gt;from other PEs.<br>&gt;&g
t;
> &gt;<br>&gt;&gt;&gt;Cheers,<br>&gt;&gt;&gt;Igor<br>&gt;&gt;&gt;<br>&gt;&gt;&g
t;
> <br>&gt;&gt;&gt;----- Original Message ----<br>&gt;&gt;&gt;From: "Drake, John
 E
> " &lt;<a ymailto="mailto:[email-masked]" href="mailto:John.E.Drake2
@b
> oeing.com">[email-masked]</a>&gt;<br>&gt;&gt;&gt;To: Igor Bryskin &
lt
> ;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">i_
br
> [email-masked]</a>&gt;; Yakov Rekhter <br>&gt;&gt;&gt;&lt;<a ymailto="mailto
:y
> [email-masked]"
> >  href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;
<a
> ymailto="mailto:[email-masked]" href="mailto:[email-masked]">lberger@labn
.
> net</a>&gt;<br>&gt;&gt;&gt;Cc: Yakov Rekhter &lt;<a ymailto="mailto:yakov@jun
ip
> er.net" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian Far
re
> l <br>&gt;&gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:ad
ri
> [email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:[email-masked]
tf
> .org" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="ma
il
> to:[email-masked]" href="mailto:[email-masked]">[email-masked]</a
><
> br>&gt;&gt;&gt;Sent: Friday, August 29, 2008 11:20:16 AM<br>&gt;&gt;&gt;Subje
ct
> : RE: [Softwires] BGP TE attr last call by softwires WG (2nd<br>&gt;&gt;&gt;q
ue
> stion)<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Igor,<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Do
es
> n't this defeat auto-discovery?&nbsp; I.e., how is a new PE <br>&gt;added to 
a 
> <br>&gt;&gt;&gt;given
> >  L1VPN?<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Thanks,<br>&gt;&gt;&gt;<br>&gt;&gt;&
gt
> ;John<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;-----Original Message-----<br>&gt;&g
t;
> &gt;&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" hr
ef
> ="mailto:[email-masked]">[email-masked]</a>]<br>&gt;&gt;&gt;&gt;Sen
t:
> Friday, August 29, 2008 5:51 AM<br>&gt;&gt;&gt;&gt;To: Yakov Rekhter; Lou Ber
g
> er<br>&gt;&gt;&gt;&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:cc
am
> [email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>
&g
> t;&gt;&gt;&gt;<a ymailto="mailto:[email-masked]" href="mailto:softwires@i
et
> f.org">[email-masked]</a><br>&gt;&gt;&gt;&gt;Subject: Re: [Softwires] BGP
 T
> E attr last call by softwires WG (2nd<br>&gt;&gt;&gt;&gt;question)<br>&gt;&gt
;&
> gt;&gt;<br>&gt;&gt;&gt;&gt;Yakov,<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;You 
sa
> id:<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;... And while 
on
> the subject of
> >  scaling, please keep in mind<br>&gt;&gt;that BGP<br>&gt;&gt;&gt;&gt;only s
to
> res L1VPN routes on PEs that have sites of that VPN<br>&gt;&gt;connected<br>&
gt
> ;&gt;&gt;&gt;to them, and on an RR if used, but *not* on any of the P <br>&gt
;r
> outers. In <br>&gt;&gt;&gt;&gt;contrast, rfc5252 (OSPF for L1VPN<br>&gt;&gt;&
gt
> ;&gt;autodiscovery) results in storing *all VPN TE information <br>&gt;for al
l 
> the<br>&gt;&gt;&gt;&gt;VPNs* on *all* the IGP nodes, both P and PE. So, clear
ly
> BGP-based <br>&gt;&gt;&gt;&gt;approach scales better than OSPF-based approach
.
> <br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;Yakov.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt
;&
> gt;&gt;This is not true in case of multi-instance OSPF: one can build an <br>
&g
> t;&gt;&gt;&gt;overlay interconnecting PEs via one or small number of Ps<br>&g
t;
> &gt;&gt;using IPinIP<br>&gt;&gt;&gt;&gt;tunnels and run in this overlay an in
st
> ance of OSPF specifically <br>&gt;&gt;&gt;&gt;designated for distribution of 
L1
> VPN information. In
> >  this<br>&gt;&gt;&gt;case the OSPF<br>&gt;&gt;&gt;&gt;solution won't scale 
an
> y worse than the BGP approach. Note. <br>&gt;&gt;&gt;that rfc252<br>&gt;&gt;&
gt
> ;&gt;never said that the instance of OSPF used for flooding of the L1VPN <br>
&g
> t;&gt;&gt;&gt;information must be the same instance that is used for the<br>&
gt
> ;&gt;&gt;distribution<br>&gt;&gt;&gt;&gt;of IP-related LSAs.<br>&gt;&gt;&gt;&
gt
> ;<br>&gt;&gt;&gt;&gt;Regards,<br>&gt;&gt;&gt;&gt;Igor<br>&gt;&gt;&gt;&gt;<br>
&g
> t;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt
;&
> gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<b
r>
> &gt;<br>&gt;<br>&gt;<br>&gt;<br><br></div></div></div><br>
> > 
> >       </body></html>
> > --0-1141253910-1220449648=:97601--
> 
> 
> 
>       
> --0-1852435290-1220452662=:19087
> Content-Type: text/html; charset=us-ascii
> 
> <html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><
body><div style="font-family:times new roman, new york, times, serif;font-size:
12pt"><div>Yaokov,<br><br>Please,&nbsp; see in-line.<br></div><div style="font-
family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style=
"font-family: arial,helvetica,sans-serif; font-size: 13px;">----- Original Mess
age ----<br>From: Yakov Rekhter &lt;[email-masked]&gt;<br>To: Igor Bryskin &
lt;[email-masked]&gt;<br>Cc: "Drake, John E" &lt;[email-masked]&
gt;; Lou Berger &lt;[email-masked]&gt;; Adrian Farrel &lt;[email-masked]
&gt;; [email-masked]; [email-masked]<br>Sent: Wednesday, September 3, 2
008 9:55:49 AM<br>Subject: Re: [Softwires] BGP TE attr last call by softwires W
G (2nd question) <br><br>
> Igor,<br><br>&gt; And I am not arguing that sufficient redundancy must be pro
vided. However you<br>&gt; said:<br>&gt; &gt;For your suggested approach to wor
k with sufficient <br>&gt; &gt;redundancy, the topology of the overlay needs to
 be configured <br>&gt; &gt;such that every selected P router is connected to a
t least two <br>&gt; &gt;other selected P routers and every PE router needs to 
be <br>&gt; &gt;connected to at least two selected P routers.<br>&gt; <br>&gt; 
If you just simply interconnect all VPN-aware PEs into a single<br>&gt; ring vi
a IPin IP tunnels and run an instance of OSPF to distribute<br>&gt; VPN-related
 information between them, it will provide sufficient<br>&gt; redundancy and in
volve exactly *zero* Ps.<br>&gt;<br>&gt; So, I want you to drop your lecturing 
tone for a minute and simply<br>&gt; tell in what respect in your opinion this 
approach is not perfect<br>&gt; fo the L1VPN application. Otherwise, I am not i
nterested in
>  this<br>&gt; discussion any longer. I do like to hear comments from other pe
ople.<br><br>Since you asked, one problem with using OSPF, as John correctly<br
>pointed out, is that you are left with a situation in which *every* PE <br>rou
ter will have *all* L1VPN routes for all the L1VPNs. Of course, <br>this is "pe
rfect" in a sense that you can do no worse than that :-)<br><br>IB&gt;&gt; Ok. 
Several points here. Note that neither Ps nor VPN-unaware PEs participate in th
e distribution/maintenance of VPN information, which is already significantly b
etter than what you said about the OSPF solution in your previous mail:<br><br>
&gt;... And while on the subject of scaling, please keep in mind that BGP<br>&g
t;&nbsp;&nbsp; only stores L1VPN routes on PEs that have sites of that VPN<br>&
gt;&nbsp;&nbsp; connected to them, and on an RR if used, but *not* on any of th
e P <br>&gt;&nbsp;&nbsp; routers. In contrast, rfc5252 (OSPF for L1VPN<br>&gt;&
nbsp;&nbsp;
>  autodiscovery) results in storing *all VPN TE information <br>&gt;&nbsp;&nbs
p; for all the VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-bas
ed <br>&gt;&nbsp;&nbsp; approach scales better than OSPF-based approach.<br><br
>&gt; &gt;&gt;&gt;&gt;Yakov.<br><br>I do agree that if you use a single ring ov
erlay interconnecting all VPN aware PEs you will have LSDBs at all PEs contain 
VPN info about all VPNs. However, in case of L1VPN this is not VPN routes, rath
er VPN Provider-To-Customer port mappings which I believe will prove to be sugn
ifficantly smaller, so I am not sure yet how bad is that. In any case, if it do
es present a problem on a network with large number of VPNs, who said that it h
as to be a single overlay? Why not to configure several overlays - each contain
ing a single ring that interconnects PEs participating in a common sub-set of V
PNs, and run a seperate instance of OSPF in each overlay?<br><br>Igor<br><br><b
r>&nbsp;<br>&gt;
>  <br>&gt; <br>&gt; <br>&gt; <br>&gt; ----- Original Message ----<br>&gt; From
: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" href="mailto
:[email-masked]">[email-masked]</a>&gt;<br>&gt; To: Igor Br
yskin &lt;<a ymailto="mailto:[email-masked]" href="mailto:i_bryskin@yahoo.
com">[email-masked]</a>&gt;; Yakov Rekhter &lt;<a ymailto="mailto:yakov@ju
niper.net" href="mailto:[email-masked]">[email-masked]</a>&gt;; Lo<br>u B
erger &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">l
[email-masked]</a>&gt;<br>&gt; Cc: Yakov Rekhter &lt;<a ymailto="mailto:yakov@
juniper.net" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian 
Farrel &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]
o.uk">[email-masked]</a>&gt;; c<br><a ymailto="mailto:[email-masked]" h
ref="mailto:[email-masked]">[email-masked]</a>; <a ymailto="mailto:softwi
[email-masked]"
>  href="mailto:[email-masked]">[email-masked]</a><br>&gt; Sent: Wednes
day, September 3, 2008 8:10:07 AM<br>&gt; Subject: RE: [Softwires] BGP TE attr 
last call by softwires WG (2nd question)<br>&gt; <br>&gt; Igor,<br>&gt; <br>&gt
; Actually, I am not sure that you do understand what I wrote, because you<br>&
gt; are providing examples of the redundancy that I specified - every PE<br>&gt
; router needs to have connectivity to two other routers in the IGP<br>&gt; ins
tance.<br>&gt; <br>&gt; Thanks,<br>&gt; <br>&gt; John <br>&gt; <br>&gt; &gt;---
--Original Message-----<br>&gt; &gt;From: Igor Bryskin [mailto:<a ymailto="mail
to:[email-masked]" href="mailto:[email-masked]">[email-masked]</
a>] <br>&gt; &gt;Sent: Tuesday, September 02, 2008 3:06 PM<br>&gt; &gt;To: Drak
e, John E; Yakov Rekhter; Lou Berger<br>&gt; &gt;Cc: Yakov Rekhter; Adrian Farr
el; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">cca
[email-masked]</a>;
>  <br>&gt; &gt;<a ymailto="mailto:[email-masked]" href="mailto:softwires@i
etf.org">[email-masked]</a><br>&gt; &gt;Subject: Re: [Softwires] BGP TE att
r last call by softwires WG <br>&gt; &gt;(2nd question)<br>&gt; &gt;<br>&gt; &g
t;Hi John,<br>&gt; &gt;<br>&gt; &gt;I understand what you are saying and disagr
ee. The overlay I <br>&gt; &gt;am talking about logically is a separate network
 and as any <br>&gt; &gt;network it should be sufficiently redundant to functio
n. There <br>&gt; &gt;is a number of ways how you can address the redundancy <b
r>&gt; &gt;concerns. Look at the examples below:<br>&gt; &gt;<br>&gt; &gt;a) in
terconnect all VPN-aware PEs into a single ring: <br>&gt; &gt;PE=======PE<br>&g
t; &gt; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||<br>
&gt; &gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  PE <br>&gt; &gt;||
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||<br>&gt; &gt;
PE&nbsp; &nbsp; &nbsp;
>  &nbsp; &nbsp; &nbsp; &nbsp;  PE <br>&gt; &gt;||&nbsp; &nbsp; &nbsp; &nbsp; &
nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||<br>&gt; &gt;...&nbsp; &nbsp; &nbsp; &nbsp
; &nbsp; &nbsp; &nbsp; &nbsp; ....<br>&gt; &gt;PE=======PE<br>&gt; &gt;<br>&gt;
 &gt;b) connect each PE to two interconnected Ps <br>&gt; &gt;<br>&gt; &gt;PE&n
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  P&nbsp; &nbsp; &nbsp; &nbsp; &n
bsp; &nbsp; &nbsp; &nbsp;  PE<br>&gt; &gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n
bsp; &nbsp; &nbsp; &nbsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n
bsp; &nbsp; &nbsp; <br>&gt; &gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb
sp;  ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PE <br>&g
t; &gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>&gt; &gt;PE&
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||&nbsp; &nbsp; &nbsp; &nbsp; 
&nbsp; &nbsp; &nbsp;
>  &nbsp; &nbsp; PE <br>&gt; &gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs
p; &nbsp; &nbsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs
p; &nbsp; <br>&gt; &gt;...&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs
p;  ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ....<br>&
gt; &gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  P&nbsp; &nbsp; &nbs
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  PE<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt
;Note that tunnels can traverse any number of VPN-unaware Ps and PEs.<br>&gt; &
gt;<br>&gt; &gt;Igor<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;----- Original Messa
ge ----<br>&gt; &gt;From: "Drake, John E" &lt;<a ymailto="mailto:John.E.Drake2@
boeing.com" href="mailto:[email-masked]">[email-masked]</a>
&gt;<br>&gt; &gt;To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" h
ref="mailto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter <br
>&gt; &gt;&lt;<a
>  ymailto="mailto:[email-masked]" href="mailto:[email-masked]">yakov@jun
iper.net</a>&gt;; Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="mai
lto:[email-masked]">[email-masked]</a>&gt;<br>&gt; &gt;Cc: Yakov Rekhter &l
t;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">yakov@j
uniper.net</a>&gt;; Adrian Farrel <br>&gt; &gt;&lt;<a ymailto="mailto:adrian@ol
ddog.co.uk" href="mailto:[email-masked]">[email-masked]</a>&gt;; <a y
mailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]
etf.org</a>; <a ymailto="mailto:[email-masked]" href="mailto:softwires@ietf
.org">[email-masked]</a><br>&gt; &gt;Sent: Tuesday, September 2, 2008 2:24:
26 PM<br>&gt; &gt;Subject: RE: [Softwires] BGP TE attr last call by softwires W
G <br>&gt; &gt;(2nd question)<br>&gt; &gt;<br>&gt; &gt;Igor,<br>&gt; &gt;<br>&g
t; &gt;Several years ago when OSPF was first proposed as an <br>&gt; &gt;autodi
scovery mechanism for
>  L1VPNs, you were told that it was <br>&gt; &gt;a bad idea due to its scaling
 properties and impact on the IGP.<br>&gt; &gt;<br>&gt; &gt;You are now tacitly
 agreeing with those who told you it was a bad idea.<br>&gt; &gt;<br>&gt; &gt;F
or your suggested approach to work with sufficient <br>&gt; &gt;redundancy, the
 topology of the overlay needs to be configured <br>&gt; &gt;such that every se
lected P router is connected to at least two <br>&gt; &gt;other selected P rout
ers and every PE router needs to be <br>&gt; &gt;connected to at least two sele
cted P routers.<br>&gt; &gt;<br>&gt; &gt;When you are done with this configurat
ion, you are left with a <br>&gt; &gt;situation in which *every* PE and selecte
d P router will have <br>&gt; &gt;*all* L1VPN routes.<br>&gt; &gt;<br>&gt; &gt;
Thanks,<br>&gt; &gt;<br>&gt; &gt;John <br>&gt; &gt;<br>&gt; &gt;&gt;-----Origin
al Message-----<br>&gt; &gt;&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:i
[email-masked]"
>  href="mailto:[email-masked]">[email-masked]</a>]<br>&gt; &gt;&gt;S
ent: Friday, August 29, 2008 12:10 PM<br>&gt; &gt;&gt;To: Drake, John E; Yakov 
Rekhter; Lou Berger<br>&gt; &gt;&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailt
o="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]
rg</a>; <br>&gt; &gt;&gt;<a ymailto="mailto:[email-masked]" href="mailto:so
[email-masked]">[email-masked]</a><br>&gt; &gt;&gt;Subject: Re: [Softwire
s] BGP TE attr last call by softwires WG (2nd <br>&gt; &gt;&gt;question)<br>&gt
; &gt;&gt;<br>&gt; &gt;&gt;Are you calling me silly? Are you coming to Minneapo
lis? :=)<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;Seriously, what is wrong in your opin
ion with this approach? <br>&gt; &gt;&gt;Many people are talking about multi-in
stance IGPs. What they have in <br>&gt; &gt;&gt;mind is improving the IGP scala
bility:<br>&gt; &gt;&gt;a) by removing non-IP advertisements from the instance 
of IGP that <br>&gt;
>  &gt;&gt;manages IP routing/forwarding tables into separate IGP instance(s);<
br>&gt; &gt;&gt;b) by distributing non-IP information only to and via <br>&gt; 
&gt;inerested parties <br>&gt; &gt;&gt;leaving the bulk of Ps out of the proces
s.<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;In my opinion this is exactly what is neede
d for the OSPF-based L1VPN <br>&gt; &gt;&gt;application.<br>&gt; &gt;&gt;<br>&g
t; &gt;&gt;Igor<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;
&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;----- Original Message -
---<br>&gt; &gt;&gt;From: "Drake, John E" &lt;<a ymailto="mailto:John.E.Drake2@
boeing.com" href="mailto:[email-masked]">[email-masked]</a>
&gt;<br>&gt; &gt;&gt;To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]
m" href="mailto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter
 <br>&gt; &gt;&gt;&lt;<a ymailto="mailto:[email-masked]"
>  href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">lberger@labn.
net</a>&gt;<br>&gt; &gt;&gt;Cc: Yakov Rekhter &lt;<a ymailto="mailto:yakov@juni
per.net" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian Farr
el <br>&gt; &gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:ad
[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:[email-masked]
tf.org" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="ma
ilto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a
><br>&gt; &gt;&gt;Sent: Friday, August 29, 2008 2:31:36 PM<br>&gt; &gt;&gt;Subj
ect: RE: [Softwires] BGP TE attr last call by softwires WG (2nd <br>&gt; &gt;&g
t;question)<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;So you are proposing an OSPF route
 reflector?&nbsp; At what point does the <br>&gt; &gt;&gt;silliness stop?<br>&g
t; &gt;&gt;<br>&gt;
>  &gt;&gt;&gt;-----Original Message-----<br>&gt; &gt;&gt;&gt;From: Igor Bryski
n [mailto:<a ymailto="mailto:[email-masked]" href="mailto:i_bryskin@yahoo.
com">[email-masked]</a>]<br>&gt; &gt;&gt;&gt;Sent: Friday, August 29, 2008
 11:29 AM<br>&gt; &gt;&gt;&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&
gt; &gt;&gt;&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:ccamp@ops.
ietf.org" href="mailto:[email-masked]">[email-masked]</a>; <br>&gt; &gt
;&gt;&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]
">[email-masked]</a><br>&gt; &gt;&gt;&gt;Subject: Re: [Softwires] BGP TE at
tr last call by softwires WG (2nd<br>&gt; &gt;&gt;&gt;question)<br>&gt; &gt;&gt
;&gt;<br>&gt; &gt;&gt;&gt;Hi John,<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;No,
 not really. When you add a PE you configure local<br>&gt; &gt;&gt;interfaces, 
local<br>&gt; &gt;&gt;&gt;VPN port mappings, stuff like that. While doing this 
you will also <br>&gt;
>  &gt;&gt;&gt;configure an IPinIP tunnel to one of your spoke Ps and enable L1
VPN <br>&gt; &gt;&gt;&gt;OSPF instance on the tunnel.<br>&gt; &gt;&gt;&gt;Once 
you did that the local VPN information will be flooded<br>&gt; &gt;&gt;accross 
the<br>&gt; &gt;&gt;&gt;overlay, likewise, the new PE will get all the necessar
y information <br>&gt; &gt;&gt;&gt;from other PEs.<br>&gt; &gt;&gt;&gt;<br>&gt;
 &gt;&gt;&gt;Cheers,<br>&gt; &gt;&gt;&gt;Igor<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;
&gt;&gt;<br>&gt; &gt;&gt;&gt;----- Original Message ----<br>&gt; &gt;&gt;&gt;Fr
om: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" href="mail
to:[email-masked]">[email-masked]</a>&gt;<br>&gt; &gt;&gt;&
gt;To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" href="mailto:i_
[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt; &gt;&gt;
&gt;&lt;<a ymailto="mailto:[email-masked]"
>  href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">lberger@labn.
net</a>&gt;<br>&gt; &gt;&gt;&gt;Cc: Yakov Rekhter &lt;<a ymailto="mailto:yakov@
juniper.net" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian 
Farrel <br>&gt; &gt;&gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="m
ailto:[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:ccam
[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <a yma
ilto="mailto:[email-masked]" href="mailto:[email-masked]">softwires@iet
f.org</a><br>&gt; &gt;&gt;&gt;Sent: Friday, August 29, 2008 11:20:16 AM<br>&gt;
 &gt;&gt;&gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2n
d<br>&gt; &gt;&gt;&gt;question)<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;Igor,<
br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;Doesn't this defeat auto-discovery?&nb
sp; I.e., how is a new
>  PE <br>&gt; &gt;added to a <br>&gt; &gt;&gt;&gt;given L1VPN?<br>&gt; &gt;&gt
;&gt;<br>&gt; &gt;&gt;&gt;Thanks,<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;John
<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;-----Original Message-----<br>&gt
; &gt;&gt;&gt;&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:i_bryskin@yahoo
.com" href="mailto:[email-masked]">[email-masked]</a>]<br>&gt; &gt;&g
t;&gt;&gt;Sent: Friday, August 29, 2008 5:51 AM<br>&gt; &gt;&gt;&gt;&gt;To: Yak
ov Rekhter; Lou Berger<br>&gt; &gt;&gt;&gt;&gt;Cc: Yakov Rekhter; Adrian Farrel
; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">ccamp
@ops.ietf.org</a>; <br>&gt; &gt;&gt;&gt;&gt;<a ymailto="mailto:[email-masked]
rg" href="mailto:[email-masked]">[email-masked]</a><br>&gt; &gt;&gt;&gt
;&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd<br>&gt
; &gt;&gt;&gt;&gt;question)<br>&gt; &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;Ya
kov,<br>&gt;
>  &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;You said:<br>&gt; &gt;&gt;&gt;&gt;<
br>&gt; &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;... And while on the subject o
f scaling, please keep in mind<br>&gt; &gt;&gt;that BGP<br>&gt; &gt;&gt;&gt;&gt
;only stores L1VPN routes on PEs that have sites of that VPN<br>&gt; &gt;&gt;co
nnected<br>&gt; &gt;&gt;&gt;&gt;to them, and on an RR if used, but *not* on any
 of the P <br>&gt; &gt;routers. In <br>&gt; &gt;&gt;&gt;&gt;contrast, rfc5252 (
OSPF for L1VPN<br>&gt; &gt;&gt;&gt;&gt;autodiscovery) results in storing *all V
PN TE information <br>&gt; &gt;for all the<br>&gt; &gt;&gt;&gt;&gt;VPNs* on *al
l* the IGP nodes, both P and PE. So, clearly BGP-based <br>&gt; &gt;&gt;&gt;&gt
;approach scales better than OSPF-based approach.<br>&gt; &gt;&gt;&gt;&gt;<br>&
gt; &gt;&gt;&gt;&gt;Yakov.<br>&gt; &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;Thi
s is not true in case of multi-instance OSPF: one can build an <br>&gt; &gt;&gt
;&gt;&gt;overlay
>  interconnecting PEs via one or small number of Ps<br>&gt; &gt;&gt;&gt;using 
IPinIP<br>&gt; &gt;&gt;&gt;&gt;tunnels and run in this overlay an instance of O
SPF specifically <br>&gt; &gt;&gt;&gt;&gt;designated for distribution of L1VPN 
information. In this<br>&gt; &gt;&gt;&gt;case the OSPF<br>&gt; &gt;&gt;&gt;&gt;
solution won't scale any worse than the BGP approach. Note. <br>&gt; &gt;&gt;&g
t;that rfc252<br>&gt; &gt;&gt;&gt;&gt;never said that the instance of OSPF used
 for flooding of the L1VPN <br>&gt; &gt;&gt;&gt;&gt;information must be the sam
e instance that is used for the<br>&gt; &gt;&gt;&gt;distribution<br>&gt; &gt;&g
t;&gt;&gt;of IP-related LSAs.<br>&gt; &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;
Regards,<br>&gt; &gt;&gt;&gt;&gt;Igor<br>&gt; &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;
&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;
<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt
;<br>&gt;
>  &gt;&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt
;<br>&gt; <br>&gt; <br>&gt;&nbsp; &nbsp; &nbsp;  <br>&gt; --0-1141253910-122044
9648=:97601<br>&gt; Content-Type: text/html; charset=us-ascii<br>&gt; <br>&gt; 
&lt;html&gt;&lt;head&gt;&lt;style type="text/css"&gt;&lt;!-- DIV {margin:0px;} 
--&gt;&lt;/style&gt;&lt;/head&gt;&lt;<br>body&gt;&lt;div style="font-family:tim
es new roman, new york, times, serif;font-size:<br>12pt"&gt;&lt;div&gt;And I am
 not arguing that sufficient redundancy must be provided. Ho<br>wever you said:
&lt;br&gt;&amp;gt;For your suggested approach to work with sufficient &lt;br&gt
;<br>&amp;gt;redundancy, the topology of the overlay needs to be configured &lt
;br&gt;&amp;gt;such<br> that every selected P router is connected to at least t
wo &lt;br&gt;&amp;gt;other select<br>ed P routers and every PE router needs to 
be &lt;br&gt;&amp;gt;connected to at least two <br>selected P routers.&lt;br&gt
;&lt;br&gt;If you just
>  simply interconnect all VPN-aware PEs in<br>to a single ring via IPinIP tunn
els and run an instance of OSPF to distribute V<br>PN-related information betwe
en them, it will provide sufficient redundancy and <br>involve exactly *zero* P
s.&lt;br&gt;So, I want you to drop your lecturing tone for a <br>minute and sim
ply tell in what respect in your opinion this approach is not per<br>fect fo th
e L1VPN<br>&gt;&nbsp; application. Otherwise, I am not interested in this discu
ssion any longer. I<br> do like to hear comments from other people.&lt;br&gt;&l
t;br&gt;Igor &lt;br&gt;&lt;br&gt;&lt;/div&gt;&lt;div sty<br>le="font-family: ti
mes new roman,new york,times,serif; font-size: 12pt;"&gt;&lt;br&gt;&lt;d<br>iv 
style="font-family: arial,helvetica,sans-serif; font-size: 13px;"&gt;----- Orig
<br>inal Message ----&lt;br&gt;From: "Drake, John E" &amp;lt;<a ymailto="mailto
:[email-masked]"
>  href="mailto:[email-masked]">[email-masked]</a>&amp;gt;&
lt;br&gt;<br>To: Igor Bryskin &amp;lt;<a ymailto="mailto:[email-masked]" h
ref="mailto:[email-masked]">[email-masked]</a>&amp;gt;; Yakov Rekhter
 &amp;lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">yako
[email-masked]</a><br>et&amp;gt;; Lou Berger &amp;lt;<a ymailto="mailto:lberger@la
bn.net" href="mailto:[email-masked]">[email-masked]</a>&amp;gt;&lt;br&gt;Cc
: Yakov Rekhter &amp;lt;yakov@juni<br>per.net&amp;gt;; Adrian Farrel &amp;lt;<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">adrian@
olddog.co.uk</a>&amp;gt;; <a ymailto="mailto:[email-masked]" href="mailto:c
[email-masked]">[email-masked]</a>; sof<br><a ymailto="mailto:twires@iet
f.org" href="mailto:[email-masked]">[email-masked]</a>&lt;br&gt;Sent: Wednesd
ay, September 3, 2008 8:10:07 AM&lt;br&gt;Subject: RE<br>: [Softwires] BGP TE a
ttr last call by
>  softwires WG (2nd question)&lt;br&gt;&lt;br&gt;<br>&gt; Igor,&lt;br&gt;&lt;b
r&gt;Actually, I am not sure that you do understand what I wrote, bec<br>ause y
ou&lt;br&gt;are providing examples of the redundancy that I specified - every P
<br>E&lt;br&gt;router needs to have connectivity to two other routers in the IG
P&lt;br&gt;insta<br>nce.&lt;br&gt;&lt;br&gt;Thanks,&lt;br&gt;&lt;br&gt;John &lt
;br&gt;&lt;br&gt;&amp;gt;-----Original Message-----&lt;br&gt;&amp;gt;F<br>rom: 
Igor Bryskin [mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]
om" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<br
><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">i_br
[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:i_
[email-masked]">[email-masked]</a>&lt;/a&gt;] &lt;br&gt;&amp;gt;Sent: T
uesday, September <br>02, 2008 3:06 PM&lt;br&gt;&amp;gt;To: Drake, John E; Yako
v Rekhter; Lou
>  Berger&lt;br&gt;&amp;gt;Cc:<br> Yakov Rekhter; Adrian Farrel; &lt;a ymailto=
"mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]"
>[email-masked]</a>" href="mai<br>lto:<a ymailto="mailto:[email-masked]
" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailt
o:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&l
t;/a&gt;; &lt;br&gt;&amp;gt;&lt;a ymailto="mailto:soft<br><a ymailto="mailto:wi
[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a 
ymailto="mailto:[email-masked]" href="mailto:[email-masked]">softwires@
ietf.org</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:softwires@
ietf.org">[email-masked]</a>&lt;/a&gt;&lt;br&gt;&amp;gt;<br>Subject: Re: [S
oftwires] BGP TE attr last call by softwires WG &lt;br&gt;&amp;gt;(2nd que<br>s
tion)&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;Hi John,&lt;br&gt;&amp;gt;&lt;br&gt;&a
mp;gt;I understand
>  what you are saying <br>and disagree. The<br>&gt;&nbsp; overlay I &lt;br&gt;
&amp;gt;am talking about logically is a separate network and as an<br>y &lt;br&
gt;&amp;gt;network it should be sufficiently redundant to function. There &lt;b
r&gt;&amp;g<br>t;is a number of ways how you can address the redundancy &lt;br&
gt;&amp;gt;concerns. Look<br> at the examples below:&lt;br&gt;&amp;gt;&lt;br&gt
;&amp;gt;a) interconnect all VPN-aware PEs into a<br> single ring: &lt;br&gt;&a
mp;gt;PE=======PE&lt;br&gt;&amp;gt; ||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbs
p; &amp;nbsp; <br>&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; ||&lt;br&gt;&amp;
gt;PE&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbs<br>p; &amp
;nbsp;&nbsp; PE &lt;br&gt;&amp;gt;||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;
 &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;<br> &amp;nbsp;&nbsp; ||&lt;br&gt;&
amp;gt;PE&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp
;nbsp;&nbsp; PE
>  &lt;br&gt;&amp;<br>gt;||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbs
p; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; ||&lt;br&gt;&amp;gt;<br>..
.&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &
amp;nbsp; ....&lt;br&gt;&amp;gt;PE======<br>=PE&lt;br&gt;&amp;gt;&lt;br&gt;&amp
;gt;b) connect each PE to two interconnected Ps &lt;br&gt;&amp;gt;&lt;br&gt;&am
p;gt;<br>PE&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &a
mp;nbsp;&nbsp; P&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp<br>; &amp;nbsp; &amp
;nbsp; &amp;nbsp;<br>&gt;&nbsp; &amp;nbsp;&nbsp; PE&lt;br&gt;&amp;gt;&amp;nbsp;
 &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &
amp;n<br>bsp; &amp;nbsp; ||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbs
p; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; &lt;<br>br&gt;&amp;gt;PE&a
mp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp
; ||&amp;nbsp;
>  &amp;nbsp; &amp;nbs<br>p; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;n
bsp; &amp;nbsp; PE &lt;br&gt;&amp;gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;n<br
>bsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; ||&amp;
nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;n<br>bsp; &amp;nbsp; &amp;nbsp; &am
p;nbsp; &amp;nbsp; &lt;br&gt;&amp;gt;PE&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nb
sp; &amp;nbsp; &amp;<br>nbsp; &amp;nbsp;&nbsp; ||&amp;nbsp; &amp;nbsp; &amp;nbs
p; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; <br>PE &lt
;br&gt;&amp;gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp
; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp<br>; ||&amp;nbsp; &amp;nbsp; &amp;
nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &lt;br&
gt;&amp;gt;...&amp;<br>nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;n
bsp; &amp;nbsp; &amp;nbsp;&nbsp; ||&amp;nbsp; &amp;nbsp; &amp;nbsp; <br>&amp;nb
sp; &amp;nbsp;
>  &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; ....&lt;br&gt;&amp;gt;PE&a
mp;nbsp; &amp;nbsp; &amp;nbsp; &amp;<br>nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&
nbsp; P&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;n
bsp; &amp;<br>nbsp; <br>&gt;&nbsp; PE&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;&lt;br
&gt;&amp;gt;Note that tunnels can traverse any number of VPN-u<br>naware Ps and
 PEs.&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;Igor&lt;br&gt;&amp;gt;&lt;br&gt;&amp;g
t;&lt;br&gt;&amp;gt;----- Original Me<br>ssage ----&lt;br&gt;&amp;gt;From: "Dra
ke, John E" &amp;lt;&lt;a ymailto="mailto:John.E.Drake2@bo<br><a target="_blank
" href="http://eing.com">eing.com</a>" href="mailto:<a ymailto="mailto:John.E.D
[email-masked]" href="mailto:[email-masked]">[email-masked]
om</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:John.E.Dra
[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;g<br>t;&lt;br&gt;&am
p;gt;To: Igor Bryskin
>  &amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="
mailto:[email-masked]">[email-masked]</a>" href="ma<br>ilto:<a ymailt
o="mailto:[email-masked]" href="mailto:[email-masked]">i_bryskin@yaho
o.com</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:i_bryskin@ya
hoo.com">[email-masked]</a>&lt;/a&gt;&amp;gt;; Yakov Rekhter &lt;br&gt;&am
p;gt;&amp;l<br>t;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" hr
ef="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="m
ailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"
&gt;yakov@j<br><a target="_blank" href="http://uniper.net">uniper.net</a>&lt;/a
&gt;&amp;gt;; Lou Berger &amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:lberg
[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="m<br>ai
lto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">lberger
@labn.net</a>"&gt;<a
>  ymailto="mailto:[email-masked]" href="mailto:[email-masked]">lberger@lab
n.net</a>&lt;/a&gt;&amp;gt;&lt;br&gt;&amp;gt;Cc: Yakov Rekhter &amp;lt;&lt;<br>
a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:yakov@juni
per.net">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]
et" href="mailto:[email-masked]">[email-masked]</a>"&gt;yakov@juni<br><a 
target="_blank" href="http://per.net">per.net</a>&lt;/a&gt;&amp;gt;; Adrian Far
rel &lt;br&gt;&amp;gt;&amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:adrian@o
lddog.co" href="mailto:[email-masked]">[email-masked]</a>.<br>uk" href="mai
lto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">a
[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto
:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; &lt;a<br>&gt;&
nbsp; ymailto="mailto:<a ymailto="mailto:[email-masked]"
>  href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a yma
ilto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]
f.org</a>"&gt;ccamp@o<br><a target="_blank" href="http://ps.ietf.org">ps.ietf.o
rg</a>&lt;/a&gt;; &lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" 
href="mailto:[email-masked]">[email-masked]</a>" href="mailto:softwires
@<br><a target="_blank" href="http://ietf.org">ietf.org</a>"&gt;<a ymailto="mai
lto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>
&lt;/a&gt;&lt;br&gt;&amp;gt;Sent: Tuesday, September 2, 2008 2:24:2<br>6 PM&lt;
br&gt;&amp;gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG &l
t;br&gt;<br>&amp;gt;(2nd question)&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;Igor,&lt;
br&gt;&amp;gt;&lt;br&gt;&amp;gt;Several years ago when O<br>SPF was first propo
sed as an &lt;br&gt;&amp;gt;autodiscovery mechanism for L1VPNs, you we<br>re to
ld that it was
>  &lt;br&gt;&amp;gt;a bad idea due to its scaling properties and impact<br> on
 the IGP.&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;You are now tacitly agreeing with 
those who told yo<br>u it was a bad idea.&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;Fo
r your suggested approach to work with su<br>fficient &lt;br&gt;&amp;gt;redunda
ncy, the topology of the overlay needs to be configured<br> &lt;br&gt;&amp;gt;s
uch that every selected P router is connected to at least two &lt;br&gt;&amp;gt
<br>;other selected P routers and every PE router needs to be &lt;br&gt;&amp;gt
;connected to <br>at least two selected<br>&gt;&nbsp; P routers.&lt;br&gt;&amp;
gt;&lt;br&gt;&amp;gt;When you are done with this configuration, you are<br> lef
t with a &lt;br&gt;&amp;gt;situation in which *every* PE and selected P router 
will h<br>ave &lt;br&gt;&amp;gt;*all* L1VPN routes.&lt;br&gt;&amp;gt;&lt;br&gt;
&amp;gt;Thanks,&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;John
>  &lt;br&gt;<br>&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;-----Original Message-----&l
t;br&gt;&amp;gt;&amp;gt;From: Igor Bryskin [mailt<br>o:&lt;a ymailto="mailto:<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">i_brysk
[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="ma
ilto:[email-masked]">[email-masked]</a>"&gt;i_b<br><a ymailto="mailto
:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt
;]&lt;br&gt;&amp;gt;&amp;gt;Sent: Friday, August 29, 2008 12:10 PM&lt;br&gt;&am
p;gt;<br>&amp;gt;To: Drake, John E; Yakov Rekhter; Lou Berger&lt;br&gt;&amp;gt;
&amp;gt;Cc: Yakov Rekhter; <br>Adrian Farrel; &lt;a ymailto="mailto:<a ymailto=
"mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]
</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">
[email-masked]</a><br><a target="_blank" href="http://tf.org">tf.org</a>"&gt;<a
>  ymailto="mailto:[email-masked]" href="mailto:[email-masked]">ccamp@o
ps.ietf.org</a>&lt;/a&gt;; &lt;br&gt;&amp;gt;&amp;gt;&lt;a ymailto="mailto:<a y
mailto="mailto:[email-masked]" href="mailto:[email-masked]">softwires@ietf.
o</a><br>rg" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:s
[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:softwires@ietf
.org" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&lt;br&g
t;&amp;gt;&amp;gt;Subject:<br> Re: [Softwires] BGP TE attr last call by softwir
es WG (2nd &lt;br&gt;&amp;gt;&amp;gt;questio<br>n)&lt;br&gt;&amp;gt;&amp;gt;&lt
;br&gt;&amp;gt;&amp;gt;Are you calling me silly? Are you coming to Minneapol<br
>is?<br>&gt;&nbsp; :=)&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;Serio
usly, what is wrong in your opinion with thi<br>s approach? &lt;br&gt;&amp;gt;&
amp;gt;Many people are talking about multi-instance IGPs. What<br> they have in
>  &lt;br&gt;&amp;gt;&amp;gt;mind is improving the IGP scalability:&lt;br&gt;&a
mp;gt;&amp;gt;a) <br>by removing non-IP advertisements from the instance of IGP
 that &lt;br&gt;&amp;gt;&amp;gt;man<br>ages IP routing/forwarding tables into s
eparate IGP instance(s);&lt;br&gt;&amp;gt;&amp;gt;b) <br>by distributing non-IP
 information only to and via &lt;br&gt;&amp;gt;inerested parties &lt;b<br>r&gt;
&amp;gt;&amp;gt;leaving the bulk of Ps out of the process.&lt;br&gt;&amp;gt;&am
p;gt;&lt;br&gt;&amp;gt;&amp;gt;In <br>my opinion this is exactly what is needed
 for the OSPF-based L1VPN &lt;br&gt;&amp;gt;&amp;gt;<br>application.&lt;br&gt;&
amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;Igor&lt;br&gt;&amp;gt;&amp;gt;&lt;br&g
t;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&lt;br<br>&gt;&amp;gt;&amp;gt;&lt;b
r&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;----- 
Original Message ----&lt;br&gt;&amp;gt<br>;&amp;gt;From: "Drake, John E" &amp;l
t;&lt;a
>  ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:Jo
[email-masked]">[email-masked]</a>" hre<br>f="mailto:<a ymail
to="mailto:[email-masked]" href="mailto:[email-masked]">Joh
[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href
="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;g
t;&lt;br&gt;&amp;gt;&amp;gt<br>;To: Igor Bryskin<br>&gt;&nbsp; &amp;lt;&lt;a ym
ailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:i_bryskin@ya
hoo.com">[email-masked]</a>" href="mailto:<a ymailto="mailto:i_bryskin@yah
oo.com" href="mailto:[email-masked]">[email-masked]</a><br>"&gt;<a ym
ailto="mailto:[email-masked]" href="mailto:[email-masked]">i_bryskin@
yahoo.com</a>&lt;/a&gt;&amp;gt;; Yakov Rekhter &lt;br&gt;&amp;gt;&amp;gt;&amp;l
t;&lt;a ymailto="mailto<br>:<a ymailto="mailto:[email-masked]"
>  href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymail
to="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]
</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">
[email-masked]</a>&lt;/a&gt;&amp;gt;; <br>Lou Berger &amp;lt;&lt;a ymailto="
mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">lber
[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:
[email-masked]">[email-masked]</a><br>et"&gt;<a ymailto="mailto:[email-masked]
t" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;&lt;br&
gt;&amp;gt;&amp;gt;Cc: Yakov Rekhter &amp;lt;&lt;a ymailto="mailt<br>o:<a ymail
to="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]
</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:yakov@jun
iper.net">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]"
>  href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;;<br>
 Adrian Farrel &lt;br&gt;&amp;gt;&amp;gt;&amp;lt;&lt;a ymailto="mailto:<a ymail
to="mailto:[email-masked]" href="mailto:[email-masked]">adrian@olddog
.co.uk</a>" href="ma<br>ilto:<a ymailto="mailto:[email-masked]" href="mail
to:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:adrian@o
lddog.co.uk" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt
;&amp;gt;; &lt;a ymailto="mailto:ccamp<br>@ops.ietf.org" href="mailto:<a ymailt
o="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]
rg</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]
rg">[email-masked]</a>&lt;/a&gt;; &lt;a ymai<br>lto="mailto:<a ymailto="mai
lto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>
" href="mailto:<a ymailto="mailto:[email-masked]"
>  href="mailto:[email-masked]">[email-masked]</a>"&gt;softwires@ietf<b
r>.org&lt;/a&gt;&lt;br&gt;&amp;gt;&amp;gt;Sent: Friday, August 29, 2008 2:31:36
 PM&lt;br&gt;&amp;gt;&amp;gt;Subject<br>: RE: [Softwires] BGP TE attr last call
 by softwires WG (2nd<br>&gt;&nbsp; &lt;br&gt;&amp;gt;&amp;gt;question)&lt;br&g
t;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;So you are proposing an OSPF ro<br>
ute reflector?&amp;nbsp; At what point does the &lt;br&gt;&amp;gt;&amp;gt;silli
ness stop?&lt;br&gt;&amp;gt;<br>&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;-----
Original Message-----&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;From: Igor Bryski<br>n [
mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mail
to:[email-masked]">[email-masked]</a>" href="mailto:i_bryskin@yahoo.<
br>com"&gt;<a ymailto="mailto:[email-masked]" href="mailto:i_bryskin@yahoo
.com">[email-masked]</a>&lt;/a&gt;]&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Sent:
 Friday, August 29,
>  2008 11:2<br>9 AM&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;To: Drake, John E; Yakov 
Rekhter; Lou Berger&lt;br&gt;&amp;gt;&amp;gt;&amp;gt<br>;Cc: Yakov Rekhter; Adr
ian Farrel; &lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="
mailto:[email-masked]">[email-masked]</a>" href=<br>"mailto:<a ymailto=
"mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]
</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]
">[email-masked]</a>&lt;/a&gt;; &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;a yma
ilto=<br>"mailto:<a ymailto="mailto:[email-masked]" href="mailto:softwires@
ietf.org">[email-masked]</a>" href="mailto:<a ymailto="mailto:softwires@iet
f.org" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="
mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]<
/a><br>&lt;/a&gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Subject: Re: [Softwires] BGP
 TE attr last call by
>  softwires<br> WG (2nd&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;question)&lt;br&gt;&a
mp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Hi John,&lt;br&gt;&amp;
g<br>t;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;No, not really. When y
ou add a PE you configure<br>&gt;&nbsp; local&lt;br&gt;&amp;gt;&amp;gt;interfac
es, local&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;VPN port mappings, stuff l<br>ike th
at. While doing this you will also &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;configure 
an IPinIP tu<br>nnel to one of your spoke Ps and enable L1VPN &lt;br&gt;&amp;gt
;&amp;gt;&amp;gt;OSPF instance on <br>the tunnel.&lt;br&gt;&amp;gt;&amp;gt;&amp
;gt;Once you did that the local VPN information will be <br>flooded&lt;br&gt;&a
mp;gt;&amp;gt;accross the&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;overlay, likewise, t
he new PE wil<br>l get all the necessary information &lt;br&gt;&amp;gt;&amp;gt;
&amp;gt;from other
>  PEs.&lt;br&gt;&amp;gt;&amp;gt;<br>&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;
Cheers,&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Igor&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;<br>&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;----- O
riginal Message ----&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;From: "Drake, John E<br>"
 &amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" hre
f="mailto:[email-masked]">[email-masked]</a>" href="mailto:
John.E.Drake2@b<br><a target="_blank" href="http://oeing.com">oeing.com</a>"&gt
;<a ymailto="mailto:[email-masked]" href="mailto:John.E.Drake2@boeing
.com">[email-masked]</a>&lt;/a&gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&
amp;gt;To: Igor Bryskin &amp;lt<br>;&lt;a ymailto="mailto:<a ymailto="mailto:i_
[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" h
ref="mailto:<a ymailto="mailto:[email-masked]"
>  href="mailto:[email-masked]">[email-masked]</a>"&gt;i_br<br><a yma
ilto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>
&lt;/a&gt;&amp;gt;; Yakov Rekhter &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;lt;&lt
;a ymailto="mailto:y<br><a ymailto="mailto:[email-masked]" href="mailto:akov@
juniper.net">[email-masked]</a>"<br>&gt;&nbsp; href="mailto:<a ymailto="mailt
o:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;
<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">yakov@jun
iper.net</a>&lt;/a&gt;&amp;gt;; Lou Berger &amp;lt;&lt;a<br> ymailto="mailto:<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">lberger@labn.
net</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:lberger
@labn.net">[email-masked]</a>"&gt;lberger@labn.<br>net&lt;/a&gt;&amp;gt;&lt;b
r&gt;&amp;gt;&amp;gt;&amp;gt;Cc: Yakov Rekhter &amp;lt;&lt;a ymailto="mailto:ya
kov@junip<br><a
>  target="_blank" href="http://er.net">er.net</a>" href="mailto:<a ymailto="ma
ilto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&
gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">yakov@
juniper.net</a>&lt;/a&gt;&amp;gt;; Adrian Farre<br>l &lt;br&gt;&amp;gt;&amp;gt;
&amp;gt;&amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" h
ref="mailto:[email-masked]">[email-masked]</a>" href="mailto:adri<br>
<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked].
uk</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]
o.uk">[email-masked]</a>&lt;/a&gt;&amp;gt;; &lt;a ymailto="mailto:<a ymail
to="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>.
org" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:ccamp@ops
.ietf.org">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]"
>  href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;; &lt;a yma
ilto="mail<br>to:<a ymailto="mailto:[email-masked]" href="mailto:softwires@
ietf.org">[email-masked]</a>" href="mailto:<a ymailto="mailto:softwires@iet
f.org" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="
mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]<
/a>&lt;/a&gt;&lt;<br>br&gt;&amp;gt;&amp;gt;&amp;gt;Sent: Friday, August 29, 200
8 11:20:16 AM&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Subject<br>: RE: [Softwires] BGP
 TE attr last call by softwires WG (2nd&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;que<br
>stion)&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Igor
,&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Does<br>n'
t this defeat auto-discovery?&amp;nbsp; I.e., how is a new PE &lt;br&gt;&amp;gt
;added to a <br>&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;given<br>&gt;&nbsp;
>  L1VPN?&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Th
anks,&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt<br>;Jo
hn&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;-
----Original Message-----&lt;br&gt;&amp;gt;&amp;gt;<br>&amp;gt;&amp;gt;From: Ig
or Bryskin [mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]
" href="mailto:[email-masked]">[email-masked]</a>" href<br>="mailto:<
a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">i_brys
[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:i_br
[email-masked]">[email-masked]</a>&lt;/a&gt;]&lt;br&gt;&amp;gt;&amp;gt;&a
mp;gt;&amp;gt;Sent:<br> Friday, August 29, 2008 5:51 AM&lt;br&gt;&amp;gt;&amp;g
t;&amp;gt;&amp;gt;To: Yakov Rekhter; Lou Berg<br>er&lt;br&gt;&amp;gt;&amp;gt;&a
mp;gt;&amp;gt;Cc: Yakov Rekhter; Adrian Farrel; &lt;a ymailto="mailto:ccam<br><
a
>  ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]<
/a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:ccamp@ops
.ietf.org">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" hr
ef="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;; &lt;br&gt;&amp
;g<br>t;&amp;gt;&amp;gt;&amp;gt;&lt;a ymailto="mailto:<a ymailto="mailto:softwi
[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="ma
ilto:softwires@iet<br><a target="_blank" href="http://f.org">f.org</a>"&gt;<a y
mailto="mailto:[email-masked]" href="mailto:[email-masked]">softwires@i
etf.org</a>&lt;/a&gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Subject: Re: [So
ftwires] BGP T<br>E attr last call by softwires WG
>  (2nd&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;question)&lt;br&gt;&amp;gt;&am
p;gt;&amp;<br>gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Yakov,&lt;br
&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Y
ou sa<br>id:&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt
;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;... And while on<br>
 the subject of<br>&gt;&nbsp; scaling, please keep in mind&lt;br&gt;&amp;gt;&am
p;gt;that BGP&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;only sto<br>res L1VPN ro
utes on PEs that have sites of that VPN&lt;br&gt;&amp;gt;&amp;gt;connected&lt;b
r&gt;&amp;gt<br>;&amp;gt;&amp;gt;&amp;gt;to them, and on an RR if used, but *no
t* on any of the P &lt;br&gt;&amp;gt;r<br>outers. In &lt;br&gt;&amp;gt;&amp;gt;
&amp;gt;&amp;gt;contrast, rfc5252 (OSPF for L1VPN&lt;br&gt;&amp;gt;&amp;gt;&amp
;gt<br>;&amp;gt;autodiscovery) results in storing *all VPN TE information &lt;b
r&gt;&amp;gt;for all
>  <br>the&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;VPNs* on *all* the IGP node
s, both P and PE. So, clearly<br> BGP-based &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&
amp;gt;approach scales better than OSPF-based approach.<br>&lt;br&gt;&amp;gt;&a
mp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Yakov.&lt;br&gt
;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;<br>gt;&amp;gt;
This is not true in case of multi-instance OSPF: one can build an &lt;br&gt;&am
p;g<br>t;&amp;gt;&amp;gt;&amp;gt;overlay interconnecting PEs via one or small n
umber of Ps&lt;br&gt;&amp;gt;<br>&amp;gt;&amp;gt;using IPinIP&lt;br&gt;&amp;gt;
&amp;gt;&amp;gt;&amp;gt;tunnels and run in this overlay an inst<br>ance of OSPF
 specifically &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;designated for distribu
tion of L1<br>VPN information. In<br>&gt;&nbsp; this&lt;br&gt;&amp;gt;&amp;gt;&
amp;gt;case the OSPF&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;solution won't sc
ale an<br>y worse than
>  the BGP approach. Note. &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;that rfc252&lt;br&
gt;&amp;gt;&amp;gt;&amp;gt<br>;&amp;gt;never said that the instance of OSPF use
d for flooding of the L1VPN &lt;br&gt;&amp;g<br>t;&amp;gt;&amp;gt;&amp;gt;infor
mation must be the same instance that is used for the&lt;br&gt;&amp;gt<br>;&amp
;gt;&amp;gt;distribution&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;of IP-related
>  LSAs.&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt<br>;&lt;br&gt;&amp;gt;&amp;gt
;&amp;gt;&amp;gt;Regards,&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Igor&lt;br&g
t;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;g<br>t;&amp;gt;&amp;gt;&amp;gt
;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&a
mp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;<br>gt;&amp;gt;&
lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&a
mp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;<br
>&amp;gt;&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;&lt;br&gt;&lt;br
&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;br&gt;<br>&gt; <br>&gt;&nbsp; &nbsp
; &nbsp;  &lt;/body&gt;&lt;/html&gt;<br>&gt; --0-1141253910-1220449648=:97601--
<br></div></div></div><br>
> 
> 
> 
>       </body></html>
> --0-1852435290-1220452662=:19087--
> 

Delivery-date: Wed, 03 Sep 2008 14:58:33 +0000
Content-class: urn:content-classes:message
Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)
Date: Wed, 3 Sep 2008 07:53:59 -0700
From: "Drake, John E" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>, "Yakov Rekhter" <[email-masked]>, "Lou Berger" <[email-masked]>
Cc: "Yakov Rekhter" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>, <[email-masked]>

>2)  Every PE router in the IGP instance has L1VPN routes that=20
>it doesn't care about.
>
>3)  The number of L1VPN routes that a given PE router doesn't=20
>care about is probably greater than the number of L1VPN routes=20
>it does care about.
>
>IB>> As I answered to Yakov if this proves to be a problem you can=20
>IB>> configure multiple overlays

JD:  "With sufficient thrust, pigs fly just fine..."  [RFC1295]

>
>Thanks,
>
>John =20
>
>>-----Original Message-----
>>From: Igor Bryskin [mailto:[email-masked]]
>>Sent: Wednesday, September 03, 2008 6:47 AM
>>To: Drake, John E; Yakov Rekhter; Lou Berger
>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked];=20
>>[email-masked]
>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd=20
>>question)
>>
>>And I am not arguing that sufficient redundancy must be provided.=20
>>However you said:
>>>For your suggested approach to work with sufficient redundancy, the=20
>>>topology of the overlay needs to be configured such that
>>every selected
>>>P router is connected to at least two other selected P routers and=20
>>>every PE router needs to be connected to at least two selected P=20
>>>routers.
>>
>>If you just simply interconnect all VPN-aware PEs into a single ring=20
>>via IPinIP tunnels and run an instance of OSPF to distribute=20
>>VPN-related information between them, it will provide sufficient=20
>>redundancy and involve exactly *zero* Ps.
>>So, I want you to drop your lecturing tone for a minute and=20
>simply tell=20
>>in what respect in your opinion this approach is not perfect fo the=20
>>L1VPN application. Otherwise, I am not interested in this discussion=20
>>any longer. I do like to hear comments from other people.
>>
>>Igor
>>
>>
>>
>>----- Original Message ----
>>From: "Drake, John E" <[email-masked]>
>>To: Igor Bryskin <[email-masked]>; Yakov Rekhter=20
>><[email-masked]>; Lou Berger <[email-masked]>
>>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel=20
>><[email-masked]>; [email-masked]; [email-masked]
>>Sent: Wednesday, September 3, 2008 8:10:07 AM
>>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd=20
>>question)
>>
>>Igor,
>>
>>Actually, I am not sure that you do understand what I wrote, because=20
>>you are providing examples of the redundancy that I specified - every=20
>>PE router needs to have connectivity to two other routers in the IGP=20
>>instance.
>>
>>Thanks,
>>
>>John
>>
>>>-----Original Message-----
>>>From: Igor Bryskin [mailto:[email-masked]]
>>>Sent: Tuesday, September 02, 2008 3:06 PM
>>>To: Drake, John E; Yakov Rekhter; Lou Berger
>>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked];=20
>>>[email-masked]
>>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
>>>question)
>>>
>>>Hi John,
>>>
>>>I understand what you are saying and disagree. The overlay I
>>am talking
>>>about logically is a separate network and as any network it=20
>should be=20
>>>sufficiently redundant to function. There is a number of=20
>ways how you=20
>>>can address the redundancy concerns. Look at the examples below:
>>>
>>>a) interconnect all VPN-aware PEs into a single ring:=20
>>>PE=3D=3D=3D=3D=3D=3D=3DPE
>>> ||                  ||
>>>PE              PE=20
>>>||                  ||
>>>PE              PE=20
>>>||                  ||
>>>...                ....
>>>PE=3D=3D=3D=3D=3D=3D=3DPE
>>>
>>>b) connect each PE to two interconnected Ps
>>>
>>>PE              P                PE
>>>                    ||                 =20
>>>PE              ||                  PE=20
>>>                    ||                 =20
>>>PE              ||                  PE=20
>>>                    ||                 =20
>>>...                ||                  ....
>>>PE              P                PE
>>>
>>>
>>>Note that tunnels can traverse any number of VPN-unaware Ps and PEs.
>>>
>>>Igor
>>>
>>>
>>>----- Original Message ----
>>>From: "Drake, John E" <[email-masked]>
>>>To: Igor Bryskin <[email-masked]>; Yakov Rekhter=20
>>><[email-masked]>; Lou Berger <[email-masked]>
>>>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel=20
>>><[email-masked]>; [email-masked]; [email-masked]
>>>Sent: Tuesday, September 2, 2008 2:24:26 PM
>>>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd
>>>question)
>>>
>>>Igor,
>>>
>>>Several years ago when OSPF was first proposed as an autodiscovery=20
>>>mechanism for L1VPNs, you were told that it was a bad idea=20
>due to its=20
>>>scaling properties and impact on the IGP.
>>>
>>>You are now tacitly agreeing with those who told you it was a
>>bad idea.
>>>
>>>For your suggested approach to work with sufficient redundancy, the=20
>>>topology of the overlay needs to be configured such that
>>every selected
>>>P router is connected to at least two other selected P routers and=20
>>>every PE router needs to be connected to at least two selected P=20
>>>routers.
>>>
>>>When you are done with this configuration, you are left with a=20
>>>situation in which *every* PE and selected P router will have
>>>*all* L1VPN routes.
>>>
>>>Thanks,
>>>
>>>John
>>>
>>>>-----Original Message-----
>>>>From: Igor Bryskin [mailto:[email-masked]]
>>>>Sent: Friday, August 29, 2008 12:10 PM
>>>>To: Drake, John E; Yakov Rekhter; Lou Berger
>>>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked];=20
>>>>[email-masked]
>>>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
>>>>question)
>>>>
>>>>Are you calling me silly? Are you coming to Minneapolis? :=3D)
>>>>
>>>>Seriously, what is wrong in your opinion with this approach?=20
>>>>Many people are talking about multi-instance IGPs. What=20
>they have in=20
>>>>mind is improving the IGP scalability:
>>>>a) by removing non-IP advertisements from the instance of IGP that=20
>>>>manages IP routing/forwarding tables into separate IGP instance(s);
>>>>b) by distributing non-IP information only to and via
>>>inerested parties
>>>>leaving the bulk of Ps out of the process.
>>>>
>>>>In my opinion this is exactly what is needed for the
>>OSPF-based L1VPN
>>>>application.
>>>>
>>>>Igor
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>----- Original Message ----
>>>>From: "Drake, John E" <[email-masked]>
>>>>To: Igor Bryskin <[email-masked]>; Yakov Rekhter=20
>>>><[email-masked]>; Lou Berger <[email-masked]>
>>>>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel=20
>>>><[email-masked]>; [email-masked]; [email-masked]
>>>>Sent: Friday, August 29, 2008 2:31:36 PM
>>>>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd
>>>>question)
>>>>
>>>>So you are proposing an OSPF route reflector?  At what point
>>does the
>>>>silliness stop?
>>>>
>>>>>-----Original Message-----
>>>>>From: Igor Bryskin [mailto:[email-masked]]
>>>>>Sent: Friday, August 29, 2008 11:29 AM
>>>>>To: Drake, John E; Yakov Rekhter; Lou Berger
>>>>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked];=20
>>>>>[email-masked]
>>>>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
>>>>>question)
>>>>>
>>>>>Hi John,
>>>>>
>>>>>No, not really. When you add a PE you configure local
>>>>interfaces, local
>>>>>VPN port mappings, stuff like that. While doing this you will also=20
>>>>>configure an IPinIP tunnel to one of your spoke Ps and=20
>enable L1VPN=20
>>>>>OSPF instance on the tunnel.
>>>>>Once you did that the local VPN information will be flooded
>>>>accross the
>>>>>overlay, likewise, the new PE will get all the necessary
>>information
>>>>>from other PEs.
>>>>>
>>>>>Cheers,
>>>>>Igor
>>>>>
>>>>>
>>>>>----- Original Message ----
>>>>>From: "Drake, John E" <[email-masked]>
>>>>>To: Igor Bryskin <[email-masked]>; Yakov Rekhter=20
>>>>><[email-masked]>; Lou Berger <[email-masked]>
>>>>>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel=20
>>>>><[email-masked]>; [email-masked]; [email-masked]
>>>>>Sent: Friday, August 29, 2008 11:20:16 AM
>>>>>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd
>>>>>question)
>>>>>
>>>>>Igor,
>>>>>
>>>>>Doesn't this defeat auto-discovery?  I.e., how is a new PE
>>>added to a
>>>>>given L1VPN?
>>>>>
>>>>>Thanks,
>>>>>
>>>>>John
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Igor Bryskin [mailto:[email-masked]]
>>>>>>Sent: Friday, August 29, 2008 5:51 AM
>>>>>>To: Yakov Rekhter; Lou Berger
>>>>>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked];=20
>>>>>>[email-masked]
>>>>>>Subject: Re: [Softwires] BGP TE attr last call by=20
>softwires WG (2nd
>>>>>>question)
>>>>>>
>>>>>>Yakov,
>>>>>>
>>>>>>You said:
>>>>>>
>>>>>>
>>>>>>... And while on the subject of scaling, please keep in mind
>>>>that BGP
>>>>>>only stores L1VPN routes on PEs that have sites of that VPN
>>>>connected
>>>>>>to them, and on an RR if used, but *not* on any of the P
>>>routers. In
>>>>>>contrast, rfc5252 (OSPF for L1VPN
>>>>>>autodiscovery) results in storing *all VPN TE information
>>>for all the
>>>>>>VPNs* on *all* the IGP nodes, both P and PE. So, clearly=20
>BGP-based=20
>>>>>>approach scales better than OSPF-based approach.
>>>>>>
>>>>>>Yakov.
>>>>>>
>>>>>>This is not true in case of multi-instance OSPF: one can build an=20
>>>>>>overlay interconnecting PEs via one or small number of Ps
>>>>>using IPinIP
>>>>>>tunnels and run in this overlay an instance of OSPF specifically=20
>>>>>>designated for distribution of L1VPN information. In this
>>>>>case the OSPF
>>>>>>solution won't scale any worse than the BGP approach. Note.=20
>>>>>that rfc252
>>>>>>never said that the instance of OSPF used for flooding of
>>the L1VPN
>>>>>>information must be the same instance that is used for the
>>>>>distribution
>>>>>>of IP-related LSAs.
>>>>>>
>>>>>>Regards,
>>>>>>Igor
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>

Delivery-date: Wed, 03 Sep 2008 14:49:16 +0000
Date: Wed, 3 Sep 2008 07:45:10 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)
To: "Drake, John E" <[email-masked]>, Yakov Rekhter <[email-masked]>, Lou Berger <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked], [email-masked]

--0-2133473847-1220453110=:45414
Content-Type: text/plain; charset=us-ascii

John,

See in-line.

----- Original Message ----
From: "Drake, John E" <[email-masked]>
To: Igor Bryskin <[email-masked]>; Yakov Rekhter <[email-masked]>; Lou Berger <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel <[email-masked]>; [email-masked]; [email-masked]
Sent: Wednesday, September 3, 2008 10:01:29 AM
Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)

Igor,

I'm sorry, but you were the one that stipulated P routers.  I mentioned
the more general requirement in my last e-mail:  "every PE router needs
to have connectivity to two other routers in the IGP instance".

The points being that:

1) The configuration burden is twice what you claimed it to be.

IB>> I was told on many occasions that configuration of IPinIP tunnels requires a lesser burden than configuring BGP sessions

2)  Every PE router in the IGP instance has L1VPN routes that it doesn't
care about.

3)  The number of L1VPN routes that a given PE router doesn't care about
is probably greater than the number of L1VPN routes it does care about.

IB>> As I answered to Yakov if this proves to be a problem you can configure multiple overlays

Thanks,

John  

>-----Original Message-----
>From: Igor Bryskin [mailto:[email-masked]] 
>Sent: Wednesday, September 03, 2008 6:47 AM
>To: Drake, John E; Yakov Rekhter; Lou Berger
>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
>[email-masked]
>Subject: Re: [Softwires] BGP TE attr last call by softwires WG 
>(2nd question)
>
>And I am not arguing that sufficient redundancy must be 
>provided. However you said:
>>For your suggested approach to work with sufficient redundancy, the 
>>topology of the overlay needs to be configured such that 
>every selected 
>>P router is connected to at least two other selected P routers and 
>>every PE router needs to be connected to at least two selected P 
>>routers.
>
>If you just simply interconnect all VPN-aware PEs into a 
>single ring via IPinIP tunnels and run an instance of OSPF to 
>distribute VPN-related information between them, it will 
>provide sufficient redundancy and involve exactly *zero* Ps.
>So, I want you to drop your lecturing tone for a minute and 
>simply tell in what respect in your opinion this approach is 
>not perfect fo the L1VPN application. Otherwise, I am not 
>interested in this discussion any longer. I do like to hear 
>comments from other people.
>
>Igor 
>
>
>
>----- Original Message ----
>From: "Drake, John E" <[email-masked]>
>To: Igor Bryskin <[email-masked]>; Yakov Rekhter 
><[email-masked]>; Lou Berger <[email-masked]>
>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel 
><[email-masked]>; [email-masked]; [email-masked]
>Sent: Wednesday, September 3, 2008 8:10:07 AM
>Subject: RE: [Softwires] BGP TE attr last call by softwires WG 
>(2nd question)
>
>Igor,
>
>Actually, I am not sure that you do understand what I wrote, 
>because you are providing examples of the redundancy that I 
>specified - every PE router needs to have connectivity to two 
>other routers in the IGP instance.
>
>Thanks,
>
>John 
>
>>-----Original Message-----
>>From: Igor Bryskin [mailto:[email-masked]]
>>Sent: Tuesday, September 02, 2008 3:06 PM
>>To: Drake, John E; Yakov Rekhter; Lou Berger
>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
>>[email-masked]
>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd 
>>question)
>>
>>Hi John,
>>
>>I understand what you are saying and disagree. The overlay I 
>am talking 
>>about logically is a separate network and as any network it should be 
>>sufficiently redundant to function. There is a number of ways how you 
>>can address the redundancy concerns. Look at the examples below:
>>
>>a) interconnect all VPN-aware PEs into a single ring: 
>>PE=======PE
>> ||                  ||
>>PE              PE 
>>||                  ||
>>PE              PE 
>>||                  ||
>>...                ....
>>PE=======PE
>>
>>b) connect each PE to two interconnected Ps
>>
>>PE              P                PE
>>                    ||                  
>>PE              ||                  PE 
>>                    ||                  
>>PE              ||                  PE 
>>                    ||                  
>>...                ||                  ....
>>PE              P                PE
>>
>>
>>Note that tunnels can traverse any number of VPN-unaware Ps and PEs.
>>
>>Igor
>>
>>
>>----- Original Message ----
>>From: "Drake, John E" <[email-masked]>
>>To: Igor Bryskin <[email-masked]>; Yakov Rekhter 
>><[email-masked]>; Lou Berger <[email-masked]>
>>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel 
>><[email-masked]>; [email-masked]; [email-masked]
>>Sent: Tuesday, September 2, 2008 2:24:26 PM
>>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd 
>>question)
>>
>>Igor,
>>
>>Several years ago when OSPF was first proposed as an autodiscovery 
>>mechanism for L1VPNs, you were told that it was a bad idea due to its 
>>scaling properties and impact on the IGP.
>>
>>You are now tacitly agreeing with those who told you it was a 
>bad idea.
>>
>>For your suggested approach to work with sufficient redundancy, the 
>>topology of the overlay needs to be configured such that 
>every selected 
>>P router is connected to at least two other selected P routers and 
>>every PE router needs to be connected to at least two selected P 
>>routers.
>>
>>When you are done with this configuration, you are left with a 
>>situation in which *every* PE and selected P router will have
>>*all* L1VPN routes.
>>
>>Thanks,
>>
>>John
>>
>>>-----Original Message-----
>>>From: Igor Bryskin [mailto:[email-masked]]
>>>Sent: Friday, August 29, 2008 12:10 PM
>>>To: Drake, John E; Yakov Rekhter; Lou Berger
>>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
>>>[email-masked]
>>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
>>>question)
>>>
>>>Are you calling me silly? Are you coming to Minneapolis? :=)
>>>
>>>Seriously, what is wrong in your opinion with this approach? 
>>>Many people are talking about multi-instance IGPs. What they have in 
>>>mind is improving the IGP scalability:
>>>a) by removing non-IP advertisements from the instance of IGP that 
>>>manages IP routing/forwarding tables into separate IGP instance(s);
>>>b) by distributing non-IP information only to and via
>>inerested parties
>>>leaving the bulk of Ps out of the process.
>>>
>>>In my opinion this is exactly what is needed for the 
>OSPF-based L1VPN 
>>>application.
>>>
>>>Igor
>>>
>>>
>>>
>>>
>>>
>>>
>>>----- Original Message ----
>>>From: "Drake, John E" <[email-masked]>
>>>To: Igor Bryskin <[email-masked]>; Yakov Rekhter 
>>><[email-masked]>; Lou Berger <[email-masked]>
>>>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel 
>>><[email-masked]>; [email-masked]; [email-masked]
>>>Sent: Friday, August 29, 2008 2:31:36 PM
>>>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd
>>>question)
>>>
>>>So you are proposing an OSPF route reflector?  At what point 
>does the 
>>>silliness stop?
>>>
>>>>-----Original Message-----
>>>>From: Igor Bryskin [mailto:[email-masked]]
>>>>Sent: Friday, August 29, 2008 11:29 AM
>>>>To: Drake, John E; Yakov Rekhter; Lou Berger
>>>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
>>>>[email-masked]
>>>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
>>>>question)
>>>>
>>>>Hi John,
>>>>
>>>>No, not really. When you add a PE you configure local
>>>interfaces, local
>>>>VPN port mappings, stuff like that. While doing this you will also 
>>>>configure an IPinIP tunnel to one of your spoke Ps and enable L1VPN 
>>>>OSPF instance on the tunnel.
>>>>Once you did that the local VPN information will be flooded
>>>accross the
>>>>overlay, likewise, the new PE will get all the necessary 
>information 
>>>>from other PEs.
>>>>
>>>>Cheers,
>>>>Igor
>>>>
>>>>
>>>>----- Original Message ----
>>>>From: "Drake, John E" <[email-masked]>
>>>>To: Igor Bryskin <[email-masked]>; Yakov Rekhter 
>>>><[email-masked]>; Lou Berger <[email-masked]>
>>>>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel 
>>>><[email-masked]>; [email-masked]; [email-masked]
>>>>Sent: Friday, August 29, 2008 11:20:16 AM
>>>>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd
>>>>question)
>>>>
>>>>Igor,
>>>>
>>>>Doesn't this defeat auto-discovery?  I.e., how is a new PE
>>added to a
>>>>given L1VPN?
>>>>
>>>>Thanks,
>>>>
>>>>John
>>>>
>>>>>-----Original Message-----
>>>>>From: Igor Bryskin [mailto:[email-masked]]
>>>>>Sent: Friday, August 29, 2008 5:51 AM
>>>>>To: Yakov Rekhter; Lou Berger
>>>>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
>>>>>[email-masked]
>>>>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
>>>>>question)
>>>>>
>>>>>Yakov,
>>>>>
>>>>>You said:
>>>>>
>>>>>
>>>>>... And while on the subject of scaling, please keep in mind
>>>that BGP
>>>>>only stores L1VPN routes on PEs that have sites of that VPN
>>>connected
>>>>>to them, and on an RR if used, but *not* on any of the P
>>routers. In
>>>>>contrast, rfc5252 (OSPF for L1VPN
>>>>>autodiscovery) results in storing *all VPN TE information
>>for all the
>>>>>VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based 
>>>>>approach scales better than OSPF-based approach.
>>>>>
>>>>>Yakov.
>>>>>
>>>>>This is not true in case of multi-instance OSPF: one can build an 
>>>>>overlay interconnecting PEs via one or small number of Ps
>>>>using IPinIP
>>>>>tunnels and run in this overlay an instance of OSPF specifically 
>>>>>designated for distribution of L1VPN information. In this
>>>>case the OSPF
>>>>>solution won't scale any worse than the BGP approach. Note. 
>>>>that rfc252
>>>>>never said that the instance of OSPF used for flooding of 
>the L1VPN 
>>>>>information must be the same instance that is used for the
>>>>distribution
>>>>>of IP-related LSAs.
>>>>>
>>>>>Regards,
>>>>>Igor
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>

--0-2133473847-1220453110=:45414
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div>John,<br><br>See in-line.<br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;">----- Original Message ----<br>From: "Drake, John E" &lt;[email-masked]&gt;<br>To: Igor Bryskin &lt;[email-masked]&gt;; Yakov Rekhter &lt;[email-masked]&gt;; Lou Berger &lt;[email-masked]&gt;<br>Cc: Yakov Rekhter &lt;[email-masked]&gt;; Adrian Farrel &lt;[email-masked]&gt;; [email-masked]; [email-masked]<br>Sent: Wednesday, September 3, 2008 10:01:29 AM<br>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)<br><br>
Igor,<br><br>I'm sorry, but you were the one that stipulated P routers.&nbsp; I mentioned<br>the more general requirement in my last e-mail:&nbsp; "every PE router needs<br>to have connectivity to two other routers in the IGP instance".<br><br>The points being that:<br><br>1) The configuration burden is twice what you claimed it to be.<br><br>IB&gt;&gt; I was told on many occasions that configuration of IPinIP tunnels requires a lesser burden than configuring BGP sessions<br><br>2)&nbsp; Every PE router in the IGP instance has L1VPN routes that it doesn't<br>care about.<br><br>3)&nbsp; The number of L1VPN routes that a given PE router doesn't care about<br>is probably greater than the number of L1VPN routes it does care about.<br><br>IB&gt;&gt; As I answered to Yakov if this proves to be a problem you can configure multiple overlays<br><br>Thanks,<br><br>John&nbsp; <br><br>&gt;-----Original Message-----<br>&gt;From: Igor Bryskin [mailto:<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>] <br>&gt;Sent: Wednesday, September 03, 2008 6:47 AM<br>&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG <br>&gt;(2nd question)<br>&gt;<br>&gt;And I am not arguing that sufficient redundancy must be <br>&gt;provided. However you said:<br>&gt;&gt;For your suggested approach to work with sufficient redundancy, the <br>&gt;&gt;topology of the overlay needs to be configured such that <br>&gt;every selected <br>&gt;&gt;P router is connected to at least two other selected P routers and <br>&gt;&gt;every PE router needs to be connected to at least two selected P
 <br>&gt;&gt;routers.<br>&gt;<br>&gt;If you just simply interconnect all VPN-aware PEs into a <br>&gt;single ring via IPinIP tunnels and run an instance of OSPF to <br>&gt;distribute VPN-related information between them, it will <br>&gt;provide sufficient redundancy and involve exactly *zero* Ps.<br>&gt;So, I want you to drop your lecturing tone for a minute and <br>&gt;simply tell in what respect in your opinion this approach is <br>&gt;not perfect fo the L1VPN application. Otherwise, I am not <br>&gt;interested in this discussion any longer. I do like to hear <br>&gt;comments from other people.<br>&gt;<br>&gt;Igor <br>&gt;<br>&gt;<br>&gt;<br>&gt;----- Original Message ----<br>&gt;From: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;;
 Yakov Rekhter <br>&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;Cc: Yakov Rekhter &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian Farrel <br>&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;Sent: Wednesday, September 3, 2008 8:10:07 AM<br>&gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG <br>&gt;(2nd question)<br>&gt;<br>&gt;Igor,<br>&gt;<br>&gt;Actually, I am not sure that you do understand what I wrote, <br>&gt;because you are providing examples of
 the redundancy that I <br>&gt;specified - every PE router needs to have connectivity to two <br>&gt;other routers in the IGP instance.<br>&gt;<br>&gt;Thanks,<br>&gt;<br>&gt;John <br>&gt;<br>&gt;&gt;-----Original Message-----<br>&gt;&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>]<br>&gt;&gt;Sent: Tuesday, September 02, 2008 3:06 PM<br>&gt;&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt;&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>&gt;&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd <br>&gt;&gt;question)<br>&gt;&gt;<br>&gt;&gt;Hi John,<br>&gt;&gt;<br>&gt;&gt;I understand what you are saying and disagree. The overlay I <br>&gt;am talking
 <br>&gt;&gt;about logically is a separate network and as any network it should be <br>&gt;&gt;sufficiently redundant to function. There is a number of ways how you <br>&gt;&gt;can address the redundancy concerns. Look at the examples below:<br>&gt;&gt;<br>&gt;&gt;a) interconnect all VPN-aware PEs into a single ring: <br>&gt;&gt;PE=======PE<br>&gt;&gt; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||<br>&gt;&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PE <br>&gt;&gt;||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||<br>&gt;&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PE <br>&gt;&gt;||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||<br>&gt;&gt;...&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ....<br>&gt;&gt;PE=======PE<br>&gt;&gt;<br>&gt;&gt;b) connect each PE to two interconnected Ps<br>&gt;&gt;<br>&gt;&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; P&nbsp; &nbsp;
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PE<br>&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>&gt;&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PE <br>&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>&gt;&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PE <br>&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>&gt;&gt;...&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ....<br>&gt;&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; P&nbsp; &nbsp;
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PE<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;Note that tunnels can traverse any number of VPN-unaware Ps and PEs.<br>&gt;&gt;<br>&gt;&gt;Igor<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;----- Original Message ----<br>&gt;&gt;From: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;&gt;To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;&gt;Cc: Yakov Rekhter &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian Farrel <br>&gt;&gt;&lt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;&gt;Sent: Tuesday, September 2, 2008 2:24:26 PM<br>&gt;&gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd <br>&gt;&gt;question)<br>&gt;&gt;<br>&gt;&gt;Igor,<br>&gt;&gt;<br>&gt;&gt;Several years ago when OSPF was first proposed as an autodiscovery <br>&gt;&gt;mechanism for L1VPNs, you were told that it was a bad idea due to its <br>&gt;&gt;scaling properties and impact on the IGP.<br>&gt;&gt;<br>&gt;&gt;You are now tacitly agreeing with those who told you it was a <br>&gt;bad idea.<br>&gt;&gt;<br>&gt;&gt;For your suggested approach to work with sufficient redundancy, the <br>&gt;&gt;topology of the overlay needs to be configured such that <br>&gt;every selected <br>&gt;&gt;P
 router is connected to at least two other selected P routers and <br>&gt;&gt;every PE router needs to be connected to at least two selected P <br>&gt;&gt;routers.<br>&gt;&gt;<br>&gt;&gt;When you are done with this configuration, you are left with a <br>&gt;&gt;situation in which *every* PE and selected P router will have<br>&gt;&gt;*all* L1VPN routes.<br>&gt;&gt;<br>&gt;&gt;Thanks,<br>&gt;&gt;<br>&gt;&gt;John<br>&gt;&gt;<br>&gt;&gt;&gt;-----Original Message-----<br>&gt;&gt;&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>]<br>&gt;&gt;&gt;Sent: Friday, August 29, 2008 12:10 PM<br>&gt;&gt;&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt;&gt;&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>&gt;&gt;&gt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a><br>&gt;&gt;&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd<br>&gt;&gt;&gt;question)<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Are you calling me silly? Are you coming to Minneapolis? :=)<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Seriously, what is wrong in your opinion with this approach? <br>&gt;&gt;&gt;Many people are talking about multi-instance IGPs. What they have in <br>&gt;&gt;&gt;mind is improving the IGP scalability:<br>&gt;&gt;&gt;a) by removing non-IP advertisements from the instance of IGP that <br>&gt;&gt;&gt;manages IP routing/forwarding tables into separate IGP instance(s);<br>&gt;&gt;&gt;b) by distributing non-IP information only to and via<br>&gt;&gt;inerested parties<br>&gt;&gt;&gt;leaving the bulk of Ps out of the process.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;In my opinion this is exactly what is needed for the <br>&gt;OSPF-based L1VPN
 <br>&gt;&gt;&gt;application.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Igor<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;----- Original Message ----<br>&gt;&gt;&gt;From: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;&gt;&gt;To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt;&gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;&gt;&gt;Cc: Yakov Rekhter &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian Farrel <br>&gt;&gt;&gt;&lt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;&gt;&gt;Sent: Friday, August 29, 2008 2:31:36 PM<br>&gt;&gt;&gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd<br>&gt;&gt;&gt;question)<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;So you are proposing an OSPF route reflector?&nbsp; At what point <br>&gt;does the <br>&gt;&gt;&gt;silliness stop?<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;-----Original Message-----<br>&gt;&gt;&gt;&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>]<br>&gt;&gt;&gt;&gt;Sent: Friday, August 29, 2008 11:29 AM<br>&gt;&gt;&gt;&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt;&gt;&gt;&gt;Cc: Yakov Rekhter; Adrian Farrel; <a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>&gt;&gt;&gt;&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;&gt;&gt;&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd<br>&gt;&gt;&gt;&gt;question)<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;Hi John,<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;No, not really. When you add a PE you configure local<br>&gt;&gt;&gt;interfaces, local<br>&gt;&gt;&gt;&gt;VPN port mappings, stuff like that. While doing this you will also <br>&gt;&gt;&gt;&gt;configure an IPinIP tunnel to one of your spoke Ps and enable L1VPN <br>&gt;&gt;&gt;&gt;OSPF instance on the tunnel.<br>&gt;&gt;&gt;&gt;Once you did that the local VPN information will be flooded<br>&gt;&gt;&gt;accross the<br>&gt;&gt;&gt;&gt;overlay, likewise, the new PE will get all the necessary <br>&gt;information <br>&gt;&gt;&gt;&gt;from other
 PEs.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;Cheers,<br>&gt;&gt;&gt;&gt;Igor<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;----- Original Message ----<br>&gt;&gt;&gt;&gt;From: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;&gt;&gt;&gt;To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt;&gt;&gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;&gt;&gt;&gt;Cc: Yakov Rekhter &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian Farrel <br>&gt;&gt;&gt;&gt;&lt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;&gt;&gt;&gt;Sent: Friday, August 29, 2008 11:20:16 AM<br>&gt;&gt;&gt;&gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd<br>&gt;&gt;&gt;&gt;question)<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;Igor,<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;Doesn't this defeat auto-discovery?&nbsp; I.e., how is a new PE<br>&gt;&gt;added to a<br>&gt;&gt;&gt;&gt;given L1VPN?<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;Thanks,<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;John<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;-----Original Message-----<br>&gt;&gt;&gt;&gt;&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>]<br>&gt;&gt;&gt;&gt;&gt;Sent: Friday, August 29, 2008 5:51 AM<br>&gt;&gt;&gt;&gt;&gt;To: Yakov Rekhter; Lou Berger<br>&gt;&gt;&gt;&gt;&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>&gt;&gt;&gt;&gt;&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;&gt;&gt;&gt;&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd<br>&gt;&gt;&gt;&gt;&gt;question)<br>&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;Yakov,<br>&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;You said:<br>&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;... And while on the subject of scaling, please keep in mind<br>&gt;&gt;&gt;that BGP<br>&gt;&gt;&gt;&gt;&gt;only stores L1VPN routes on PEs that have sites of that
 VPN<br>&gt;&gt;&gt;connected<br>&gt;&gt;&gt;&gt;&gt;to them, and on an RR if used, but *not* on any of the P<br>&gt;&gt;routers. In<br>&gt;&gt;&gt;&gt;&gt;contrast, rfc5252 (OSPF for L1VPN<br>&gt;&gt;&gt;&gt;&gt;autodiscovery) results in storing *all VPN TE information<br>&gt;&gt;for all the<br>&gt;&gt;&gt;&gt;&gt;VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based <br>&gt;&gt;&gt;&gt;&gt;approach scales better than OSPF-based approach.<br>&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;Yakov.<br>&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;This is not true in case of multi-instance OSPF: one can build an <br>&gt;&gt;&gt;&gt;&gt;overlay interconnecting PEs via one or small number of Ps<br>&gt;&gt;&gt;&gt;using IPinIP<br>&gt;&gt;&gt;&gt;&gt;tunnels and run in this overlay an instance of OSPF specifically <br>&gt;&gt;&gt;&gt;&gt;designated for distribution of L1VPN information. In this<br>&gt;&gt;&gt;&gt;case the
 OSPF<br>&gt;&gt;&gt;&gt;&gt;solution won't scale any worse than the BGP approach. Note. <br>&gt;&gt;&gt;&gt;that rfc252<br>&gt;&gt;&gt;&gt;&gt;never said that the instance of OSPF used for flooding of <br>&gt;the L1VPN <br>&gt;&gt;&gt;&gt;&gt;information must be the same instance that is used for the<br>&gt;&gt;&gt;&gt;distribution<br>&gt;&gt;&gt;&gt;&gt;of IP-related LSAs.<br>&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;Regards,<br>&gt;&gt;&gt;&gt;&gt;Igor<br>&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;<br>&gt;<br>&gt;<br>&gt;<br><br></div></div></div><br>

      </body></html>
--0-2133473847-1220453110=:45414--

Delivery-date: Wed, 03 Sep 2008 14:42:15 +0000
Date: Wed, 3 Sep 2008 07:37:42 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)
To: Yakov Rekhter <[email-masked]>
Cc: "Drake, John E" <[email-masked]>, Lou Berger <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked], [email-masked]

--0-1852435290-1220452662=:19087
Content-Type: text/plain; charset=us-ascii

Yaokov,

Please,  see in-line.

----- Original Message ----
From: Yakov Rekhter <[email-masked]>
To: Igor Bryskin <[email-masked]>
Cc: "Drake, John E" <[email-masked]>; Lou Berger <[email-masked]>; Adrian Farrel <[email-masked]>; [email-masked]; [email-masked]
Sent: Wednesday, September 3, 2008 9:55:49 AM
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) 

Igor,

> And I am not arguing that sufficient redundancy must be provided. However you
> said:
> >For your suggested approach to work with sufficient 
> >redundancy, the topology of the overlay needs to be configured 
> >such that every selected P router is connected to at least two 
> >other selected P routers and every PE router needs to be 
> >connected to at least two selected P routers.
> 
> If you just simply interconnect all VPN-aware PEs into a single
> ring via IPin IP tunnels and run an instance of OSPF to distribute
> VPN-related information between them, it will provide sufficient
> redundancy and involve exactly *zero* Ps.
>
> So, I want you to drop your lecturing tone for a minute and simply
> tell in what respect in your opinion this approach is not perfect
> fo the L1VPN application. Otherwise, I am not interested in this
> discussion any longer. I do like to hear comments from other people.

Since you asked, one problem with using OSPF, as John correctly
pointed out, is that you are left with a situation in which *every* PE 
router will have *all* L1VPN routes for all the L1VPNs. Of course, 
this is "perfect" in a sense that you can do no worse than that :-)

IB>> Ok. Several points here. Note that neither Ps nor VPN-unaware PEs participate in the distribution/maintenance of VPN information, which is already significantly better than what you said about the OSPF solution in your previous mail:

>... And while on the subject of scaling, please keep in mind that BGP
>   only stores L1VPN routes on PEs that have sites of that VPN
>   connected to them, and on an RR if used, but *not* on any of the P 
>   routers. In contrast, rfc5252 (OSPF for L1VPN
>   autodiscovery) results in storing *all VPN TE information 
>   for all the VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based 
>   approach scales better than OSPF-based approach.

> >>>>Yakov.

I do agree that if you use a single ring overlay interconnecting all VPN aware PEs you will have LSDBs at all PEs contain VPN info about all VPNs. However, in case of L1VPN this is not VPN routes, rather VPN Provider-To-Customer port mappings which I believe will prove to be sugnifficantly smaller, so I am not sure yet how bad is that. In any case, if it does present a problem on a network with large number of VPNs, who said that it has to be a single overlay? Why not to configure several overlays - each containing a single ring that interconnects PEs participating in a common sub-set of VPNs, and run a seperate instance of OSPF in each overlay?

Igor

> 
> 
> 
> 
> ----- Original Message ----
> From: "Drake, John E" <[email-masked]>
> To: Igor Bryskin <[email-masked]>; Yakov Rekhter <[email-masked]>; Lo
u Berger <[email-masked]>
> Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel <[email-masked]>; c
[email-masked]; [email-masked]
> Sent: Wednesday, September 3, 2008 8:10:07 AM
> Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)
> 
> Igor,
> 
> Actually, I am not sure that you do understand what I wrote, because you
> are providing examples of the redundancy that I specified - every PE
> router needs to have connectivity to two other routers in the IGP
> instance.
> 
> Thanks,
> 
> John 
> 
> >-----Original Message-----
> >From: Igor Bryskin [mailto:[email-masked]] 
> >Sent: Tuesday, September 02, 2008 3:06 PM
> >To: Drake, John E; Yakov Rekhter; Lou Berger
> >Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
> >[email-masked]
> >Subject: Re: [Softwires] BGP TE attr last call by softwires WG 
> >(2nd question)
> >
> >Hi John,
> >
> >I understand what you are saying and disagree. The overlay I 
> >am talking about logically is a separate network and as any 
> >network it should be sufficiently redundant to function. There 
> >is a number of ways how you can address the redundancy 
> >concerns. Look at the examples below:
> >
> >a) interconnect all VPN-aware PEs into a single ring: 
> >PE=======PE
> > ||                  ||
> >PE               PE 
> >||                   ||
> >PE               PE 
> >||                   ||
> >...                ....
> >PE=======PE
> >
> >b) connect each PE to two interconnected Ps 
> >
> >PE               P                 PE
> >                    ||                  
> >PE               ||                  PE 
> >                    ||                  
> >PE               ||                  PE 
> >                    ||                  
> >...                 ||                   ....
> >PE               P                 PE
> >
> >
> >Note that tunnels can traverse any number of VPN-unaware Ps and PEs.
> >
> >Igor
> >
> >
> >----- Original Message ----
> >From: "Drake, John E" <[email-masked]>
> >To: Igor Bryskin <[email-masked]>; Yakov Rekhter 
> ><[email-masked]>; Lou Berger <[email-masked]>
> >Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel 
> ><[email-masked]>; [email-masked]; [email-masked]
> >Sent: Tuesday, September 2, 2008 2:24:26 PM
> >Subject: RE: [Softwires] BGP TE attr last call by softwires WG 
> >(2nd question)
> >
> >Igor,
> >
> >Several years ago when OSPF was first proposed as an 
> >autodiscovery mechanism for L1VPNs, you were told that it was 
> >a bad idea due to its scaling properties and impact on the IGP.
> >
> >You are now tacitly agreeing with those who told you it was a bad idea.
> >
> >For your suggested approach to work with sufficient 
> >redundancy, the topology of the overlay needs to be configured 
> >such that every selected P router is connected to at least two 
> >other selected P routers and every PE router needs to be 
> >connected to at least two selected P routers.
> >
> >When you are done with this configuration, you are left with a 
> >situation in which *every* PE and selected P router will have 
> >*all* L1VPN routes.
> >
> >Thanks,
> >
> >John 
> >
> >>-----Original Message-----
> >>From: Igor Bryskin [mailto:[email-masked]]
> >>Sent: Friday, August 29, 2008 12:10 PM
> >>To: Drake, John E; Yakov Rekhter; Lou Berger
> >>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
> >>[email-masked]
> >>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd 
> >>question)
> >>
> >>Are you calling me silly? Are you coming to Minneapolis? :=)
> >>
> >>Seriously, what is wrong in your opinion with this approach? 
> >>Many people are talking about multi-instance IGPs. What they have in 
> >>mind is improving the IGP scalability:
> >>a) by removing non-IP advertisements from the instance of IGP that 
> >>manages IP routing/forwarding tables into separate IGP instance(s);
> >>b) by distributing non-IP information only to and via 
> >inerested parties 
> >>leaving the bulk of Ps out of the process.
> >>
> >>In my opinion this is exactly what is needed for the OSPF-based L1VPN 
> >>application.
> >>
> >>Igor
> >>
> >>
> >>
> >>
> >>
> >>
> >>----- Original Message ----
> >>From: "Drake, John E" <[email-masked]>
> >>To: Igor Bryskin <[email-masked]>; Yakov Rekhter 
> >><[email-masked]>; Lou Berger <[email-masked]>
> >>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel 
> >><[email-masked]>; [email-masked]; [email-masked]
> >>Sent: Friday, August 29, 2008 2:31:36 PM
> >>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd 
> >>question)
> >>
> >>So you are proposing an OSPF route reflector?  At what point does the 
> >>silliness stop?
> >>
> >>>-----Original Message-----
> >>>From: Igor Bryskin [mailto:[email-masked]]
> >>>Sent: Friday, August 29, 2008 11:29 AM
> >>>To: Drake, John E; Yakov Rekhter; Lou Berger
> >>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
> >>>[email-masked]
> >>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
> >>>question)
> >>>
> >>>Hi John,
> >>>
> >>>No, not really. When you add a PE you configure local
> >>interfaces, local
> >>>VPN port mappings, stuff like that. While doing this you will also 
> >>>configure an IPinIP tunnel to one of your spoke Ps and enable L1VPN 
> >>>OSPF instance on the tunnel.
> >>>Once you did that the local VPN information will be flooded
> >>accross the
> >>>overlay, likewise, the new PE will get all the necessary information 
> >>>from other PEs.
> >>>
> >>>Cheers,
> >>>Igor
> >>>
> >>>
> >>>----- Original Message ----
> >>>From: "Drake, John E" <[email-masked]>
> >>>To: Igor Bryskin <[email-masked]>; Yakov Rekhter 
> >>><[email-masked]>; Lou Berger <[email-masked]>
> >>>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel 
> >>><[email-masked]>; [email-masked]; [email-masked]
> >>>Sent: Friday, August 29, 2008 11:20:16 AM
> >>>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd
> >>>question)
> >>>
> >>>Igor,
> >>>
> >>>Doesn't this defeat auto-discovery?  I.e., how is a new PE 
> >added to a 
> >>>given L1VPN?
> >>>
> >>>Thanks,
> >>>
> >>>John
> >>>
> >>>>-----Original Message-----
> >>>>From: Igor Bryskin [mailto:[email-masked]]
> >>>>Sent: Friday, August 29, 2008 5:51 AM
> >>>>To: Yakov Rekhter; Lou Berger
> >>>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
> >>>>[email-masked]
> >>>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
> >>>>question)
> >>>>
> >>>>Yakov,
> >>>>
> >>>>You said:
> >>>>
> >>>>
> >>>>... And while on the subject of scaling, please keep in mind
> >>that BGP
> >>>>only stores L1VPN routes on PEs that have sites of that VPN
> >>connected
> >>>>to them, and on an RR if used, but *not* on any of the P 
> >routers. In 
> >>>>contrast, rfc5252 (OSPF for L1VPN
> >>>>autodiscovery) results in storing *all VPN TE information 
> >for all the
> >>>>VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based 
> >>>>approach scales better than OSPF-based approach.
> >>>>
> >>>>Yakov.
> >>>>
> >>>>This is not true in case of multi-instance OSPF: one can build an 
> >>>>overlay interconnecting PEs via one or small number of Ps
> >>>using IPinIP
> >>>>tunnels and run in this overlay an instance of OSPF specifically 
> >>>>designated for distribution of L1VPN information. In this
> >>>case the OSPF
> >>>>solution won't scale any worse than the BGP approach. Note. 
> >>>that rfc252
> >>>>never said that the instance of OSPF used for flooding of the L1VPN 
> >>>>information must be the same instance that is used for the
> >>>distribution
> >>>>of IP-related LSAs.
> >>>>
> >>>>Regards,
> >>>>Igor
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> >
> 
> 
>      
> --0-1141253910-1220449648=:97601
> Content-Type: text/html; charset=us-ascii
> 
> <html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><
body><div style="font-family:times new roman, new york, times, serif;font-size:
12pt"><div>And I am not arguing that sufficient redundancy must be provided. Ho
wever you said:<br>&gt;For your suggested approach to work with sufficient <br>
&gt;redundancy, the topology of the overlay needs to be configured <br>&gt;such
that every selected P router is connected to at least two <br>&gt;other select
ed P routers and every PE router needs to be <br>&gt;connected to at least two 
selected P routers.<br><br>If you just simply interconnect all VPN-aware PEs in
to a single ring via IPinIP tunnels and run an instance of OSPF to distribute V
PN-related information between them, it will provide sufficient redundancy and 
involve exactly *zero* Ps.<br>So, I want you to drop your lecturing tone for a 
minute and simply tell in what respect in your opinion this approach is not per
fect fo the L1VPN
>  application. Otherwise, I am not interested in this discussion any longer. I
do like to hear comments from other people.<br><br>Igor <br><br></div><div sty
le="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><d
iv style="font-family: arial,helvetica,sans-serif; font-size: 13px;">----- Orig
inal Message ----<br>From: "Drake, John E" &lt;[email-masked]&gt;<br>
To: Igor Bryskin &lt;[email-masked]&gt;; Yakov Rekhter &lt;[email-masked]
et&gt;; Lou Berger &lt;[email-masked]&gt;<br>Cc: Yakov Rekhter &lt;yakov@juni
per.net&gt;; Adrian Farrel &lt;[email-masked]&gt;; [email-masked]; sof
[email-masked]<br>Sent: Wednesday, September 3, 2008 8:10:07 AM<br>Subject: RE
: [Softwires] BGP TE attr last call by softwires WG (2nd question)<br><br>
> Igor,<br><br>Actually, I am not sure that you do understand what I wrote, bec
ause you<br>are providing examples of the redundancy that I specified - every P
E<br>router needs to have connectivity to two other routers in the IGP<br>insta
nce.<br><br>Thanks,<br><br>John <br><br>&gt;-----Original Message-----<br>&gt;F
rom: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href="mailto:
[email-masked]">[email-masked]</a>] <br>&gt;Sent: Tuesday, September 
02, 2008 3:06 PM<br>&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt;Cc:
Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mai
lto:[email-masked]">[email-masked]</a>; <br>&gt;<a ymailto="mailto:soft
[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;
Subject: Re: [Softwires] BGP TE attr last call by softwires WG <br>&gt;(2nd que
stion)<br>&gt;<br>&gt;Hi John,<br>&gt;<br>&gt;I understand what you are saying 
and disagree. The
>  overlay I <br>&gt;am talking about logically is a separate network and as an
y <br>&gt;network it should be sufficiently redundant to function. There <br>&g
t;is a number of ways how you can address the redundancy <br>&gt;concerns. Look
at the examples below:<br>&gt;<br>&gt;a) interconnect all VPN-aware PEs into a
single ring: <br>&gt;PE=======PE<br>&gt; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
&nbsp; &nbsp; &nbsp; &nbsp; ||<br>&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs
p; &nbsp;  PE <br>&gt;||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;  ||<br>&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  PE <br>&
gt;||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||<br>&gt;
...&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ....<br>&gt;PE======
=PE<br>&gt;<br>&gt;b) connect each PE to two interconnected Ps <br>&gt;<br>&gt;
PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  P&nbsp; &nbsp; &nbsp; &nbsp
; &nbsp; &nbsp; &nbsp;
>  &nbsp;  PE<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n
bsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  <
br>&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||&nbsp; &nbsp; &nbs
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PE <br>&gt;&nbsp; &nbsp; &nbsp; &n
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &n
bsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &
nbsp; &nbsp;  ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
PE <br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp
; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>&gt;...&
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||&nbsp; &nbsp; &nbsp; 
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ....<br>&gt;PE&nbsp; &nbsp; &nbsp; &
nbsp; &nbsp; &nbsp; &nbsp;  P&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &
nbsp; 
>  PE<br>&gt;<br>&gt;<br>&gt;Note that tunnels can traverse any number of VPN-u
naware Ps and PEs.<br>&gt;<br>&gt;Igor<br>&gt;<br>&gt;<br>&gt;----- Original Me
ssage ----<br>&gt;From: "Drake, John E" &lt;<a ymailto="mailto:John.E.Drake2@bo
eing.com" href="mailto:[email-masked]">[email-masked]</a>&g
t;<br>&gt;To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" href="ma
ilto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt;&l
t;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">yakov@j
uniper.net</a>&gt;; Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="m
ailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;Cc: Yakov Rekhter &lt;<
a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">yakov@juni
per.net</a>&gt;; Adrian Farrel <br>&gt;&lt;<a ymailto="mailto:[email-masked].
uk" href="mailto:[email-masked]">[email-masked]</a>&gt;; <a
>  ymailto="mailto:[email-masked]" href="mailto:[email-masked]">ccamp@o
ps.ietf.org</a>; <a ymailto="mailto:[email-masked]" href="mailto:softwires@
ietf.org">[email-masked]</a><br>&gt;Sent: Tuesday, September 2, 2008 2:24:2
6 PM<br>&gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG <br>
&gt;(2nd question)<br>&gt;<br>&gt;Igor,<br>&gt;<br>&gt;Several years ago when O
SPF was first proposed as an <br>&gt;autodiscovery mechanism for L1VPNs, you we
re told that it was <br>&gt;a bad idea due to its scaling properties and impact
on the IGP.<br>&gt;<br>&gt;You are now tacitly agreeing with those who told yo
u it was a bad idea.<br>&gt;<br>&gt;For your suggested approach to work with su
fficient <br>&gt;redundancy, the topology of the overlay needs to be configured
<br>&gt;such that every selected P router is connected to at least two <br>&gt
;other selected P routers and every PE router needs to be <br>&gt;connected to 
at least two selected
>  P routers.<br>&gt;<br>&gt;When you are done with this configuration, you are
left with a <br>&gt;situation in which *every* PE and selected P router will h
ave <br>&gt;*all* L1VPN routes.<br>&gt;<br>&gt;Thanks,<br>&gt;<br>&gt;John <br>
&gt;<br>&gt;&gt;-----Original Message-----<br>&gt;&gt;From: Igor Bryskin [mailt
o:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">i_b
[email-masked]</a>]<br>&gt;&gt;Sent: Friday, August 29, 2008 12:10 PM<br>&gt;
&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt;&gt;Cc: Yakov Rekhter; 
Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]
tf.org">[email-masked]</a>; <br>&gt;&gt;<a ymailto="mailto:[email-masked]
rg" href="mailto:[email-masked]">[email-masked]</a><br>&gt;&gt;Subject:
Re: [Softwires] BGP TE attr last call by softwires WG (2nd <br>&gt;&gt;questio
n)<br>&gt;&gt;<br>&gt;&gt;Are you calling me silly? Are you coming to Minneapol
is?
>  :=)<br>&gt;&gt;<br>&gt;&gt;Seriously, what is wrong in your opinion with thi
s approach? <br>&gt;&gt;Many people are talking about multi-instance IGPs. What
they have in <br>&gt;&gt;mind is improving the IGP scalability:<br>&gt;&gt;a) 
by removing non-IP advertisements from the instance of IGP that <br>&gt;&gt;man
ages IP routing/forwarding tables into separate IGP instance(s);<br>&gt;&gt;b) 
by distributing non-IP information only to and via <br>&gt;inerested parties <b
r>&gt;&gt;leaving the bulk of Ps out of the process.<br>&gt;&gt;<br>&gt;&gt;In 
my opinion this is exactly what is needed for the OSPF-based L1VPN <br>&gt;&gt;
application.<br>&gt;&gt;<br>&gt;&gt;Igor<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br
>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;----- Original Message ----<br>&gt
;&gt;From: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" hre
f="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;&gt
;To: Igor Bryskin
>  &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]
">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt;&gt;&lt;<a ymailto="mailto
:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; 
Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]
et">[email-masked]</a>&gt;<br>&gt;&gt;Cc: Yakov Rekhter &lt;<a ymailto="mailt
o:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;;
Adrian Farrel <br>&gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="ma
ilto:[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:ccamp
@ops.ietf.org" href="mailto:[email-masked]">[email-masked]</a>; <a ymai
lto="mailto:[email-masked]" href="mailto:[email-masked]">softwires@ietf
.org</a><br>&gt;&gt;Sent: Friday, August 29, 2008 2:31:36 PM<br>&gt;&gt;Subject
: RE: [Softwires] BGP TE attr last call by softwires WG (2nd
>  <br>&gt;&gt;question)<br>&gt;&gt;<br>&gt;&gt;So you are proposing an OSPF ro
ute reflector?&nbsp; At what point does the <br>&gt;&gt;silliness stop?<br>&gt;
&gt;<br>&gt;&gt;&gt;-----Original Message-----<br>&gt;&gt;&gt;From: Igor Bryski
n [mailto:<a ymailto="mailto:[email-masked]" href="mailto:i_bryskin@yahoo.
com">[email-masked]</a>]<br>&gt;&gt;&gt;Sent: Friday, August 29, 2008 11:2
9 AM<br>&gt;&gt;&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt;&gt;&gt
;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href=
"mailto:[email-masked]">[email-masked]</a>; <br>&gt;&gt;&gt;<a ymailto=
"mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]
</a><br>&gt;&gt;&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires
WG (2nd<br>&gt;&gt;&gt;question)<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Hi John,<br>&g
t;&gt;&gt;<br>&gt;&gt;&gt;No, not really. When you add a PE you configure
>  local<br>&gt;&gt;interfaces, local<br>&gt;&gt;&gt;VPN port mappings, stuff l
ike that. While doing this you will also <br>&gt;&gt;&gt;configure an IPinIP tu
nnel to one of your spoke Ps and enable L1VPN <br>&gt;&gt;&gt;OSPF instance on 
the tunnel.<br>&gt;&gt;&gt;Once you did that the local VPN information will be 
flooded<br>&gt;&gt;accross the<br>&gt;&gt;&gt;overlay, likewise, the new PE wil
l get all the necessary information <br>&gt;&gt;&gt;from other PEs.<br>&gt;&gt;
&gt;<br>&gt;&gt;&gt;Cheers,<br>&gt;&gt;&gt;Igor<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt;----- Original Message ----<br>&gt;&gt;&gt;From: "Drake, John E
" &lt;<a ymailto="mailto:[email-masked]" href="mailto:John.E.Drake2@b
oeing.com">[email-masked]</a>&gt;<br>&gt;&gt;&gt;To: Igor Bryskin &lt
;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">i_br
[email-masked]</a>&gt;; Yakov Rekhter <br>&gt;&gt;&gt;&lt;<a ymailto="mailto:y
[email-masked]"
>  href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;<a
ymailto="mailto:[email-masked]" href="mailto:[email-masked]">lberger@labn.
net</a>&gt;<br>&gt;&gt;&gt;Cc: Yakov Rekhter &lt;<a ymailto="mailto:yakov@junip
er.net" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian Farre
l <br>&gt;&gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:adri
[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:[email-masked]
.org" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="mail
to:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><
br>&gt;&gt;&gt;Sent: Friday, August 29, 2008 11:20:16 AM<br>&gt;&gt;&gt;Subject
: RE: [Softwires] BGP TE attr last call by softwires WG (2nd<br>&gt;&gt;&gt;que
stion)<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Igor,<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Does
n't this defeat auto-discovery?&nbsp; I.e., how is a new PE <br>&gt;added to a 
<br>&gt;&gt;&gt;given
>  L1VPN?<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Thanks,<br>&gt;&gt;&gt;<br>&gt;&gt;&gt
;John<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;-----Original Message-----<br>&gt;&gt;
&gt;&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href
="mailto:[email-masked]">[email-masked]</a>]<br>&gt;&gt;&gt;&gt;Sent:
Friday, August 29, 2008 5:51 AM<br>&gt;&gt;&gt;&gt;To: Yakov Rekhter; Lou Berg
er<br>&gt;&gt;&gt;&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:ccam
[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>&g
t;&gt;&gt;&gt;<a ymailto="mailto:[email-masked]" href="mailto:softwires@iet
f.org">[email-masked]</a><br>&gt;&gt;&gt;&gt;Subject: Re: [Softwires] BGP T
E attr last call by softwires WG (2nd<br>&gt;&gt;&gt;&gt;question)<br>&gt;&gt;&
gt;&gt;<br>&gt;&gt;&gt;&gt;Yakov,<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;You sa
id:<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;... And while on
the subject of
>  scaling, please keep in mind<br>&gt;&gt;that BGP<br>&gt;&gt;&gt;&gt;only sto
res L1VPN routes on PEs that have sites of that VPN<br>&gt;&gt;connected<br>&gt
;&gt;&gt;&gt;to them, and on an RR if used, but *not* on any of the P <br>&gt;r
outers. In <br>&gt;&gt;&gt;&gt;contrast, rfc5252 (OSPF for L1VPN<br>&gt;&gt;&gt
;&gt;autodiscovery) results in storing *all VPN TE information <br>&gt;for all 
the<br>&gt;&gt;&gt;&gt;VPNs* on *all* the IGP nodes, both P and PE. So, clearly
BGP-based <br>&gt;&gt;&gt;&gt;approach scales better than OSPF-based approach.
<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;Yakov.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&
gt;&gt;This is not true in case of multi-instance OSPF: one can build an <br>&g
t;&gt;&gt;&gt;overlay interconnecting PEs via one or small number of Ps<br>&gt;
&gt;&gt;using IPinIP<br>&gt;&gt;&gt;&gt;tunnels and run in this overlay an inst
ance of OSPF specifically <br>&gt;&gt;&gt;&gt;designated for distribution of L1
VPN information. In
>  this<br>&gt;&gt;&gt;case the OSPF<br>&gt;&gt;&gt;&gt;solution won't scale an
y worse than the BGP approach. Note. <br>&gt;&gt;&gt;that rfc252<br>&gt;&gt;&gt
;&gt;never said that the instance of OSPF used for flooding of the L1VPN <br>&g
t;&gt;&gt;&gt;information must be the same instance that is used for the<br>&gt
;&gt;&gt;distribution<br>&gt;&gt;&gt;&gt;of IP-related LSAs.<br>&gt;&gt;&gt;&gt
;<br>&gt;&gt;&gt;&gt;Regards,<br>&gt;&gt;&gt;&gt;Igor<br>&gt;&gt;&gt;&gt;<br>&g
t;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&
gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>
&gt;<br>&gt;<br>&gt;<br>&gt;<br><br></div></div></div><br>
> 
>       </body></html>
> --0-1141253910-1220449648=:97601--

--0-1852435290-1220452662=:19087
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div>Yaokov,<br><br>Please,&nbsp; see in-line.<br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;">----- Original Message ----<br>From: Yakov Rekhter &lt;[email-masked]&gt;<br>To: Igor Bryskin &lt;[email-masked]&gt;<br>Cc: "Drake, John E" &lt;[email-masked]&gt;; Lou Berger &lt;[email-masked]&gt;; Adrian Farrel &lt;[email-masked]&gt;; [email-masked]; [email-masked]<br>Sent: Wednesday, September 3, 2008 9:55:49 AM<br>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) <br><br>
Igor,<br><br>&gt; And I am not arguing that sufficient redundancy must be provided. However you<br>&gt; said:<br>&gt; &gt;For your suggested approach to work with sufficient <br>&gt; &gt;redundancy, the topology of the overlay needs to be configured <br>&gt; &gt;such that every selected P router is connected to at least two <br>&gt; &gt;other selected P routers and every PE router needs to be <br>&gt; &gt;connected to at least two selected P routers.<br>&gt; <br>&gt; If you just simply interconnect all VPN-aware PEs into a single<br>&gt; ring via IPin IP tunnels and run an instance of OSPF to distribute<br>&gt; VPN-related information between them, it will provide sufficient<br>&gt; redundancy and involve exactly *zero* Ps.<br>&gt;<br>&gt; So, I want you to drop your lecturing tone for a minute and simply<br>&gt; tell in what respect in your opinion this approach is not perfect<br>&gt; fo the L1VPN application. Otherwise, I am not interested in
 this<br>&gt; discussion any longer. I do like to hear comments from other people.<br><br>Since you asked, one problem with using OSPF, as John correctly<br>pointed out, is that you are left with a situation in which *every* PE <br>router will have *all* L1VPN routes for all the L1VPNs. Of course, <br>this is "perfect" in a sense that you can do no worse than that :-)<br><br>IB&gt;&gt; Ok. Several points here. Note that neither Ps nor VPN-unaware PEs participate in the distribution/maintenance of VPN information, which is already significantly better than what you said about the OSPF solution in your previous mail:<br><br>&gt;... And while on the subject of scaling, please keep in mind that BGP<br>&gt;&nbsp;&nbsp; only stores L1VPN routes on PEs that have sites of that VPN<br>&gt;&nbsp;&nbsp; connected to them, and on an RR if used, but *not* on any of the P <br>&gt;&nbsp;&nbsp; routers. In contrast, rfc5252 (OSPF for L1VPN<br>&gt;&nbsp;&nbsp;
 autodiscovery) results in storing *all VPN TE information <br>&gt;&nbsp;&nbsp; for all the VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based <br>&gt;&nbsp;&nbsp; approach scales better than OSPF-based approach.<br><br>&gt; &gt;&gt;&gt;&gt;Yakov.<br><br>I do agree that if you use a single ring overlay interconnecting all VPN aware PEs you will have LSDBs at all PEs contain VPN info about all VPNs. However, in case of L1VPN this is not VPN routes, rather VPN Provider-To-Customer port mappings which I believe will prove to be sugnifficantly smaller, so I am not sure yet how bad is that. In any case, if it does present a problem on a network with large number of VPNs, who said that it has to be a single overlay? Why not to configure several overlays - each containing a single ring that interconnects PEs participating in a common sub-set of VPNs, and run a seperate instance of OSPF in each overlay?<br><br>Igor<br><br><br>&nbsp;<br>&gt;
 <br>&gt; <br>&gt; <br>&gt; <br>&gt; ----- Original Message ----<br>&gt; From: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt; To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Lo<br>u Berger &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt; Cc: Yakov Rekhter &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian Farrel &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; c<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a><br>&gt; Sent: Wednesday, September 3, 2008 8:10:07 AM<br>&gt; Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)<br>&gt; <br>&gt; Igor,<br>&gt; <br>&gt; Actually, I am not sure that you do understand what I wrote, because you<br>&gt; are providing examples of the redundancy that I specified - every PE<br>&gt; router needs to have connectivity to two other routers in the IGP<br>&gt; instance.<br>&gt; <br>&gt; Thanks,<br>&gt; <br>&gt; John <br>&gt; <br>&gt; &gt;-----Original Message-----<br>&gt; &gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>] <br>&gt; &gt;Sent: Tuesday, September 02, 2008 3:06 PM<br>&gt; &gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt; &gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>;
 <br>&gt; &gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt; &gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG <br>&gt; &gt;(2nd question)<br>&gt; &gt;<br>&gt; &gt;Hi John,<br>&gt; &gt;<br>&gt; &gt;I understand what you are saying and disagree. The overlay I <br>&gt; &gt;am talking about logically is a separate network and as any <br>&gt; &gt;network it should be sufficiently redundant to function. There <br>&gt; &gt;is a number of ways how you can address the redundancy <br>&gt; &gt;concerns. Look at the examples below:<br>&gt; &gt;<br>&gt; &gt;a) interconnect all VPN-aware PEs into a single ring: <br>&gt; &gt;PE=======PE<br>&gt; &gt; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||<br>&gt; &gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  PE <br>&gt; &gt;||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||<br>&gt; &gt;PE&nbsp; &nbsp; &nbsp;
 &nbsp; &nbsp; &nbsp; &nbsp;  PE <br>&gt; &gt;||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||<br>&gt; &gt;...&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ....<br>&gt; &gt;PE=======PE<br>&gt; &gt;<br>&gt; &gt;b) connect each PE to two interconnected Ps <br>&gt; &gt;<br>&gt; &gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  P&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  PE<br>&gt; &gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>&gt; &gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PE <br>&gt; &gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>&gt; &gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
 &nbsp; &nbsp; PE <br>&gt; &gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>&gt; &gt;...&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ....<br>&gt; &gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  P&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  PE<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;Note that tunnels can traverse any number of VPN-unaware Ps and PEs.<br>&gt; &gt;<br>&gt; &gt;Igor<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;----- Original Message ----<br>&gt; &gt;From: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt; &gt;To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt; &gt;&lt;<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt; &gt;Cc: Yakov Rekhter &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian Farrel <br>&gt; &gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt; &gt;Sent: Tuesday, September 2, 2008 2:24:26 PM<br>&gt; &gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG <br>&gt; &gt;(2nd question)<br>&gt; &gt;<br>&gt; &gt;Igor,<br>&gt; &gt;<br>&gt; &gt;Several years ago when OSPF was first proposed as an <br>&gt; &gt;autodiscovery mechanism for
 L1VPNs, you were told that it was <br>&gt; &gt;a bad idea due to its scaling properties and impact on the IGP.<br>&gt; &gt;<br>&gt; &gt;You are now tacitly agreeing with those who told you it was a bad idea.<br>&gt; &gt;<br>&gt; &gt;For your suggested approach to work with sufficient <br>&gt; &gt;redundancy, the topology of the overlay needs to be configured <br>&gt; &gt;such that every selected P router is connected to at least two <br>&gt; &gt;other selected P routers and every PE router needs to be <br>&gt; &gt;connected to at least two selected P routers.<br>&gt; &gt;<br>&gt; &gt;When you are done with this configuration, you are left with a <br>&gt; &gt;situation in which *every* PE and selected P router will have <br>&gt; &gt;*all* L1VPN routes.<br>&gt; &gt;<br>&gt; &gt;Thanks,<br>&gt; &gt;<br>&gt; &gt;John <br>&gt; &gt;<br>&gt; &gt;&gt;-----Original Message-----<br>&gt; &gt;&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>]<br>&gt; &gt;&gt;Sent: Friday, August 29, 2008 12:10 PM<br>&gt; &gt;&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt; &gt;&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>&gt; &gt;&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt; &gt;&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd <br>&gt; &gt;&gt;question)<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;Are you calling me silly? Are you coming to Minneapolis? :=)<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;Seriously, what is wrong in your opinion with this approach? <br>&gt; &gt;&gt;Many people are talking about multi-instance IGPs. What they have in <br>&gt; &gt;&gt;mind is improving the IGP scalability:<br>&gt; &gt;&gt;a) by removing non-IP advertisements from the instance of IGP that <br>&gt;
 &gt;&gt;manages IP routing/forwarding tables into separate IGP instance(s);<br>&gt; &gt;&gt;b) by distributing non-IP information only to and via <br>&gt; &gt;inerested parties <br>&gt; &gt;&gt;leaving the bulk of Ps out of the process.<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;In my opinion this is exactly what is needed for the OSPF-based L1VPN <br>&gt; &gt;&gt;application.<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;Igor<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;----- Original Message ----<br>&gt; &gt;&gt;From: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt; &gt;&gt;To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt; &gt;&gt;&lt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt; &gt;&gt;Cc: Yakov Rekhter &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian Farrel <br>&gt; &gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt; &gt;&gt;Sent: Friday, August 29, 2008 2:31:36 PM<br>&gt; &gt;&gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd <br>&gt; &gt;&gt;question)<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;So you are proposing an OSPF route reflector?&nbsp; At what point does the <br>&gt; &gt;&gt;silliness stop?<br>&gt; &gt;&gt;<br>&gt;
 &gt;&gt;&gt;-----Original Message-----<br>&gt; &gt;&gt;&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>]<br>&gt; &gt;&gt;&gt;Sent: Friday, August 29, 2008 11:29 AM<br>&gt; &gt;&gt;&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt; &gt;&gt;&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>&gt; &gt;&gt;&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt; &gt;&gt;&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd<br>&gt; &gt;&gt;&gt;question)<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;Hi John,<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;No, not really. When you add a PE you configure local<br>&gt; &gt;&gt;interfaces, local<br>&gt; &gt;&gt;&gt;VPN port mappings, stuff like that. While doing this you will also <br>&gt;
 &gt;&gt;&gt;configure an IPinIP tunnel to one of your spoke Ps and enable L1VPN <br>&gt; &gt;&gt;&gt;OSPF instance on the tunnel.<br>&gt; &gt;&gt;&gt;Once you did that the local VPN information will be flooded<br>&gt; &gt;&gt;accross the<br>&gt; &gt;&gt;&gt;overlay, likewise, the new PE will get all the necessary information <br>&gt; &gt;&gt;&gt;from other PEs.<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;Cheers,<br>&gt; &gt;&gt;&gt;Igor<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;----- Original Message ----<br>&gt; &gt;&gt;&gt;From: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt; &gt;&gt;&gt;To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt; &gt;&gt;&gt;&lt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt; &gt;&gt;&gt;Cc: Yakov Rekhter &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian Farrel <br>&gt; &gt;&gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt; &gt;&gt;&gt;Sent: Friday, August 29, 2008 11:20:16 AM<br>&gt; &gt;&gt;&gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd<br>&gt; &gt;&gt;&gt;question)<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;Igor,<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;Doesn't this defeat auto-discovery?&nbsp; I.e., how is a new
 PE <br>&gt; &gt;added to a <br>&gt; &gt;&gt;&gt;given L1VPN?<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;Thanks,<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;John<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;-----Original Message-----<br>&gt; &gt;&gt;&gt;&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>]<br>&gt; &gt;&gt;&gt;&gt;Sent: Friday, August 29, 2008 5:51 AM<br>&gt; &gt;&gt;&gt;&gt;To: Yakov Rekhter; Lou Berger<br>&gt; &gt;&gt;&gt;&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>&gt; &gt;&gt;&gt;&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt; &gt;&gt;&gt;&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd<br>&gt; &gt;&gt;&gt;&gt;question)<br>&gt; &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;Yakov,<br>&gt;
 &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;You said:<br>&gt; &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;... And while on the subject of scaling, please keep in mind<br>&gt; &gt;&gt;that BGP<br>&gt; &gt;&gt;&gt;&gt;only stores L1VPN routes on PEs that have sites of that VPN<br>&gt; &gt;&gt;connected<br>&gt; &gt;&gt;&gt;&gt;to them, and on an RR if used, but *not* on any of the P <br>&gt; &gt;routers. In <br>&gt; &gt;&gt;&gt;&gt;contrast, rfc5252 (OSPF for L1VPN<br>&gt; &gt;&gt;&gt;&gt;autodiscovery) results in storing *all VPN TE information <br>&gt; &gt;for all the<br>&gt; &gt;&gt;&gt;&gt;VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based <br>&gt; &gt;&gt;&gt;&gt;approach scales better than OSPF-based approach.<br>&gt; &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;Yakov.<br>&gt; &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;This is not true in case of multi-instance OSPF: one can build an <br>&gt; &gt;&gt;&gt;&gt;overlay
 interconnecting PEs via one or small number of Ps<br>&gt; &gt;&gt;&gt;using IPinIP<br>&gt; &gt;&gt;&gt;&gt;tunnels and run in this overlay an instance of OSPF specifically <br>&gt; &gt;&gt;&gt;&gt;designated for distribution of L1VPN information. In this<br>&gt; &gt;&gt;&gt;case the OSPF<br>&gt; &gt;&gt;&gt;&gt;solution won't scale any worse than the BGP approach. Note. <br>&gt; &gt;&gt;&gt;that rfc252<br>&gt; &gt;&gt;&gt;&gt;never said that the instance of OSPF used for flooding of the L1VPN <br>&gt; &gt;&gt;&gt;&gt;information must be the same instance that is used for the<br>&gt; &gt;&gt;&gt;distribution<br>&gt; &gt;&gt;&gt;&gt;of IP-related LSAs.<br>&gt; &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;Regards,<br>&gt; &gt;&gt;&gt;&gt;Igor<br>&gt; &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;<br>&gt;
 &gt;&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; <br>&gt; <br>&gt;&nbsp; &nbsp; &nbsp;  <br>&gt; --0-1141253910-1220449648=:97601<br>&gt; Content-Type: text/html; charset=us-ascii<br>&gt; <br>&gt; &lt;html&gt;&lt;head&gt;&lt;style type="text/css"&gt;&lt;!-- DIV {margin:0px;} --&gt;&lt;/style&gt;&lt;/head&gt;&lt;<br>body&gt;&lt;div style="font-family:times new roman, new york, times, serif;font-size:<br>12pt"&gt;&lt;div&gt;And I am not arguing that sufficient redundancy must be provided. Ho<br>wever you said:&lt;br&gt;&amp;gt;For your suggested approach to work with sufficient &lt;br&gt;<br>&amp;gt;redundancy, the topology of the overlay needs to be configured &lt;br&gt;&amp;gt;such<br> that every selected P router is connected to at least two &lt;br&gt;&amp;gt;other select<br>ed P routers and every PE router needs to be &lt;br&gt;&amp;gt;connected to at least two <br>selected P routers.&lt;br&gt;&lt;br&gt;If you just
 simply interconnect all VPN-aware PEs in<br>to a single ring via IPinIP tunnels and run an instance of OSPF to distribute V<br>PN-related information between them, it will provide sufficient redundancy and <br>involve exactly *zero* Ps.&lt;br&gt;So, I want you to drop your lecturing tone for a <br>minute and simply tell in what respect in your opinion this approach is not per<br>fect fo the L1VPN<br>&gt;&nbsp; application. Otherwise, I am not interested in this discussion any longer. I<br> do like to hear comments from other people.&lt;br&gt;&lt;br&gt;Igor &lt;br&gt;&lt;br&gt;&lt;/div&gt;&lt;div sty<br>le="font-family: times new roman,new york,times,serif; font-size: 12pt;"&gt;&lt;br&gt;&lt;d<br>iv style="font-family: arial,helvetica,sans-serif; font-size: 13px;"&gt;----- Orig<br>inal Message ----&lt;br&gt;From: "Drake, John E" &amp;lt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&amp;gt;&lt;br&gt;<br>To: Igor Bryskin &amp;lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&amp;gt;; Yakov Rekhter &amp;lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>et&amp;gt;; Lou Berger &amp;lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&amp;gt;&lt;br&gt;Cc: Yakov Rekhter &amp;lt;yakov@juni<br>per.net&amp;gt;; Adrian Farrel &amp;lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&amp;gt;; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; sof<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;br&gt;Sent: Wednesday, September 3, 2008 8:10:07 AM&lt;br&gt;Subject: RE<br>: [Softwires] BGP TE attr last call by
 softwires WG (2nd question)&lt;br&gt;&lt;br&gt;<br>&gt; Igor,&lt;br&gt;&lt;br&gt;Actually, I am not sure that you do understand what I wrote, bec<br>ause you&lt;br&gt;are providing examples of the redundancy that I specified - every P<br>E&lt;br&gt;router needs to have connectivity to two other routers in the IGP&lt;br&gt;insta<br>nce.&lt;br&gt;&lt;br&gt;Thanks,&lt;br&gt;&lt;br&gt;John &lt;br&gt;&lt;br&gt;&amp;gt;-----Original Message-----&lt;br&gt;&amp;gt;F<br>rom: Igor Bryskin [mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;] &lt;br&gt;&amp;gt;Sent: Tuesday, September <br>02, 2008 3:06 PM&lt;br&gt;&amp;gt;To: Drake, John E; Yakov Rekhter; Lou
 Berger&lt;br&gt;&amp;gt;Cc:<br> Yakov Rekhter; Adrian Farrel; &lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mai<br>lto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;; &lt;br&gt;&amp;gt;&lt;a ymailto="mailto:soft<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&lt;br&gt;&amp;gt;<br>Subject: Re: [Softwires] BGP TE attr last call by softwires WG &lt;br&gt;&amp;gt;(2nd que<br>stion)&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;Hi John,&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;I understand
 what you are saying <br>and disagree. The<br>&gt;&nbsp; overlay I &lt;br&gt;&amp;gt;am talking about logically is a separate network and as an<br>y &lt;br&gt;&amp;gt;network it should be sufficiently redundant to function. There &lt;br&gt;&amp;g<br>t;is a number of ways how you can address the redundancy &lt;br&gt;&amp;gt;concerns. Look<br> at the examples below:&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;a) interconnect all VPN-aware PEs into a<br> single ring: &lt;br&gt;&amp;gt;PE=======PE&lt;br&gt;&amp;gt; ||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; <br>&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; ||&lt;br&gt;&amp;gt;PE&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbs<br>p; &amp;nbsp;&nbsp; PE &lt;br&gt;&amp;gt;||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;<br> &amp;nbsp;&nbsp; ||&lt;br&gt;&amp;gt;PE&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; PE
 &lt;br&gt;&amp;<br>gt;||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; ||&lt;br&gt;&amp;gt;<br>...&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; ....&lt;br&gt;&amp;gt;PE======<br>=PE&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;b) connect each PE to two interconnected Ps &lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;<br>PE&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; P&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp<br>; &amp;nbsp; &amp;nbsp; &amp;nbsp;<br>&gt;&nbsp; &amp;nbsp;&nbsp; PE&lt;br&gt;&amp;gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;n<br>bsp; &amp;nbsp; ||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; &lt;<br>br&gt;&amp;gt;PE&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; ||&amp;nbsp;
 &amp;nbsp; &amp;nbs<br>p; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; PE &lt;br&gt;&amp;gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;n<br>bsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; ||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;n<br>bsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &lt;br&gt;&amp;gt;PE&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;<br>nbsp; &amp;nbsp;&nbsp; ||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; <br>PE &lt;br&gt;&amp;gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp<br>; ||&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &lt;br&gt;&amp;gt;...&amp;<br>nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; ||&amp;nbsp; &amp;nbsp; &amp;nbsp; <br>&amp;nbsp; &amp;nbsp;
 &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; ....&lt;br&gt;&amp;gt;PE&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;<br>nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;&nbsp; P&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;<br>nbsp; <br>&gt;&nbsp; PE&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;Note that tunnels can traverse any number of VPN-u<br>naware Ps and PEs.&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;Igor&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;----- Original Me<br>ssage ----&lt;br&gt;&amp;gt;From: "Drake, John E" &amp;lt;&lt;a ymailto="mailto:John.E.Drake2@bo<br><a target="_blank" href="http://eing.com">eing.com</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;g<br>t;&lt;br&gt;&amp;gt;To: Igor Bryskin
 &amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="ma<br>ilto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; Yakov Rekhter &lt;br&gt;&amp;gt;&amp;l<br>t;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;yakov@j<br><a target="_blank" href="http://uniper.net">uniper.net</a>&lt;/a&gt;&amp;gt;; Lou Berger &amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="m<br>ailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;&lt;br&gt;&amp;gt;Cc: Yakov Rekhter &amp;lt;&lt;<br>a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;yakov@juni<br><a target="_blank" href="http://per.net">per.net</a>&lt;/a&gt;&amp;gt;; Adrian Farrel &lt;br&gt;&amp;gt;&amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>.<br>uk" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; &lt;a<br>&gt;&nbsp; ymailto="mailto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;ccamp@o<br><a target="_blank" href="http://ps.ietf.org">ps.ietf.org</a>&lt;/a&gt;; &lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:softwires@<br><a target="_blank" href="http://ietf.org">ietf.org</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&lt;br&gt;&amp;gt;Sent: Tuesday, September 2, 2008 2:24:2<br>6 PM&lt;br&gt;&amp;gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG &lt;br&gt;<br>&amp;gt;(2nd question)&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;Igor,&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;Several years ago when O<br>SPF was first proposed as an &lt;br&gt;&amp;gt;autodiscovery mechanism for L1VPNs, you we<br>re told that it was
 &lt;br&gt;&amp;gt;a bad idea due to its scaling properties and impact<br> on the IGP.&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;You are now tacitly agreeing with those who told yo<br>u it was a bad idea.&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;For your suggested approach to work with su<br>fficient &lt;br&gt;&amp;gt;redundancy, the topology of the overlay needs to be configured<br> &lt;br&gt;&amp;gt;such that every selected P router is connected to at least two &lt;br&gt;&amp;gt<br>;other selected P routers and every PE router needs to be &lt;br&gt;&amp;gt;connected to <br>at least two selected<br>&gt;&nbsp; P routers.&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;When you are done with this configuration, you are<br> left with a &lt;br&gt;&amp;gt;situation in which *every* PE and selected P router will h<br>ave &lt;br&gt;&amp;gt;*all* L1VPN routes.&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;Thanks,&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;John
 &lt;br&gt;<br>&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;-----Original Message-----&lt;br&gt;&amp;gt;&amp;gt;From: Igor Bryskin [mailt<br>o:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;i_b<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;]&lt;br&gt;&amp;gt;&amp;gt;Sent: Friday, August 29, 2008 12:10 PM&lt;br&gt;&amp;gt;<br>&amp;gt;To: Drake, John E; Yakov Rekhter; Lou Berger&lt;br&gt;&amp;gt;&amp;gt;Cc: Yakov Rekhter; <br>Adrian Farrel; &lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br><a target="_blank" href="http://tf.org">tf.org</a>"&gt;<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;; &lt;br&gt;&amp;gt;&amp;gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>rg" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&lt;br&gt;&amp;gt;&amp;gt;Subject:<br> Re: [Softwires] BGP TE attr last call by softwires WG (2nd &lt;br&gt;&amp;gt;&amp;gt;questio<br>n)&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;Are you calling me silly? Are you coming to Minneapol<br>is?<br>&gt;&nbsp; :=)&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;Seriously, what is wrong in your opinion with thi<br>s approach? &lt;br&gt;&amp;gt;&amp;gt;Many people are talking about multi-instance IGPs. What<br> they have in
 &lt;br&gt;&amp;gt;&amp;gt;mind is improving the IGP scalability:&lt;br&gt;&amp;gt;&amp;gt;a) <br>by removing non-IP advertisements from the instance of IGP that &lt;br&gt;&amp;gt;&amp;gt;man<br>ages IP routing/forwarding tables into separate IGP instance(s);&lt;br&gt;&amp;gt;&amp;gt;b) <br>by distributing non-IP information only to and via &lt;br&gt;&amp;gt;inerested parties &lt;b<br>r&gt;&amp;gt;&amp;gt;leaving the bulk of Ps out of the process.&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;In <br>my opinion this is exactly what is needed for the OSPF-based L1VPN &lt;br&gt;&amp;gt;&amp;gt;<br>application.&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;Igor&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&lt;br<br>&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;----- Original Message ----&lt;br&gt;&amp;gt<br>;&amp;gt;From: "Drake, John E" &amp;lt;&lt;a
 ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" hre<br>f="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt<br>;To: Igor Bryskin<br>&gt;&nbsp; &amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; Yakov Rekhter &lt;br&gt;&amp;gt;&amp;gt;&amp;lt;&lt;a ymailto="mailto<br>:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; <br>Lou Berger &amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>et"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;Cc: Yakov Rekhter &amp;lt;&lt;a ymailto="mailt<br>o:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;;<br> Adrian Farrel &lt;br&gt;&amp;gt;&amp;gt;&amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="ma<br>ilto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; &lt;a ymailto="mailto:ccamp<br>@ops.ietf.org" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;; &lt;a ymai<br>lto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>"&gt;softwires@ietf<br>.org&lt;/a&gt;&lt;br&gt;&amp;gt;&amp;gt;Sent: Friday, August 29, 2008 2:31:36 PM&lt;br&gt;&amp;gt;&amp;gt;Subject<br>: RE: [Softwires] BGP TE attr last call by softwires WG (2nd<br>&gt;&nbsp; &lt;br&gt;&amp;gt;&amp;gt;question)&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;So you are proposing an OSPF ro<br>ute reflector?&amp;nbsp; At what point does the &lt;br&gt;&amp;gt;&amp;gt;silliness stop?&lt;br&gt;&amp;gt;<br>&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;-----Original Message-----&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;From: Igor Bryski<br>n [mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:i_bryskin@yahoo.<br>com"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;]&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Sent: Friday, August 29,
 2008 11:2<br>9 AM&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;To: Drake, John E; Yakov Rekhter; Lou Berger&lt;br&gt;&amp;gt;&amp;gt;&amp;gt<br>;Cc: Yakov Rekhter; Adrian Farrel; &lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href=<br>"mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;; &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;a ymailto=<br>"mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&lt;/a&gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Subject: Re: [Softwires] BGP TE attr last call by
 softwires<br> WG (2nd&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;question)&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Hi John,&lt;br&gt;&amp;g<br>t;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;No, not really. When you add a PE you configure<br>&gt;&nbsp; local&lt;br&gt;&amp;gt;&amp;gt;interfaces, local&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;VPN port mappings, stuff l<br>ike that. While doing this you will also &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;configure an IPinIP tu<br>nnel to one of your spoke Ps and enable L1VPN &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;OSPF instance on <br>the tunnel.&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Once you did that the local VPN information will be <br>flooded&lt;br&gt;&amp;gt;&amp;gt;accross the&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;overlay, likewise, the new PE wil<br>l get all the necessary information &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;from other
 PEs.&lt;br&gt;&amp;gt;&amp;gt;<br>&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Cheers,&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Igor&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;<br>&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;----- Original Message ----&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;From: "Drake, John E<br>" &amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:John.E.Drake2@b<br><a target="_blank" href="http://oeing.com">oeing.com</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;To: Igor Bryskin &amp;lt<br>;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>"&gt;i_br<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; Yakov Rekhter &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;lt;&lt;a ymailto="mailto:y<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"<br>&gt;&nbsp; href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; Lou Berger &amp;lt;&lt;a<br> ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;lberger@labn.<br>net&lt;/a&gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Cc: Yakov Rekhter &amp;lt;&lt;a ymailto="mailto:yakov@junip<br><a
 target="_blank" href="http://er.net">er.net</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; Adrian Farre<br>l &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;lt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:adri<br><a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&amp;gt;; &lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>.org" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;; &lt;a ymailto="mail<br>to:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&lt;<br>br&gt;&amp;gt;&amp;gt;&amp;gt;Sent: Friday, August 29, 2008 11:20:16 AM&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Subject<br>: RE: [Softwires] BGP TE attr last call by softwires WG (2nd&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;que<br>stion)&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Igor,&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Does<br>n't this defeat auto-discovery?&amp;nbsp; I.e., how is a new PE &lt;br&gt;&amp;gt;added to a <br>&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;given<br>&gt;&nbsp;
 L1VPN?&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;Thanks,&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt<br>;John&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;-----Original Message-----&lt;br&gt;&amp;gt;&amp;gt;<br>&amp;gt;&amp;gt;From: Igor Bryskin [mailto:&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href<br>="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;]&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Sent:<br> Friday, August 29, 2008 5:51 AM&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;To: Yakov Rekhter; Lou Berg<br>er&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Cc: Yakov Rekhter; Adrian Farrel; &lt;a ymailto="mailto:ccam<br><a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;; &lt;br&gt;&amp;g<br>t;&amp;gt;&amp;gt;&amp;gt;&lt;a ymailto="mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>" href="mailto:softwires@iet<br><a target="_blank" href="http://f.org">f.org</a>"&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&lt;/a&gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Subject: Re: [Softwires] BGP T<br>E attr last call by softwires WG
 (2nd&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;question)&lt;br&gt;&amp;gt;&amp;gt;&amp;<br>gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Yakov,&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;You sa<br>id:&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;... And while on<br> the subject of<br>&gt;&nbsp; scaling, please keep in mind&lt;br&gt;&amp;gt;&amp;gt;that BGP&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;only sto<br>res L1VPN routes on PEs that have sites of that VPN&lt;br&gt;&amp;gt;&amp;gt;connected&lt;br&gt;&amp;gt<br>;&amp;gt;&amp;gt;&amp;gt;to them, and on an RR if used, but *not* on any of the P &lt;br&gt;&amp;gt;r<br>outers. In &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;contrast, rfc5252 (OSPF for L1VPN&lt;br&gt;&amp;gt;&amp;gt;&amp;gt<br>;&amp;gt;autodiscovery) results in storing *all VPN TE information &lt;br&gt;&amp;gt;for all
 <br>the&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;VPNs* on *all* the IGP nodes, both P and PE. So, clearly<br> BGP-based &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;approach scales better than OSPF-based approach.<br>&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Yakov.&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;<br>gt;&amp;gt;This is not true in case of multi-instance OSPF: one can build an &lt;br&gt;&amp;g<br>t;&amp;gt;&amp;gt;&amp;gt;overlay interconnecting PEs via one or small number of Ps&lt;br&gt;&amp;gt;<br>&amp;gt;&amp;gt;using IPinIP&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;tunnels and run in this overlay an inst<br>ance of OSPF specifically &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;designated for distribution of L1<br>VPN information. In<br>&gt;&nbsp; this&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;case the OSPF&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;solution won't scale an<br>y worse than
 the BGP approach. Note. &lt;br&gt;&amp;gt;&amp;gt;&amp;gt;that rfc252&lt;br&gt;&amp;gt;&amp;gt;&amp;gt<br>;&amp;gt;never said that the instance of OSPF used for flooding of the L1VPN &lt;br&gt;&amp;g<br>t;&amp;gt;&amp;gt;&amp;gt;information must be the same instance that is used for the&lt;br&gt;&amp;gt<br>;&amp;gt;&amp;gt;distribution&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;of IP-related
 LSAs.&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt<br>;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Regards,&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;Igor&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;g<br>t;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;<br>gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;<br>&amp;gt;&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;&lt;br&gt;&amp;gt;&lt;br&gt;&lt;br&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;br&gt;<br>&gt; <br>&gt;&nbsp; &nbsp; &nbsp;  &lt;/body&gt;&lt;/html&gt;<br>&gt; --0-1141253910-1220449648=:97601--<br></div></div></div><br>

      </body></html>
--0-1852435290-1220452662=:19087--

Delivery-date: Wed, 03 Sep 2008 14:06:36 +0000
Content-class: urn:content-classes:message
Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)
Date: Wed, 3 Sep 2008 07:01:29 -0700
From: "Drake, John E" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>, "Yakov Rekhter" <[email-masked]>, "Lou Berger" <[email-masked]>
Cc: "Yakov Rekhter" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>, <[email-masked]>

Igor,

I'm sorry, but you were the one that stipulated P routers.  I mentioned
the more general requirement in my last e-mail:  "every PE router needs
to have connectivity to two other routers in the IGP instance".

The points being that:

1) The configuration burden is twice what you claimed it to be.

2)  Every PE router in the IGP instance has L1VPN routes that it doesn't
care about.

3)  The number of L1VPN routes that a given PE router doesn't care about
is probably greater than the number of L1VPN routes it does care about.

Thanks,

John =20

>-----Original Message-----
>From: Igor Bryskin [mailto:[email-masked]]=20
>Sent: Wednesday, September 03, 2008 6:47 AM
>To: Drake, John E; Yakov Rekhter; Lou Berger
>Cc: Yakov Rekhter; Adrian Farrel; [email-masked];=20
>[email-masked]
>Subject: Re: [Softwires] BGP TE attr last call by softwires WG=20
>(2nd question)
>
>And I am not arguing that sufficient redundancy must be=20
>provided. However you said:
>>For your suggested approach to work with sufficient redundancy, the=20
>>topology of the overlay needs to be configured such that=20
>every selected=20
>>P router is connected to at least two other selected P routers and=20
>>every PE router needs to be connected to at least two selected P=20
>>routers.
>
>If you just simply interconnect all VPN-aware PEs into a=20
>single ring via IPinIP tunnels and run an instance of OSPF to=20
>distribute VPN-related information between them, it will=20
>provide sufficient redundancy and involve exactly *zero* Ps.
>So, I want you to drop your lecturing tone for a minute and=20
>simply tell in what respect in your opinion this approach is=20
>not perfect fo the L1VPN application. Otherwise, I am not=20
>interested in this discussion any longer. I do like to hear=20
>comments from other people.
>
>Igor=20
>
>
>
>----- Original Message ----
>From: "Drake, John E" <[email-masked]>
>To: Igor Bryskin <[email-masked]>; Yakov Rekhter=20
><[email-masked]>; Lou Berger <[email-masked]>
>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel=20
><[email-masked]>; [email-masked]; [email-masked]
>Sent: Wednesday, September 3, 2008 8:10:07 AM
>Subject: RE: [Softwires] BGP TE attr last call by softwires WG=20
>(2nd question)
>
>Igor,
>
>Actually, I am not sure that you do understand what I wrote,=20
>because you are providing examples of the redundancy that I=20
>specified - every PE router needs to have connectivity to two=20
>other routers in the IGP instance.
>
>Thanks,
>
>John=20
>
>>-----Original Message-----
>>From: Igor Bryskin [mailto:[email-masked]]
>>Sent: Tuesday, September 02, 2008 3:06 PM
>>To: Drake, John E; Yakov Rekhter; Lou Berger
>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked];=20
>>[email-masked]
>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd=20
>>question)
>>
>>Hi John,
>>
>>I understand what you are saying and disagree. The overlay I=20
>am talking=20
>>about logically is a separate network and as any network it should be=20
>>sufficiently redundant to function. There is a number of ways how you=20
>>can address the redundancy concerns. Look at the examples below:
>>
>>a) interconnect all VPN-aware PEs into a single ring:=20
>>PE=3D=3D=3D=3D=3D=3D=3DPE
>> ||                  ||
>>PE              PE=20
>>||                  ||
>>PE              PE=20
>>||                  ||
>>...                ....
>>PE=3D=3D=3D=3D=3D=3D=3DPE
>>
>>b) connect each PE to two interconnected Ps
>>
>>PE              P                PE
>>                    ||                 =20
>>PE              ||                  PE=20
>>                    ||                 =20
>>PE              ||                  PE=20
>>                    ||                 =20
>>...                ||                  ....
>>PE              P                PE
>>
>>
>>Note that tunnels can traverse any number of VPN-unaware Ps and PEs.
>>
>>Igor
>>
>>
>>----- Original Message ----
>>From: "Drake, John E" <[email-masked]>
>>To: Igor Bryskin <[email-masked]>; Yakov Rekhter=20
>><[email-masked]>; Lou Berger <[email-masked]>
>>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel=20
>><[email-masked]>; [email-masked]; [email-masked]
>>Sent: Tuesday, September 2, 2008 2:24:26 PM
>>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd=20
>>question)
>>
>>Igor,
>>
>>Several years ago when OSPF was first proposed as an autodiscovery=20
>>mechanism for L1VPNs, you were told that it was a bad idea due to its=20
>>scaling properties and impact on the IGP.
>>
>>You are now tacitly agreeing with those who told you it was a=20
>bad idea.
>>
>>For your suggested approach to work with sufficient redundancy, the=20
>>topology of the overlay needs to be configured such that=20
>every selected=20
>>P router is connected to at least two other selected P routers and=20
>>every PE router needs to be connected to at least two selected P=20
>>routers.
>>
>>When you are done with this configuration, you are left with a=20
>>situation in which *every* PE and selected P router will have
>>*all* L1VPN routes.
>>
>>Thanks,
>>
>>John
>>
>>>-----Original Message-----
>>>From: Igor Bryskin [mailto:[email-masked]]
>>>Sent: Friday, August 29, 2008 12:10 PM
>>>To: Drake, John E; Yakov Rekhter; Lou Berger
>>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked];=20
>>>[email-masked]
>>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
>>>question)
>>>
>>>Are you calling me silly? Are you coming to Minneapolis? :=3D)
>>>
>>>Seriously, what is wrong in your opinion with this approach?=20
>>>Many people are talking about multi-instance IGPs. What they have in=20
>>>mind is improving the IGP scalability:
>>>a) by removing non-IP advertisements from the instance of IGP that=20
>>>manages IP routing/forwarding tables into separate IGP instance(s);
>>>b) by distributing non-IP information only to and via
>>inerested parties
>>>leaving the bulk of Ps out of the process.
>>>
>>>In my opinion this is exactly what is needed for the=20
>OSPF-based L1VPN=20
>>>application.
>>>
>>>Igor
>>>
>>>
>>>
>>>
>>>
>>>
>>>----- Original Message ----
>>>From: "Drake, John E" <[email-masked]>
>>>To: Igor Bryskin <[email-masked]>; Yakov Rekhter=20
>>><[email-masked]>; Lou Berger <[email-masked]>
>>>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel=20
>>><[email-masked]>; [email-masked]; [email-masked]
>>>Sent: Friday, August 29, 2008 2:31:36 PM
>>>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd
>>>question)
>>>
>>>So you are proposing an OSPF route reflector?  At what point=20
>does the=20
>>>silliness stop?
>>>
>>>>-----Original Message-----
>>>>From: Igor Bryskin [mailto:[email-masked]]
>>>>Sent: Friday, August 29, 2008 11:29 AM
>>>>To: Drake, John E; Yakov Rekhter; Lou Berger
>>>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked];=20
>>>>[email-masked]
>>>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
>>>>question)
>>>>
>>>>Hi John,
>>>>
>>>>No, not really. When you add a PE you configure local
>>>interfaces, local
>>>>VPN port mappings, stuff like that. While doing this you will also=20
>>>>configure an IPinIP tunnel to one of your spoke Ps and enable L1VPN=20
>>>>OSPF instance on the tunnel.
>>>>Once you did that the local VPN information will be flooded
>>>accross the
>>>>overlay, likewise, the new PE will get all the necessary=20
>information=20
>>>>from other PEs.
>>>>
>>>>Cheers,
>>>>Igor
>>>>
>>>>
>>>>----- Original Message ----
>>>>From: "Drake, John E" <[email-masked]>
>>>>To: Igor Bryskin <[email-masked]>; Yakov Rekhter=20
>>>><[email-masked]>; Lou Berger <[email-masked]>
>>>>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel=20
>>>><[email-masked]>; [email-masked]; [email-masked]
>>>>Sent: Friday, August 29, 2008 11:20:16 AM
>>>>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd
>>>>question)
>>>>
>>>>Igor,
>>>>
>>>>Doesn't this defeat auto-discovery?  I.e., how is a new PE
>>added to a
>>>>given L1VPN?
>>>>
>>>>Thanks,
>>>>
>>>>John
>>>>
>>>>>-----Original Message-----
>>>>>From: Igor Bryskin [mailto:[email-masked]]
>>>>>Sent: Friday, August 29, 2008 5:51 AM
>>>>>To: Yakov Rekhter; Lou Berger
>>>>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked];=20
>>>>>[email-masked]
>>>>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
>>>>>question)
>>>>>
>>>>>Yakov,
>>>>>
>>>>>You said:
>>>>>
>>>>>
>>>>>... And while on the subject of scaling, please keep in mind
>>>that BGP
>>>>>only stores L1VPN routes on PEs that have sites of that VPN
>>>connected
>>>>>to them, and on an RR if used, but *not* on any of the P
>>routers. In
>>>>>contrast, rfc5252 (OSPF for L1VPN
>>>>>autodiscovery) results in storing *all VPN TE information
>>for all the
>>>>>VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based=20
>>>>>approach scales better than OSPF-based approach.
>>>>>
>>>>>Yakov.
>>>>>
>>>>>This is not true in case of multi-instance OSPF: one can build an=20
>>>>>overlay interconnecting PEs via one or small number of Ps
>>>>using IPinIP
>>>>>tunnels and run in this overlay an instance of OSPF specifically=20
>>>>>designated for distribution of L1VPN information. In this
>>>>case the OSPF
>>>>>solution won't scale any worse than the BGP approach. Note.=20
>>>>that rfc252
>>>>>never said that the instance of OSPF used for flooding of=20
>the L1VPN=20
>>>>>information must be the same instance that is used for the
>>>>distribution
>>>>>of IP-related LSAs.
>>>>>
>>>>>Regards,
>>>>>Igor
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>

Delivery-date: Wed, 03 Sep 2008 14:03:48 +0000
To: Igor Bryskin <[email-masked]>
cc: "Drake, John E" <[email-masked]>, Lou Berger <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) 
Date: Wed, 03 Sep 2008 06:55:49 -0700
From: Yakov Rekhter <[email-masked]>

Igor,

> And I am not arguing that sufficient redundancy must be provided. However you
> said:
> >For your suggested approach to work with sufficient 
> >redundancy, the topology of the overlay needs to be configured 
> >such that every selected P router is connected to at least two 
> >other selected P routers and every PE router needs to be 
> >connected to at least two selected P routers.
> 
> If you just simply interconnect all VPN-aware PEs into a single
> ring via IPin IP tunnels and run an instance of OSPF to distribute
> VPN-related information between them, it will provide sufficient
> redundancy and involve exactly *zero* Ps.
>
> So, I want you to drop your lecturing tone for a minute and simply
> tell in what respect in your opinion this approach is not perfect
> fo the L1VPN application. Otherwise, I am not interested in this
> discussion any longer. I do like to hear comments from other people.

Since you asked, one problem with using OSPF, as John correctly
pointed out, is that you are left with a situation in which *every* PE 
router will have *all* L1VPN routes for all the L1VPNs. Of course, 
this is "perfect" in a sense that you can do no worse than that :-)

Yakov.
  
> 
> 
> 
> 
> ----- Original Message ----
> From: "Drake, John E" <[email-masked]>
> To: Igor Bryskin <[email-masked]>; Yakov Rekhter <[email-masked]>; Lo
u Berger <[email-masked]>
> Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel <[email-masked]>; c
[email-masked]; [email-masked]
> Sent: Wednesday, September 3, 2008 8:10:07 AM
> Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)
> 
> Igor,
> 
> Actually, I am not sure that you do understand what I wrote, because you
> are providing examples of the redundancy that I specified - every PE
> router needs to have connectivity to two other routers in the IGP
> instance.
> 
> Thanks,
> 
> John 
> 
> >-----Original Message-----
> >From: Igor Bryskin [mailto:[email-masked]] 
> >Sent: Tuesday, September 02, 2008 3:06 PM
> >To: Drake, John E; Yakov Rekhter; Lou Berger
> >Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
> >[email-masked]
> >Subject: Re: [Softwires] BGP TE attr last call by softwires WG 
> >(2nd question)
> >
> >Hi John,
> >
> >I understand what you are saying and disagree. The overlay I 
> >am talking about logically is a separate network and as any 
> >network it should be sufficiently redundant to function. There 
> >is a number of ways how you can address the redundancy 
> >concerns. Look at the examples below:
> >
> >a) interconnect all VPN-aware PEs into a single ring: 
> >PE=======PE
> > ||                  ||
> >PE               PE 
> >||                   ||
> >PE               PE 
> >||                   ||
> >...                ....
> >PE=======PE
> >
> >b) connect each PE to two interconnected Ps 
> >
> >PE               P                 PE
> >                    ||                  
> >PE               ||                  PE 
> >                    ||                  
> >PE               ||                  PE 
> >                    ||                  
> >...                 ||                   ....
> >PE               P                 PE
> >
> >
> >Note that tunnels can traverse any number of VPN-unaware Ps and PEs.
> >
> >Igor
> >
> >
> >----- Original Message ----
> >From: "Drake, John E" <[email-masked]>
> >To: Igor Bryskin <[email-masked]>; Yakov Rekhter 
> ><[email-masked]>; Lou Berger <[email-masked]>
> >Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel 
> ><[email-masked]>; [email-masked]; [email-masked]
> >Sent: Tuesday, September 2, 2008 2:24:26 PM
> >Subject: RE: [Softwires] BGP TE attr last call by softwires WG 
> >(2nd question)
> >
> >Igor,
> >
> >Several years ago when OSPF was first proposed as an 
> >autodiscovery mechanism for L1VPNs, you were told that it was 
> >a bad idea due to its scaling properties and impact on the IGP.
> >
> >You are now tacitly agreeing with those who told you it was a bad idea.
> >
> >For your suggested approach to work with sufficient 
> >redundancy, the topology of the overlay needs to be configured 
> >such that every selected P router is connected to at least two 
> >other selected P routers and every PE router needs to be 
> >connected to at least two selected P routers.
> >
> >When you are done with this configuration, you are left with a 
> >situation in which *every* PE and selected P router will have 
> >*all* L1VPN routes.
> >
> >Thanks,
> >
> >John 
> >
> >>-----Original Message-----
> >>From: Igor Bryskin [mailto:[email-masked]]
> >>Sent: Friday, August 29, 2008 12:10 PM
> >>To: Drake, John E; Yakov Rekhter; Lou Berger
> >>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
> >>[email-masked]
> >>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd 
> >>question)
> >>
> >>Are you calling me silly? Are you coming to Minneapolis? :=)
> >>
> >>Seriously, what is wrong in your opinion with this approach? 
> >>Many people are talking about multi-instance IGPs. What they have in 
> >>mind is improving the IGP scalability:
> >>a) by removing non-IP advertisements from the instance of IGP that 
> >>manages IP routing/forwarding tables into separate IGP instance(s);
> >>b) by distributing non-IP information only to and via 
> >inerested parties 
> >>leaving the bulk of Ps out of the process.
> >>
> >>In my opinion this is exactly what is needed for the OSPF-based L1VPN 
> >>application.
> >>
> >>Igor
> >>
> >>
> >>
> >>
> >>
> >>
> >>----- Original Message ----
> >>From: "Drake, John E" <[email-masked]>
> >>To: Igor Bryskin <[email-masked]>; Yakov Rekhter 
> >><[email-masked]>; Lou Berger <[email-masked]>
> >>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel 
> >><[email-masked]>; [email-masked]; [email-masked]
> >>Sent: Friday, August 29, 2008 2:31:36 PM
> >>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd 
> >>question)
> >>
> >>So you are proposing an OSPF route reflector?  At what point does the 
> >>silliness stop?
> >>
> >>>-----Original Message-----
> >>>From: Igor Bryskin [mailto:[email-masked]]
> >>>Sent: Friday, August 29, 2008 11:29 AM
> >>>To: Drake, John E; Yakov Rekhter; Lou Berger
> >>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
> >>>[email-masked]
> >>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
> >>>question)
> >>>
> >>>Hi John,
> >>>
> >>>No, not really. When you add a PE you configure local
> >>interfaces, local
> >>>VPN port mappings, stuff like that. While doing this you will also 
> >>>configure an IPinIP tunnel to one of your spoke Ps and enable L1VPN 
> >>>OSPF instance on the tunnel.
> >>>Once you did that the local VPN information will be flooded
> >>accross the
> >>>overlay, likewise, the new PE will get all the necessary information 
> >>>from other PEs.
> >>>
> >>>Cheers,
> >>>Igor
> >>>
> >>>
> >>>----- Original Message ----
> >>>From: "Drake, John E" <[email-masked]>
> >>>To: Igor Bryskin <[email-masked]>; Yakov Rekhter 
> >>><[email-masked]>; Lou Berger <[email-masked]>
> >>>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel 
> >>><[email-masked]>; [email-masked]; [email-masked]
> >>>Sent: Friday, August 29, 2008 11:20:16 AM
> >>>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd
> >>>question)
> >>>
> >>>Igor,
> >>>
> >>>Doesn't this defeat auto-discovery?  I.e., how is a new PE 
> >added to a 
> >>>given L1VPN?
> >>>
> >>>Thanks,
> >>>
> >>>John
> >>>
> >>>>-----Original Message-----
> >>>>From: Igor Bryskin [mailto:[email-masked]]
> >>>>Sent: Friday, August 29, 2008 5:51 AM
> >>>>To: Yakov Rekhter; Lou Berger
> >>>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
> >>>>[email-masked]
> >>>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
> >>>>question)
> >>>>
> >>>>Yakov,
> >>>>
> >>>>You said:
> >>>>
> >>>>
> >>>>... And while on the subject of scaling, please keep in mind
> >>that BGP
> >>>>only stores L1VPN routes on PEs that have sites of that VPN
> >>connected
> >>>>to them, and on an RR if used, but *not* on any of the P 
> >routers. In 
> >>>>contrast, rfc5252 (OSPF for L1VPN
> >>>>autodiscovery) results in storing *all VPN TE information 
> >for all the
> >>>>VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based 
> >>>>approach scales better than OSPF-based approach.
> >>>>
> >>>>Yakov.
> >>>>
> >>>>This is not true in case of multi-instance OSPF: one can build an 
> >>>>overlay interconnecting PEs via one or small number of Ps
> >>>using IPinIP
> >>>>tunnels and run in this overlay an instance of OSPF specifically 
> >>>>designated for distribution of L1VPN information. In this
> >>>case the OSPF
> >>>>solution won't scale any worse than the BGP approach. Note. 
> >>>that rfc252
> >>>>never said that the instance of OSPF used for flooding of the L1VPN 
> >>>>information must be the same instance that is used for the
> >>>distribution
> >>>>of IP-related LSAs.
> >>>>
> >>>>Regards,
> >>>>Igor
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> >
> 
> 
>       
> --0-1141253910-1220449648=:97601
> Content-Type: text/html; charset=us-ascii
> 
> <html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><
body><div style="font-family:times new roman, new york, times, serif;font-size:
12pt"><div>And I am not arguing that sufficient redundancy must be provided. Ho
wever you said:<br>&gt;For your suggested approach to work with sufficient <br>
&gt;redundancy, the topology of the overlay needs to be configured <br>&gt;such
 that every selected P router is connected to at least two <br>&gt;other select
ed P routers and every PE router needs to be <br>&gt;connected to at least two 
selected P routers.<br><br>If you just simply interconnect all VPN-aware PEs in
to a single ring via IPinIP tunnels and run an instance of OSPF to distribute V
PN-related information between them, it will provide sufficient redundancy and 
involve exactly *zero* Ps.<br>So, I want you to drop your lecturing tone for a 
minute and simply tell in what respect in your opinion this approach is not per
fect fo the L1VPN
>  application. Otherwise, I am not interested in this discussion any longer. I
 do like to hear comments from other people.<br><br>Igor <br><br></div><div sty
le="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><d
iv style="font-family: arial,helvetica,sans-serif; font-size: 13px;">----- Orig
inal Message ----<br>From: "Drake, John E" &lt;[email-masked]&gt;<br>
To: Igor Bryskin &lt;[email-masked]&gt;; Yakov Rekhter &lt;[email-masked]
et&gt;; Lou Berger &lt;[email-masked]&gt;<br>Cc: Yakov Rekhter &lt;yakov@juni
per.net&gt;; Adrian Farrel &lt;[email-masked]&gt;; [email-masked]; sof
[email-masked]<br>Sent: Wednesday, September 3, 2008 8:10:07 AM<br>Subject: RE
: [Softwires] BGP TE attr last call by softwires WG (2nd question)<br><br>
> Igor,<br><br>Actually, I am not sure that you do understand what I wrote, bec
ause you<br>are providing examples of the redundancy that I specified - every P
E<br>router needs to have connectivity to two other routers in the IGP<br>insta
nce.<br><br>Thanks,<br><br>John <br><br>&gt;-----Original Message-----<br>&gt;F
rom: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href="mailto:
[email-masked]">[email-masked]</a>] <br>&gt;Sent: Tuesday, September 
02, 2008 3:06 PM<br>&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt;Cc:
 Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mai
lto:[email-masked]">[email-masked]</a>; <br>&gt;<a ymailto="mailto:soft
[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;
Subject: Re: [Softwires] BGP TE attr last call by softwires WG <br>&gt;(2nd que
stion)<br>&gt;<br>&gt;Hi John,<br>&gt;<br>&gt;I understand what you are saying 
and disagree. The
>  overlay I <br>&gt;am talking about logically is a separate network and as an
y <br>&gt;network it should be sufficiently redundant to function. There <br>&g
t;is a number of ways how you can address the redundancy <br>&gt;concerns. Look
 at the examples below:<br>&gt;<br>&gt;a) interconnect all VPN-aware PEs into a
 single ring: <br>&gt;PE=======PE<br>&gt; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
&nbsp; &nbsp; &nbsp; &nbsp; ||<br>&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs
p; &nbsp;  PE <br>&gt;||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
 &nbsp;  ||<br>&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  PE <br>&
gt;||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||<br>&gt;
...&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ....<br>&gt;PE======
=PE<br>&gt;<br>&gt;b) connect each PE to two interconnected Ps <br>&gt;<br>&gt;
PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  P&nbsp; &nbsp; &nbsp; &nbsp
; &nbsp; &nbsp; &nbsp;
>  &nbsp;  PE<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n
bsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  <
br>&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||&nbsp; &nbsp; &nbs
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PE <br>&gt;&nbsp; &nbsp; &nbsp; &n
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &n
bsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &
nbsp; &nbsp;  ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
PE <br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp
; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>&gt;...&
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||&nbsp; &nbsp; &nbsp; 
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ....<br>&gt;PE&nbsp; &nbsp; &nbsp; &
nbsp; &nbsp; &nbsp; &nbsp;  P&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &
nbsp; 
>  PE<br>&gt;<br>&gt;<br>&gt;Note that tunnels can traverse any number of VPN-u
naware Ps and PEs.<br>&gt;<br>&gt;Igor<br>&gt;<br>&gt;<br>&gt;----- Original Me
ssage ----<br>&gt;From: "Drake, John E" &lt;<a ymailto="mailto:John.E.Drake2@bo
eing.com" href="mailto:[email-masked]">[email-masked]</a>&g
t;<br>&gt;To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" href="ma
ilto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt;&l
t;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">yakov@j
uniper.net</a>&gt;; Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="m
ailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;Cc: Yakov Rekhter &lt;<
a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">yakov@juni
per.net</a>&gt;; Adrian Farrel <br>&gt;&lt;<a ymailto="mailto:[email-masked].
uk" href="mailto:[email-masked]">[email-masked]</a>&gt;; <a
>  ymailto="mailto:[email-masked]" href="mailto:[email-masked]">ccamp@o
ps.ietf.org</a>; <a ymailto="mailto:[email-masked]" href="mailto:softwires@
ietf.org">[email-masked]</a><br>&gt;Sent: Tuesday, September 2, 2008 2:24:2
6 PM<br>&gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG <br>
&gt;(2nd question)<br>&gt;<br>&gt;Igor,<br>&gt;<br>&gt;Several years ago when O
SPF was first proposed as an <br>&gt;autodiscovery mechanism for L1VPNs, you we
re told that it was <br>&gt;a bad idea due to its scaling properties and impact
 on the IGP.<br>&gt;<br>&gt;You are now tacitly agreeing with those who told yo
u it was a bad idea.<br>&gt;<br>&gt;For your suggested approach to work with su
fficient <br>&gt;redundancy, the topology of the overlay needs to be configured
 <br>&gt;such that every selected P router is connected to at least two <br>&gt
;other selected P routers and every PE router needs to be <br>&gt;connected to 
at least two selected
>  P routers.<br>&gt;<br>&gt;When you are done with this configuration, you are
 left with a <br>&gt;situation in which *every* PE and selected P router will h
ave <br>&gt;*all* L1VPN routes.<br>&gt;<br>&gt;Thanks,<br>&gt;<br>&gt;John <br>
&gt;<br>&gt;&gt;-----Original Message-----<br>&gt;&gt;From: Igor Bryskin [mailt
o:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">i_b
[email-masked]</a>]<br>&gt;&gt;Sent: Friday, August 29, 2008 12:10 PM<br>&gt;
&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt;&gt;Cc: Yakov Rekhter; 
Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]
tf.org">[email-masked]</a>; <br>&gt;&gt;<a ymailto="mailto:[email-masked]
rg" href="mailto:[email-masked]">[email-masked]</a><br>&gt;&gt;Subject:
 Re: [Softwires] BGP TE attr last call by softwires WG (2nd <br>&gt;&gt;questio
n)<br>&gt;&gt;<br>&gt;&gt;Are you calling me silly? Are you coming to Minneapol
is?
>  :=)<br>&gt;&gt;<br>&gt;&gt;Seriously, what is wrong in your opinion with thi
s approach? <br>&gt;&gt;Many people are talking about multi-instance IGPs. What
 they have in <br>&gt;&gt;mind is improving the IGP scalability:<br>&gt;&gt;a) 
by removing non-IP advertisements from the instance of IGP that <br>&gt;&gt;man
ages IP routing/forwarding tables into separate IGP instance(s);<br>&gt;&gt;b) 
by distributing non-IP information only to and via <br>&gt;inerested parties <b
r>&gt;&gt;leaving the bulk of Ps out of the process.<br>&gt;&gt;<br>&gt;&gt;In 
my opinion this is exactly what is needed for the OSPF-based L1VPN <br>&gt;&gt;
application.<br>&gt;&gt;<br>&gt;&gt;Igor<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br
>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;----- Original Message ----<br>&gt
;&gt;From: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" hre
f="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;&gt
;To: Igor Bryskin
>  &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]
">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt;&gt;&lt;<a ymailto="mailto
:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; 
Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]
et">[email-masked]</a>&gt;<br>&gt;&gt;Cc: Yakov Rekhter &lt;<a ymailto="mailt
o:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;;
 Adrian Farrel <br>&gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="ma
ilto:[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:ccamp
@ops.ietf.org" href="mailto:[email-masked]">[email-masked]</a>; <a ymai
lto="mailto:[email-masked]" href="mailto:[email-masked]">softwires@ietf
.org</a><br>&gt;&gt;Sent: Friday, August 29, 2008 2:31:36 PM<br>&gt;&gt;Subject
: RE: [Softwires] BGP TE attr last call by softwires WG (2nd
>  <br>&gt;&gt;question)<br>&gt;&gt;<br>&gt;&gt;So you are proposing an OSPF ro
ute reflector?&nbsp; At what point does the <br>&gt;&gt;silliness stop?<br>&gt;
&gt;<br>&gt;&gt;&gt;-----Original Message-----<br>&gt;&gt;&gt;From: Igor Bryski
n [mailto:<a ymailto="mailto:[email-masked]" href="mailto:i_bryskin@yahoo.
com">[email-masked]</a>]<br>&gt;&gt;&gt;Sent: Friday, August 29, 2008 11:2
9 AM<br>&gt;&gt;&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt;&gt;&gt
;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href=
"mailto:[email-masked]">[email-masked]</a>; <br>&gt;&gt;&gt;<a ymailto=
"mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]
</a><br>&gt;&gt;&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires
 WG (2nd<br>&gt;&gt;&gt;question)<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Hi John,<br>&g
t;&gt;&gt;<br>&gt;&gt;&gt;No, not really. When you add a PE you configure
>  local<br>&gt;&gt;interfaces, local<br>&gt;&gt;&gt;VPN port mappings, stuff l
ike that. While doing this you will also <br>&gt;&gt;&gt;configure an IPinIP tu
nnel to one of your spoke Ps and enable L1VPN <br>&gt;&gt;&gt;OSPF instance on 
the tunnel.<br>&gt;&gt;&gt;Once you did that the local VPN information will be 
flooded<br>&gt;&gt;accross the<br>&gt;&gt;&gt;overlay, likewise, the new PE wil
l get all the necessary information <br>&gt;&gt;&gt;from other PEs.<br>&gt;&gt;
&gt;<br>&gt;&gt;&gt;Cheers,<br>&gt;&gt;&gt;Igor<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt;----- Original Message ----<br>&gt;&gt;&gt;From: "Drake, John E
" &lt;<a ymailto="mailto:[email-masked]" href="mailto:John.E.Drake2@b
oeing.com">[email-masked]</a>&gt;<br>&gt;&gt;&gt;To: Igor Bryskin &lt
;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">i_br
[email-masked]</a>&gt;; Yakov Rekhter <br>&gt;&gt;&gt;&lt;<a ymailto="mailto:y
[email-masked]"
>  href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">lberger@labn.
net</a>&gt;<br>&gt;&gt;&gt;Cc: Yakov Rekhter &lt;<a ymailto="mailto:yakov@junip
er.net" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian Farre
l <br>&gt;&gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:adri
[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:[email-masked]
.org" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="mail
to:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><
br>&gt;&gt;&gt;Sent: Friday, August 29, 2008 11:20:16 AM<br>&gt;&gt;&gt;Subject
: RE: [Softwires] BGP TE attr last call by softwires WG (2nd<br>&gt;&gt;&gt;que
stion)<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Igor,<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Does
n't this defeat auto-discovery?&nbsp; I.e., how is a new PE <br>&gt;added to a 
<br>&gt;&gt;&gt;given
>  L1VPN?<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Thanks,<br>&gt;&gt;&gt;<br>&gt;&gt;&gt
;John<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;-----Original Message-----<br>&gt;&gt;
&gt;&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href
="mailto:[email-masked]">[email-masked]</a>]<br>&gt;&gt;&gt;&gt;Sent:
 Friday, August 29, 2008 5:51 AM<br>&gt;&gt;&gt;&gt;To: Yakov Rekhter; Lou Berg
er<br>&gt;&gt;&gt;&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:ccam
[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>&g
t;&gt;&gt;&gt;<a ymailto="mailto:[email-masked]" href="mailto:softwires@iet
f.org">[email-masked]</a><br>&gt;&gt;&gt;&gt;Subject: Re: [Softwires] BGP T
E attr last call by softwires WG (2nd<br>&gt;&gt;&gt;&gt;question)<br>&gt;&gt;&
gt;&gt;<br>&gt;&gt;&gt;&gt;Yakov,<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;You sa
id:<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;... And while on
 the subject of
>  scaling, please keep in mind<br>&gt;&gt;that BGP<br>&gt;&gt;&gt;&gt;only sto
res L1VPN routes on PEs that have sites of that VPN<br>&gt;&gt;connected<br>&gt
;&gt;&gt;&gt;to them, and on an RR if used, but *not* on any of the P <br>&gt;r
outers. In <br>&gt;&gt;&gt;&gt;contrast, rfc5252 (OSPF for L1VPN<br>&gt;&gt;&gt
;&gt;autodiscovery) results in storing *all VPN TE information <br>&gt;for all 
the<br>&gt;&gt;&gt;&gt;VPNs* on *all* the IGP nodes, both P and PE. So, clearly
 BGP-based <br>&gt;&gt;&gt;&gt;approach scales better than OSPF-based approach.
<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;Yakov.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&
gt;&gt;This is not true in case of multi-instance OSPF: one can build an <br>&g
t;&gt;&gt;&gt;overlay interconnecting PEs via one or small number of Ps<br>&gt;
&gt;&gt;using IPinIP<br>&gt;&gt;&gt;&gt;tunnels and run in this overlay an inst
ance of OSPF specifically <br>&gt;&gt;&gt;&gt;designated for distribution of L1
VPN information. In
>  this<br>&gt;&gt;&gt;case the OSPF<br>&gt;&gt;&gt;&gt;solution won't scale an
y worse than the BGP approach. Note. <br>&gt;&gt;&gt;that rfc252<br>&gt;&gt;&gt
;&gt;never said that the instance of OSPF used for flooding of the L1VPN <br>&g
t;&gt;&gt;&gt;information must be the same instance that is used for the<br>&gt
;&gt;&gt;distribution<br>&gt;&gt;&gt;&gt;of IP-related LSAs.<br>&gt;&gt;&gt;&gt
;<br>&gt;&gt;&gt;&gt;Regards,<br>&gt;&gt;&gt;&gt;Igor<br>&gt;&gt;&gt;&gt;<br>&g
t;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&
gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>
&gt;<br>&gt;<br>&gt;<br>&gt;<br><br></div></div></div><br>
> 
>       </body></html>
> --0-1141253910-1220449648=:97601--

Delivery-date: Wed, 03 Sep 2008 13:51:58 +0000
Date: Wed, 3 Sep 2008 06:47:28 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)
To: "Drake, John E" <[email-masked]>, Yakov Rekhter <[email-masked]>, Lou Berger <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked], [email-masked]

--0-1141253910-1220449648=:97601
Content-Type: text/plain; charset=us-ascii

And I am not arguing that sufficient redundancy must be provided. However you said:
>For your suggested approach to work with sufficient 
>redundancy, the topology of the overlay needs to be configured 
>such that every selected P router is connected to at least two 
>other selected P routers and every PE router needs to be 
>connected to at least two selected P routers.

If you just simply interconnect all VPN-aware PEs into a single ring via IPinIP tunnels and run an instance of OSPF to distribute VPN-related information between them, it will provide sufficient redundancy and involve exactly *zero* Ps.
So, I want you to drop your lecturing tone for a minute and simply tell in what respect in your opinion this approach is not perfect fo the L1VPN application. Otherwise, I am not interested in this discussion any longer. I do like to hear comments from other people.

Igor

----- Original Message ----
From: "Drake, John E" <[email-masked]>
To: Igor Bryskin <[email-masked]>; Yakov Rekhter <[email-masked]>; Lou Berger <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel <[email-masked]>; [email-masked]; [email-masked]
Sent: Wednesday, September 3, 2008 8:10:07 AM
Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)

Igor,

Actually, I am not sure that you do understand what I wrote, because you
are providing examples of the redundancy that I specified - every PE
router needs to have connectivity to two other routers in the IGP
instance.

Thanks,

John 

>-----Original Message-----
>From: Igor Bryskin [mailto:[email-masked]] 
>Sent: Tuesday, September 02, 2008 3:06 PM
>To: Drake, John E; Yakov Rekhter; Lou Berger
>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
>[email-masked]
>Subject: Re: [Softwires] BGP TE attr last call by softwires WG 
>(2nd question)
>
>Hi John,
>
>I understand what you are saying and disagree. The overlay I 
>am talking about logically is a separate network and as any 
>network it should be sufficiently redundant to function. There 
>is a number of ways how you can address the redundancy 
>concerns. Look at the examples below:
>
>a) interconnect all VPN-aware PEs into a single ring: 
>PE=======PE
> ||                  ||
>PE               PE 
>||                   ||
>PE               PE 
>||                   ||
>...                ....
>PE=======PE
>
>b) connect each PE to two interconnected Ps 
>
>PE               P                 PE
>                    ||                  
>PE               ||                  PE 
>                    ||                  
>PE               ||                  PE 
>                    ||                  
>...                 ||                   ....
>PE               P                 PE
>
>
>Note that tunnels can traverse any number of VPN-unaware Ps and PEs.
>
>Igor
>
>
>----- Original Message ----
>From: "Drake, John E" <[email-masked]>
>To: Igor Bryskin <[email-masked]>; Yakov Rekhter 
><[email-masked]>; Lou Berger <[email-masked]>
>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel 
><[email-masked]>; [email-masked]; [email-masked]
>Sent: Tuesday, September 2, 2008 2:24:26 PM
>Subject: RE: [Softwires] BGP TE attr last call by softwires WG 
>(2nd question)
>
>Igor,
>
>Several years ago when OSPF was first proposed as an 
>autodiscovery mechanism for L1VPNs, you were told that it was 
>a bad idea due to its scaling properties and impact on the IGP.
>
>You are now tacitly agreeing with those who told you it was a bad idea.
>
>For your suggested approach to work with sufficient 
>redundancy, the topology of the overlay needs to be configured 
>such that every selected P router is connected to at least two 
>other selected P routers and every PE router needs to be 
>connected to at least two selected P routers.
>
>When you are done with this configuration, you are left with a 
>situation in which *every* PE and selected P router will have 
>*all* L1VPN routes.
>
>Thanks,
>
>John 
>
>>-----Original Message-----
>>From: Igor Bryskin [mailto:[email-masked]]
>>Sent: Friday, August 29, 2008 12:10 PM
>>To: Drake, John E; Yakov Rekhter; Lou Berger
>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
>>[email-masked]
>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd 
>>question)
>>
>>Are you calling me silly? Are you coming to Minneapolis? :=)
>>
>>Seriously, what is wrong in your opinion with this approach? 
>>Many people are talking about multi-instance IGPs. What they have in 
>>mind is improving the IGP scalability:
>>a) by removing non-IP advertisements from the instance of IGP that 
>>manages IP routing/forwarding tables into separate IGP instance(s);
>>b) by distributing non-IP information only to and via 
>inerested parties 
>>leaving the bulk of Ps out of the process.
>>
>>In my opinion this is exactly what is needed for the OSPF-based L1VPN 
>>application.
>>
>>Igor
>>
>>
>>
>>
>>
>>
>>----- Original Message ----
>>From: "Drake, John E" <[email-masked]>
>>To: Igor Bryskin <[email-masked]>; Yakov Rekhter 
>><[email-masked]>; Lou Berger <[email-masked]>
>>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel 
>><[email-masked]>; [email-masked]; [email-masked]
>>Sent: Friday, August 29, 2008 2:31:36 PM
>>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd 
>>question)
>>
>>So you are proposing an OSPF route reflector?  At what point does the 
>>silliness stop?
>>
>>>-----Original Message-----
>>>From: Igor Bryskin [mailto:[email-masked]]
>>>Sent: Friday, August 29, 2008 11:29 AM
>>>To: Drake, John E; Yakov Rekhter; Lou Berger
>>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
>>>[email-masked]
>>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
>>>question)
>>>
>>>Hi John,
>>>
>>>No, not really. When you add a PE you configure local
>>interfaces, local
>>>VPN port mappings, stuff like that. While doing this you will also 
>>>configure an IPinIP tunnel to one of your spoke Ps and enable L1VPN 
>>>OSPF instance on the tunnel.
>>>Once you did that the local VPN information will be flooded
>>accross the
>>>overlay, likewise, the new PE will get all the necessary information 
>>>from other PEs.
>>>
>>>Cheers,
>>>Igor
>>>
>>>
>>>----- Original Message ----
>>>From: "Drake, John E" <[email-masked]>
>>>To: Igor Bryskin <[email-masked]>; Yakov Rekhter 
>>><[email-masked]>; Lou Berger <[email-masked]>
>>>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel 
>>><[email-masked]>; [email-masked]; [email-masked]
>>>Sent: Friday, August 29, 2008 11:20:16 AM
>>>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd
>>>question)
>>>
>>>Igor,
>>>
>>>Doesn't this defeat auto-discovery?  I.e., how is a new PE 
>added to a 
>>>given L1VPN?
>>>
>>>Thanks,
>>>
>>>John
>>>
>>>>-----Original Message-----
>>>>From: Igor Bryskin [mailto:[email-masked]]
>>>>Sent: Friday, August 29, 2008 5:51 AM
>>>>To: Yakov Rekhter; Lou Berger
>>>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
>>>>[email-masked]
>>>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
>>>>question)
>>>>
>>>>Yakov,
>>>>
>>>>You said:
>>>>
>>>>
>>>>... And while on the subject of scaling, please keep in mind
>>that BGP
>>>>only stores L1VPN routes on PEs that have sites of that VPN
>>connected
>>>>to them, and on an RR if used, but *not* on any of the P 
>routers. In 
>>>>contrast, rfc5252 (OSPF for L1VPN
>>>>autodiscovery) results in storing *all VPN TE information 
>for all the
>>>>VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based 
>>>>approach scales better than OSPF-based approach.
>>>>
>>>>Yakov.
>>>>
>>>>This is not true in case of multi-instance OSPF: one can build an 
>>>>overlay interconnecting PEs via one or small number of Ps
>>>using IPinIP
>>>>tunnels and run in this overlay an instance of OSPF specifically 
>>>>designated for distribution of L1VPN information. In this
>>>case the OSPF
>>>>solution won't scale any worse than the BGP approach. Note. 
>>>that rfc252
>>>>never said that the instance of OSPF used for flooding of the L1VPN 
>>>>information must be the same instance that is used for the
>>>distribution
>>>>of IP-related LSAs.
>>>>
>>>>Regards,
>>>>Igor
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
>

--0-1141253910-1220449648=:97601
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div>And I am not arguing that sufficient redundancy must be provided. However you said:<br>&gt;For your suggested approach to work with sufficient <br>&gt;redundancy, the topology of the overlay needs to be configured <br>&gt;such that every selected P router is connected to at least two <br>&gt;other selected P routers and every PE router needs to be <br>&gt;connected to at least two selected P routers.<br><br>If you just simply interconnect all VPN-aware PEs into a single ring via IPinIP tunnels and run an instance of OSPF to distribute VPN-related information between them, it will provide sufficient redundancy and involve exactly *zero* Ps.<br>So, I want you to drop your lecturing tone for a minute and simply tell in what respect in your opinion this approach is not perfect fo the L1VPN
 application. Otherwise, I am not interested in this discussion any longer. I do like to hear comments from other people.<br><br>Igor <br><br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;">----- Original Message ----<br>From: "Drake, John E" &lt;[email-masked]&gt;<br>To: Igor Bryskin &lt;[email-masked]&gt;; Yakov Rekhter &lt;[email-masked]&gt;; Lou Berger &lt;[email-masked]&gt;<br>Cc: Yakov Rekhter &lt;[email-masked]&gt;; Adrian Farrel &lt;[email-masked]&gt;; [email-masked]; [email-masked]<br>Sent: Wednesday, September 3, 2008 8:10:07 AM<br>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)<br><br>
Igor,<br><br>Actually, I am not sure that you do understand what I wrote, because you<br>are providing examples of the redundancy that I specified - every PE<br>router needs to have connectivity to two other routers in the IGP<br>instance.<br><br>Thanks,<br><br>John <br><br>&gt;-----Original Message-----<br>&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>] <br>&gt;Sent: Tuesday, September 02, 2008 3:06 PM<br>&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG <br>&gt;(2nd question)<br>&gt;<br>&gt;Hi John,<br>&gt;<br>&gt;I understand what you are saying and disagree. The
 overlay I <br>&gt;am talking about logically is a separate network and as any <br>&gt;network it should be sufficiently redundant to function. There <br>&gt;is a number of ways how you can address the redundancy <br>&gt;concerns. Look at the examples below:<br>&gt;<br>&gt;a) interconnect all VPN-aware PEs into a single ring: <br>&gt;PE=======PE<br>&gt; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||<br>&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  PE <br>&gt;||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||<br>&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  PE <br>&gt;||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||<br>&gt;...&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ....<br>&gt;PE=======PE<br>&gt;<br>&gt;b) connect each PE to two interconnected Ps <br>&gt;<br>&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  P&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
 &nbsp;  PE<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  <br>&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PE <br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PE <br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>&gt;...&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ....<br>&gt;PE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  P&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
 PE<br>&gt;<br>&gt;<br>&gt;Note that tunnels can traverse any number of VPN-unaware Ps and PEs.<br>&gt;<br>&gt;Igor<br>&gt;<br>&gt;<br>&gt;----- Original Message ----<br>&gt;From: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;Cc: Yakov Rekhter &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian Farrel <br>&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; <a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;Sent: Tuesday, September 2, 2008 2:24:26 PM<br>&gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG <br>&gt;(2nd question)<br>&gt;<br>&gt;Igor,<br>&gt;<br>&gt;Several years ago when OSPF was first proposed as an <br>&gt;autodiscovery mechanism for L1VPNs, you were told that it was <br>&gt;a bad idea due to its scaling properties and impact on the IGP.<br>&gt;<br>&gt;You are now tacitly agreeing with those who told you it was a bad idea.<br>&gt;<br>&gt;For your suggested approach to work with sufficient <br>&gt;redundancy, the topology of the overlay needs to be configured <br>&gt;such that every selected P router is connected to at least two <br>&gt;other selected P routers and every PE router needs to be <br>&gt;connected to at least two selected
 P routers.<br>&gt;<br>&gt;When you are done with this configuration, you are left with a <br>&gt;situation in which *every* PE and selected P router will have <br>&gt;*all* L1VPN routes.<br>&gt;<br>&gt;Thanks,<br>&gt;<br>&gt;John <br>&gt;<br>&gt;&gt;-----Original Message-----<br>&gt;&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>]<br>&gt;&gt;Sent: Friday, August 29, 2008 12:10 PM<br>&gt;&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt;&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>&gt;&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd <br>&gt;&gt;question)<br>&gt;&gt;<br>&gt;&gt;Are you calling me silly? Are you coming to Minneapolis?
 :=)<br>&gt;&gt;<br>&gt;&gt;Seriously, what is wrong in your opinion with this approach? <br>&gt;&gt;Many people are talking about multi-instance IGPs. What they have in <br>&gt;&gt;mind is improving the IGP scalability:<br>&gt;&gt;a) by removing non-IP advertisements from the instance of IGP that <br>&gt;&gt;manages IP routing/forwarding tables into separate IGP instance(s);<br>&gt;&gt;b) by distributing non-IP information only to and via <br>&gt;inerested parties <br>&gt;&gt;leaving the bulk of Ps out of the process.<br>&gt;&gt;<br>&gt;&gt;In my opinion this is exactly what is needed for the OSPF-based L1VPN <br>&gt;&gt;application.<br>&gt;&gt;<br>&gt;&gt;Igor<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;----- Original Message ----<br>&gt;&gt;From: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;&gt;To: Igor Bryskin
 &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;&gt;Cc: Yakov Rekhter &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian Farrel <br>&gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;&gt;Sent: Friday, August 29, 2008 2:31:36 PM<br>&gt;&gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd
 <br>&gt;&gt;question)<br>&gt;&gt;<br>&gt;&gt;So you are proposing an OSPF route reflector?&nbsp; At what point does the <br>&gt;&gt;silliness stop?<br>&gt;&gt;<br>&gt;&gt;&gt;-----Original Message-----<br>&gt;&gt;&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>]<br>&gt;&gt;&gt;Sent: Friday, August 29, 2008 11:29 AM<br>&gt;&gt;&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt;&gt;&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>&gt;&gt;&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;&gt;&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd<br>&gt;&gt;&gt;question)<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Hi John,<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;No, not really. When you add a PE you configure
 local<br>&gt;&gt;interfaces, local<br>&gt;&gt;&gt;VPN port mappings, stuff like that. While doing this you will also <br>&gt;&gt;&gt;configure an IPinIP tunnel to one of your spoke Ps and enable L1VPN <br>&gt;&gt;&gt;OSPF instance on the tunnel.<br>&gt;&gt;&gt;Once you did that the local VPN information will be flooded<br>&gt;&gt;accross the<br>&gt;&gt;&gt;overlay, likewise, the new PE will get all the necessary information <br>&gt;&gt;&gt;from other PEs.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Cheers,<br>&gt;&gt;&gt;Igor<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;----- Original Message ----<br>&gt;&gt;&gt;From: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;&gt;&gt;To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt;&gt;&gt;&lt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;&gt;&gt;Cc: Yakov Rekhter &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian Farrel <br>&gt;&gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;&gt;&gt;Sent: Friday, August 29, 2008 11:20:16 AM<br>&gt;&gt;&gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd<br>&gt;&gt;&gt;question)<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Igor,<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Doesn't this defeat auto-discovery?&nbsp; I.e., how is a new PE <br>&gt;added to a <br>&gt;&gt;&gt;given
 L1VPN?<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Thanks,<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;John<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;-----Original Message-----<br>&gt;&gt;&gt;&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>]<br>&gt;&gt;&gt;&gt;Sent: Friday, August 29, 2008 5:51 AM<br>&gt;&gt;&gt;&gt;To: Yakov Rekhter; Lou Berger<br>&gt;&gt;&gt;&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>&gt;&gt;&gt;&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;&gt;&gt;&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd<br>&gt;&gt;&gt;&gt;question)<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;Yakov,<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;You said:<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;... And while on the subject of
 scaling, please keep in mind<br>&gt;&gt;that BGP<br>&gt;&gt;&gt;&gt;only stores L1VPN routes on PEs that have sites of that VPN<br>&gt;&gt;connected<br>&gt;&gt;&gt;&gt;to them, and on an RR if used, but *not* on any of the P <br>&gt;routers. In <br>&gt;&gt;&gt;&gt;contrast, rfc5252 (OSPF for L1VPN<br>&gt;&gt;&gt;&gt;autodiscovery) results in storing *all VPN TE information <br>&gt;for all the<br>&gt;&gt;&gt;&gt;VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based <br>&gt;&gt;&gt;&gt;approach scales better than OSPF-based approach.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;Yakov.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;This is not true in case of multi-instance OSPF: one can build an <br>&gt;&gt;&gt;&gt;overlay interconnecting PEs via one or small number of Ps<br>&gt;&gt;&gt;using IPinIP<br>&gt;&gt;&gt;&gt;tunnels and run in this overlay an instance of OSPF specifically <br>&gt;&gt;&gt;&gt;designated for distribution of L1VPN information. In
 this<br>&gt;&gt;&gt;case the OSPF<br>&gt;&gt;&gt;&gt;solution won't scale any worse than the BGP approach. Note. <br>&gt;&gt;&gt;that rfc252<br>&gt;&gt;&gt;&gt;never said that the instance of OSPF used for flooding of the L1VPN <br>&gt;&gt;&gt;&gt;information must be the same instance that is used for the<br>&gt;&gt;&gt;distribution<br>&gt;&gt;&gt;&gt;of IP-related LSAs.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;Regards,<br>&gt;&gt;&gt;&gt;Igor<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;<br>&gt;<br>&gt;<br>&gt;<br><br></div></div></div><br>

      </body></html>
--0-1141253910-1220449648=:97601--

Delivery-date: Wed, 03 Sep 2008 12:25:39 +0000
Date: Wed, 03 Sep 2008 08:21:18 -0400
To: Yakov Rekhter <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) 
Cc: Lou Berger <[email-masked]>,Yakov Rekhter <[email-masked]>, Adrian Farrel <[email-masked]>,[email-masked], [email-masked]

At 05:30 PM 9/2/2008, Yakov Rekhter wrote:

>Here is the text I'll add to the spec to discuss this issue:
>
>      Use of Traffic Engineering Attribute does not increase the number
>      of routes.
>
>      When the routes differ in other than the Traffic Engineering
>      Attribute (e.g., differ in the set of Route Targets, and/or
>      NEXT_HOP), use of Traffic Engineering Attribute has no impact
>      on the number of BGP Update messages required to carry the routes.
>      Only when the routes have all, but the Traffic Engineering
>      Attribute the same, use of the attribute may increase the number
>      of BGP Update messages required to carry the routes.
>
>Yakov.

Is this from babel fish?  How about:

Use of Traffic Engineering Attribute does not increase the number
of routes, but may increase the number of BGP Update messages
required to distribute the routes.

When the routes differ in other than the Traffic Engineering
Attribute (e.g., differ in the set of Route Targets, and/or
NEXT_HOP), use of Traffic Engineering Attribute has no impact
on the number of BGP Update messages required to carry the routes.
There is also no impact when routes share all other attribute
information and have an aggregated or identical Traffic Engineering Attribute.
When routes share all other attribute information and have different
Traffic Engineering Attributes, routes must be distributed in
per-route BGP Update messages rather than a single message.

Lou

Delivery-date: Wed, 03 Sep 2008 12:19:47 +0000
Content-class: urn:content-classes:message
Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)
Date: Wed, 3 Sep 2008 05:10:07 -0700
From: "Drake, John E" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>, "Yakov Rekhter" <[email-masked]>, "Lou Berger" <[email-masked]>
Cc: "Yakov Rekhter" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>, <[email-masked]>

Igor,

Actually, I am not sure that you do understand what I wrote, because you
are providing examples of the redundancy that I specified - every PE
router needs to have connectivity to two other routers in the IGP
instance.

Thanks,

John=20

>-----Original Message-----
>From: Igor Bryskin [mailto:[email-masked]]=20
>Sent: Tuesday, September 02, 2008 3:06 PM
>To: Drake, John E; Yakov Rekhter; Lou Berger
>Cc: Yakov Rekhter; Adrian Farrel; [email-masked];=20
>[email-masked]
>Subject: Re: [Softwires] BGP TE attr last call by softwires WG=20
>(2nd question)
>
>Hi John,
>
>I understand what you are saying and disagree. The overlay I=20
>am talking about logically is a separate network and as any=20
>network it should be sufficiently redundant to function. There=20
>is a number of ways how you can address the redundancy=20
>concerns. Look at the examples below:
>
>a) interconnect all VPN-aware PEs into a single ring:=20
>PE=3D=3D=3D=3D=3D=3D=3DPE
> ||                  ||
>PE               PE=20
>||                   ||
>PE               PE=20
>||                   ||
>...                ....
>PE=3D=3D=3D=3D=3D=3D=3DPE
>
>b) connect each PE to two interconnected Ps=20
>
>PE               P                 PE
>                    ||                  =20
>PE               ||                  PE=20
>                    ||                 =20
>PE               ||                  PE=20
>                    ||                 =20
>...                 ||                   ....
>PE               P                 PE
>
>
>Note that tunnels can traverse any number of VPN-unaware Ps and PEs.
>
>Igor
>
>
>----- Original Message ----
>From: "Drake, John E" <[email-masked]>
>To: Igor Bryskin <[email-masked]>; Yakov Rekhter=20
><[email-masked]>; Lou Berger <[email-masked]>
>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel=20
><[email-masked]>; [email-masked]; [email-masked]
>Sent: Tuesday, September 2, 2008 2:24:26 PM
>Subject: RE: [Softwires] BGP TE attr last call by softwires WG=20
>(2nd question)
>
>Igor,
>
>Several years ago when OSPF was first proposed as an=20
>autodiscovery mechanism for L1VPNs, you were told that it was=20
>a bad idea due to its scaling properties and impact on the IGP.
>
>You are now tacitly agreeing with those who told you it was a bad idea.
>
>For your suggested approach to work with sufficient=20
>redundancy, the topology of the overlay needs to be configured=20
>such that every selected P router is connected to at least two=20
>other selected P routers and every PE router needs to be=20
>connected to at least two selected P routers.
>
>When you are done with this configuration, you are left with a=20
>situation in which *every* PE and selected P router will have=20
>*all* L1VPN routes.
>
>Thanks,
>
>John=20
>
>>-----Original Message-----
>>From: Igor Bryskin [mailto:[email-masked]]
>>Sent: Friday, August 29, 2008 12:10 PM
>>To: Drake, John E; Yakov Rekhter; Lou Berger
>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked];=20
>>[email-masked]
>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd=20
>>question)
>>
>>Are you calling me silly? Are you coming to Minneapolis? :=3D)
>>
>>Seriously, what is wrong in your opinion with this approach?=20
>>Many people are talking about multi-instance IGPs. What they have in=20
>>mind is improving the IGP scalability:
>>a) by removing non-IP advertisements from the instance of IGP that=20
>>manages IP routing/forwarding tables into separate IGP instance(s);
>>b) by distributing non-IP information only to and via=20
>inerested parties=20
>>leaving the bulk of Ps out of the process.
>>
>>In my opinion this is exactly what is needed for the OSPF-based L1VPN=20
>>application.
>>
>>Igor
>>
>>
>>
>>
>>
>>
>>----- Original Message ----
>>From: "Drake, John E" <[email-masked]>
>>To: Igor Bryskin <[email-masked]>; Yakov Rekhter=20
>><[email-masked]>; Lou Berger <[email-masked]>
>>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel=20
>><[email-masked]>; [email-masked]; [email-masked]
>>Sent: Friday, August 29, 2008 2:31:36 PM
>>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd=20
>>question)
>>
>>So you are proposing an OSPF route reflector?  At what point does the=20
>>silliness stop?
>>
>>>-----Original Message-----
>>>From: Igor Bryskin [mailto:[email-masked]]
>>>Sent: Friday, August 29, 2008 11:29 AM
>>>To: Drake, John E; Yakov Rekhter; Lou Berger
>>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked];=20
>>>[email-masked]
>>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
>>>question)
>>>
>>>Hi John,
>>>
>>>No, not really. When you add a PE you configure local
>>interfaces, local
>>>VPN port mappings, stuff like that. While doing this you will also=20
>>>configure an IPinIP tunnel to one of your spoke Ps and enable L1VPN=20
>>>OSPF instance on the tunnel.
>>>Once you did that the local VPN information will be flooded
>>accross the
>>>overlay, likewise, the new PE will get all the necessary information=20
>>>from other PEs.
>>>
>>>Cheers,
>>>Igor
>>>
>>>
>>>----- Original Message ----
>>>From: "Drake, John E" <[email-masked]>
>>>To: Igor Bryskin <[email-masked]>; Yakov Rekhter=20
>>><[email-masked]>; Lou Berger <[email-masked]>
>>>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel=20
>>><[email-masked]>; [email-masked]; [email-masked]
>>>Sent: Friday, August 29, 2008 11:20:16 AM
>>>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd
>>>question)
>>>
>>>Igor,
>>>
>>>Doesn't this defeat auto-discovery?  I.e., how is a new PE=20
>added to a=20
>>>given L1VPN?
>>>
>>>Thanks,
>>>
>>>John
>>>
>>>>-----Original Message-----
>>>>From: Igor Bryskin [mailto:[email-masked]]
>>>>Sent: Friday, August 29, 2008 5:51 AM
>>>>To: Yakov Rekhter; Lou Berger
>>>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked];=20
>>>>[email-masked]
>>>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
>>>>question)
>>>>
>>>>Yakov,
>>>>
>>>>You said:
>>>>
>>>>
>>>>... And while on the subject of scaling, please keep in mind
>>that BGP
>>>>only stores L1VPN routes on PEs that have sites of that VPN
>>connected
>>>>to them, and on an RR if used, but *not* on any of the P=20
>routers. In=20
>>>>contrast, rfc5252 (OSPF for L1VPN
>>>>autodiscovery) results in storing *all VPN TE information=20
>for all the
>>>>VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based=20
>>>>approach scales better than OSPF-based approach.
>>>>
>>>>Yakov.
>>>>
>>>>This is not true in case of multi-instance OSPF: one can build an=20
>>>>overlay interconnecting PEs via one or small number of Ps
>>>using IPinIP
>>>>tunnels and run in this overlay an instance of OSPF specifically=20
>>>>designated for distribution of L1VPN information. In this
>>>case the OSPF
>>>>solution won't scale any worse than the BGP approach. Note.=20
>>>that rfc252
>>>>never said that the instance of OSPF used for flooding of the L1VPN=20
>>>>information must be the same instance that is used for the
>>>distribution
>>>>of IP-related LSAs.
>>>>
>>>>Regards,
>>>>Igor
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
>

Delivery-date: Tue, 02 Sep 2008 22:36:42 +0000
To: Lou Berger <[email-masked]>
cc: Yakov Rekhter <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) 
Date: Tue, 02 Sep 2008 14:30:38 -0700
From: Yakov Rekhter <[email-masked]>

Lou,

> Yakov,
>          See below.

see in-line...

> At 07:47 PM 8/28/2008, Yakov Rekhter wrote:
> >Lou,
> >
> > > Yakov,
> > >          see below.
> > >
> > > At 12:00 PM 8/28/2008, Yakov Rekhter wrote:
> > > >Lou,
> > > >
> > > > > At 12:02 PM 8/27/2008, Yakov Rekhter wrote:
> > > > > >Lou,
> > > > > >
> > > > > > > If you drop the "unless they share identical Traffic Engineering
> > > > > > > Attributes" then we have alignment.
> > > > > >
> > > > > >If they do share identical TE attributes, then there is no
> > > > > >problem  to aggregate such routes. So, the current text is correct.
> > > > > >
> > > > > >Yakov.
> > > > >
> > > > > I think you need some additional semantic and aggregation function
> > > > > definition if you want to aggregate. (For example: Does the TE
> > > > > aggregate represent the resources available to *each* route or to
> > > > > *all* the routes?  If the latter, what's the distribution function?)
> > > >
> > > >Constructing BGP TE attribute when aggregating routes with identical
> > > >BGP TE attributes follows procedure of rfc4201.
> > >
> > > ahh, that wasn't obvious.  Need some specific language to that effect.
> >
> >Sure. To make it obvious I'll add the following:
> >
> >   Constructing BGP TE attribute when aggregating routes with identical
> >   BGP TE attributes follows procedure of rfc4201.
> 
> great.
> 
> >
> > > > > Also I think some discussion on impact on scaling is
> > > > > warranted.  (consider the case where each <PPI, CPI> tuple from a PE
> > > > > now needs it's own advisement due to dissimilar TE 
> > information per port.)
> > > >
> > > >As I said before, the granularity of L1VPN auto-discovery advertisements
> > > >is a single PE-CE port anyway. So, each <PPI, CPI> tuple from a PE
> > > >forms its own route anyway.
> > >
> > > Sure, but as the doc says more than one NLRI can be included in a
> > > MP_REACH_NLRI  attribute.
> >
> >That does not change the number of routes that PEs and RRs have
> >to maintain.
> 
> sure, but there's potential for significant impact on number/size of 
> advertisements and corresponding processing.
> 
> > > >And while on the subject of scaling, please keep in mind that BGP
> > > >only stores L1VPN routes on PEs that have sites of that VPN connected
> > > >to them, and on an RR if used, but *not* on any of the P routers. In
> > > >contrast, rfc5252 (OSPF for L1VPN autodiscovery) results in storing
> > > >*all VPN TE information for all the VPNs* on *all* the IGP nodes, both P
> > > >and PE. So, clearly BGP-based approach scales better than OSPF-based
> > > >approach.
> > >
> > > sure this is made clear in the l1vpn document.  What isn't made clear
> > > is that, per this document, when TE attributes cannot be aggregated,
> > > each <PPI, CPI> tuple needs its own MP_REACH_NLRI attribute *and*
> > > advertisement.
> >
> >It would be quite clear if you would read base BGP spec (which is
> >quoted as a Normative Refence in this document). Quoting Section
> >3.1 of BGP spec (rfc4271):
> >
> >    Multiple routes that have the same path attributes can be advertised
> >    in a single UPDATE message by including multiple prefixes in the NLRI
> >    field of the UPDATE message.
> 
> I believe it is both worthwhile and appropriate to discuss how this 
> draft impacts/relates to scaling.  In essence, I'm suggesting a 
> similar/parallel to section 5 of rfc 5195.  (which also states things 
> that are "quite clear if you would read" BGP specs.)

Here is the text I'll add to the spec to discuss this issue:

     Use of Traffic Engineering Attribute does not increase the number
     of routes.
  
     When the routes differ in other than the Traffic Engineering
     Attribute (e.g., differ in the set of Route Targets, and/or
     NEXT_HOP), use of Traffic Engineering Attribute has no impact
     on the number of BGP Update messages required to carry the routes.
     Only when the routes have all, but the Traffic Engineering
     Attribute the same, use of the attribute may increase the number
     of BGP Update messages required to carry the routes.

Yakov.

Delivery-date: Tue, 02 Sep 2008 22:10:21 +0000
Date: Tue, 2 Sep 2008 15:06:17 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)
To: "Drake, John E" <[email-masked]>, Yakov Rekhter <[email-masked]>, Lou Berger <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked], [email-masked]

--0-1815314846-1220393177=:49291
Content-Type: text/plain; charset=us-ascii

Hi John,

I understand what you are saying and disagree. The overlay I am talking about logically is a separate network and as any network it should be sufficiently redundant to function. There is a number of ways how you can address the redundancy concerns. Look at the examples below:

a) interconnect all VPN-aware PEs into a single ring: 
PE=======PE
 ||                  ||
PE               PE 
 ||                   ||
PE               PE 
||                   ||
...                ....
PE=======PE

b) connect each PE to two interconnected Ps 

PE               P                 PE
                    ||                   
PE               ||                  PE 
                    ||                  
PE               ||                  PE 
                    ||                  
...                 ||                   ....
PE               P                 PE

Note that tunnels can traverse any number of VPN-unaware Ps and PEs.

Igor

----- Original Message ----
From: "Drake, John E" <[email-masked]>
To: Igor Bryskin <[email-masked]>; Yakov Rekhter <[email-masked]>; Lou Berger <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel <[email-masked]>; [email-masked]; [email-masked]
Sent: Tuesday, September 2, 2008 2:24:26 PM
Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)

Igor,

Several years ago when OSPF was first proposed as an autodiscovery
mechanism for L1VPNs, you were told that it was a bad idea due to its
scaling properties and impact on the IGP.

You are now tacitly agreeing with those who told you it was a bad idea.

For your suggested approach to work with sufficient redundancy, the
topology of the overlay needs to be configured such that every selected
P router is connected to at least two other selected P routers and every
PE router needs to be connected to at least two selected P routers.

When you are done with this configuration, you are left with a situation
in which *every* PE and selected P router will have *all* L1VPN routes.

Thanks,

John 

>-----Original Message-----
>From: Igor Bryskin [mailto:[email-masked]] 
>Sent: Friday, August 29, 2008 12:10 PM
>To: Drake, John E; Yakov Rekhter; Lou Berger
>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
>[email-masked]
>Subject: Re: [Softwires] BGP TE attr last call by softwires WG 
>(2nd question)
>
>Are you calling me silly? Are you coming to Minneapolis? :=)
>
>Seriously, what is wrong in your opinion with this approach? 
>Many people are talking about multi-instance IGPs. What they 
>have in mind is improving the IGP scalability:
>a) by removing non-IP advertisements from the instance of IGP 
>that manages IP routing/forwarding tables into separate IGP 
>instance(s);
>b) by distributing non-IP information only to and via 
>inerested parties leaving the bulk of Ps out of the process.
>
>In my opinion this is exactly what is needed for the 
>OSPF-based L1VPN application.
>
>Igor
>
>
>
>
>
>
>----- Original Message ----
>From: "Drake, John E" <[email-masked]>
>To: Igor Bryskin <[email-masked]>; Yakov Rekhter 
><[email-masked]>; Lou Berger <[email-masked]>
>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel 
><[email-masked]>; [email-masked]; [email-masked]
>Sent: Friday, August 29, 2008 2:31:36 PM
>Subject: RE: [Softwires] BGP TE attr last call by softwires WG 
>(2nd question)
>
>So you are proposing an OSPF route reflector?  At what point 
>does the silliness stop? 
>
>>-----Original Message-----
>>From: Igor Bryskin [mailto:[email-masked]]
>>Sent: Friday, August 29, 2008 11:29 AM
>>To: Drake, John E; Yakov Rekhter; Lou Berger
>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
>>[email-masked]
>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd 
>>question)
>>
>>Hi John,
>>
>>No, not really. When you add a PE you configure local 
>interfaces, local 
>>VPN port mappings, stuff like that. While doing this you will also 
>>configure an IPinIP tunnel to one of your spoke Ps and enable L1VPN 
>>OSPF instance on the tunnel.
>>Once you did that the local VPN information will be flooded 
>accross the 
>>overlay, likewise, the new PE will get all the necessary information 
>>from other PEs.
>>
>>Cheers,
>>Igor
>>
>>
>>----- Original Message ----
>>From: "Drake, John E" <[email-masked]>
>>To: Igor Bryskin <[email-masked]>; Yakov Rekhter 
>><[email-masked]>; Lou Berger <[email-masked]>
>>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel 
>><[email-masked]>; [email-masked]; [email-masked]
>>Sent: Friday, August 29, 2008 11:20:16 AM
>>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd 
>>question)
>>
>>Igor,
>>
>>Doesn't this defeat auto-discovery?  I.e., how is a new PE added to a 
>>given L1VPN?
>>
>>Thanks,
>>
>>John
>>
>>>-----Original Message-----
>>>From: Igor Bryskin [mailto:[email-masked]]
>>>Sent: Friday, August 29, 2008 5:51 AM
>>>To: Yakov Rekhter; Lou Berger
>>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked]; 
>>>[email-masked]
>>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
>>>question)
>>>
>>>Yakov,
>>>
>>>You said:
>>>
>>>
>>>... And while on the subject of scaling, please keep in mind 
>that BGP 
>>>only stores L1VPN routes on PEs that have sites of that VPN 
>connected 
>>>to them, and on an RR if used, but *not* on any of the P routers. In 
>>>contrast, rfc5252 (OSPF for L1VPN
>>>autodiscovery) results in storing *all VPN TE information for all the
>>>VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based 
>>>approach scales better than OSPF-based approach.
>>>
>>>Yakov.
>>>
>>>This is not true in case of multi-instance OSPF: one can build an 
>>>overlay interconnecting PEs via one or small number of Ps
>>using IPinIP
>>>tunnels and run in this overlay an instance of OSPF specifically 
>>>designated for distribution of L1VPN information. In this
>>case the OSPF
>>>solution won't scale any worse than the BGP approach. Note. 
>>that rfc252
>>>never said that the instance of OSPF used for flooding of the L1VPN 
>>>information must be the same instance that is used for the
>>distribution
>>>of IP-related LSAs.
>>>
>>>Regards,
>>>Igor
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>

--0-1815314846-1220393177=:49291
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div>Hi John,<br><br> I understand what you are saying and disagree. The overlay I am talking about logically is a separate network and as any network it should be sufficiently redundant to function. There is a number of ways how you can address the redundancy concerns. Look at the examples below:<br><br>a) interconnect all VPN-aware PEs into a single ring: <br>PE=======PE<br>&nbsp;|| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; ||<br>
PE &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PE <br> || &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp; ||<br>
PE &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PE <br><!-- ORIGINAL -->||&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; ||<br>...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; ....<br>PE=======PE<br><br>b) connect each PE to two interconnected Ps <br><br>PE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; P&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PE<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; || &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>

PE &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; || &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; PE <br><!-- ORIGINAL -->&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp; || &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; <br>

PE &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; || &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; PE <br><!-- ORIGINAL -->&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; || &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; <br>
...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ....<br>
PE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; P&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PE<br><br><br>Note that tunnels can traverse any number of VPN-unaware Ps and PEs.<br><br>Igor<br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;">----- Original Message ----<br>From: "Drake, John E" &lt;[email-masked]&gt;<br>To: Igor Bryskin &lt;[email-masked]&gt;; Yakov Rekhter &lt;[email-masked]&gt;; Lou Berger &lt;[email-masked]&gt;<br>Cc: Yakov Rekhter &lt;[email-masked]&gt;; Adrian Farrel &lt;[email-masked]&gt;; [email-masked]; [email-masked]<br>Sent: Tuesday, September 2, 2008 2:24:26 PM<br>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)<br><br>
Igor,<br><br>Several years ago when OSPF was first proposed as an autodiscovery<br>mechanism for L1VPNs, you were told that it was a bad idea due to its<br>scaling properties and impact on the IGP.<br><br>You are now tacitly agreeing with those who told you it was a bad idea.<br><br>For your suggested approach to work with sufficient redundancy, the<br>topology of the overlay needs to be configured such that every selected<br>P router is connected to at least two other selected P routers and every<br>PE router needs to be connected to at least two selected P routers.<br><br>When you are done with this configuration, you are left with a situation<br>in which *every* PE and selected P router will have *all* L1VPN routes.<br><br>Thanks,<br><br>John <br><br>&gt;-----Original Message-----<br>&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>] <br>&gt;Sent: Friday, August 29, 2008
 12:10 PM<br>&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG <br>&gt;(2nd question)<br>&gt;<br>&gt;Are you calling me silly? Are you coming to Minneapolis? :=)<br>&gt;<br>&gt;Seriously, what is wrong in your opinion with this approach? <br>&gt;Many people are talking about multi-instance IGPs. What they <br>&gt;have in mind is improving the IGP scalability:<br>&gt;a) by removing non-IP advertisements from the instance of IGP <br>&gt;that manages IP routing/forwarding tables into separate IGP <br>&gt;instance(s);<br>&gt;b) by distributing non-IP information only to and via <br>&gt;inerested parties leaving the bulk of Ps out of the
 process.<br>&gt;<br>&gt;In my opinion this is exactly what is needed for the <br>&gt;OSPF-based L1VPN application.<br>&gt;<br>&gt;Igor<br>&gt;<br>&gt;<br>&gt;<br>&gt;<br>&gt;<br>&gt;<br>&gt;----- Original Message ----<br>&gt;From: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;Cc: Yakov Rekhter &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian Farrel <br>&gt;&lt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;Sent: Friday, August 29, 2008 2:31:36 PM<br>&gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG <br>&gt;(2nd question)<br>&gt;<br>&gt;So you are proposing an OSPF route reflector?&nbsp; At what point <br>&gt;does the silliness stop? <br>&gt;<br>&gt;&gt;-----Original Message-----<br>&gt;&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>]<br>&gt;&gt;Sent: Friday, August 29, 2008 11:29 AM<br>&gt;&gt;To: Drake, John E; Yakov Rekhter; Lou Berger<br>&gt;&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>&gt;&gt;<a
 ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd <br>&gt;&gt;question)<br>&gt;&gt;<br>&gt;&gt;Hi John,<br>&gt;&gt;<br>&gt;&gt;No, not really. When you add a PE you configure local <br>&gt;interfaces, local <br>&gt;&gt;VPN port mappings, stuff like that. While doing this you will also <br>&gt;&gt;configure an IPinIP tunnel to one of your spoke Ps and enable L1VPN <br>&gt;&gt;OSPF instance on the tunnel.<br>&gt;&gt;Once you did that the local VPN information will be flooded <br>&gt;accross the <br>&gt;&gt;overlay, likewise, the new PE will get all the necessary information <br>&gt;&gt;from other PEs.<br>&gt;&gt;<br>&gt;&gt;Cheers,<br>&gt;&gt;Igor<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;----- Original Message ----<br>&gt;&gt;From: "Drake, John E" &lt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;&gt;To: Igor Bryskin &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Yakov Rekhter <br>&gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Lou Berger &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt;&gt;Cc: Yakov Rekhter &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; Adrian Farrel <br>&gt;&gt;&lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;&gt;Sent: Friday, August 29, 2008 11:20:16
 AM<br>&gt;&gt;Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd <br>&gt;&gt;question)<br>&gt;&gt;<br>&gt;&gt;Igor,<br>&gt;&gt;<br>&gt;&gt;Doesn't this defeat auto-discovery?&nbsp; I.e., how is a new PE added to a <br>&gt;&gt;given L1VPN?<br>&gt;&gt;<br>&gt;&gt;Thanks,<br>&gt;&gt;<br>&gt;&gt;John<br>&gt;&gt;<br>&gt;&gt;&gt;-----Original Message-----<br>&gt;&gt;&gt;From: Igor Bryskin [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>]<br>&gt;&gt;&gt;Sent: Friday, August 29, 2008 5:51 AM<br>&gt;&gt;&gt;To: Yakov Rekhter; Lou Berger<br>&gt;&gt;&gt;Cc: Yakov Rekhter; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>; <br>&gt;&gt;&gt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt;&gt;&gt;Subject: Re: [Softwires] BGP TE attr last call by softwires WG
 (2nd<br>&gt;&gt;&gt;question)<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Yakov,<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;You said:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;... And while on the subject of scaling, please keep in mind <br>&gt;that BGP <br>&gt;&gt;&gt;only stores L1VPN routes on PEs that have sites of that VPN <br>&gt;connected <br>&gt;&gt;&gt;to them, and on an RR if used, but *not* on any of the P routers. In <br>&gt;&gt;&gt;contrast, rfc5252 (OSPF for L1VPN<br>&gt;&gt;&gt;autodiscovery) results in storing *all VPN TE information for all the<br>&gt;&gt;&gt;VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based <br>&gt;&gt;&gt;approach scales better than OSPF-based approach.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Yakov.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;This is not true in case of multi-instance OSPF: one can build an <br>&gt;&gt;&gt;overlay interconnecting PEs via one or small number of Ps<br>&gt;&gt;using IPinIP<br>&gt;&gt;&gt;tunnels and run in this
 overlay an instance of OSPF specifically <br>&gt;&gt;&gt;designated for distribution of L1VPN information. In this<br>&gt;&gt;case the OSPF<br>&gt;&gt;&gt;solution won't scale any worse than the BGP approach. Note. <br>&gt;&gt;that rfc252<br>&gt;&gt;&gt;never said that the instance of OSPF used for flooding of the L1VPN <br>&gt;&gt;&gt;information must be the same instance that is used for the<br>&gt;&gt;distribution<br>&gt;&gt;&gt;of IP-related LSAs.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;Regards,<br>&gt;&gt;&gt;Igor<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;<br>&gt;<br>&gt;<br><br></div></div></div><br>

      </body></html>
--0-1815314846-1220393177=:49291--

Delivery-date: Tue, 02 Sep 2008 21:58:26 +0000
Date: Tue, 02 Sep 2008 22:47:24 +0100
Subject: Re: R: Re: [mpls-tp] mpls-tp Dual stack DCN? (was  MPLS over OTN)
From: Ben Niven-Jenkins <[email-masked]>
To: Dieter Beller <[email-masked]>, Diego Caviglia <[email-masked]>
CC: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

That is not a problem for IETF though.  Ben

On 29/08/2008 10:07, "Dieter Beller" <[email-masked]> wrote:

> ... resent this mail because it did not appear on the mailing lists  :-( .
> 
> Hi Diego,
> 
> 
> Diego Caviglia wrote:
>>  
>> Stewart,
>>            I think i agree here.
>> 
>> Even if i'm coming from sdh i don'e see the need to hane osi capability
>> in brand new mpls-tp boxes.
>>   
> I actually do not fully agree here. If, due to historical reasons, the
> existing DCN
> is an OSI network and if the new MPLS-TP boxes will only understand IP and
> have
> to use the existing OSI-based DCN, then the new MPLS-TP boxes need to support
> at least tunneling of IP over CLNP tunnels. Otherwise, a dual stack DCN would
> indeed be needed (I am assuming here that the existing OSI-only DCN cannot be
> turned into an IP-only DCN).
> 
> 
> Cheers,
> Dieter
>>  
>> Br
>> 
>> Diego
>> 
>> 
>>   

Delivery-date: Tue, 02 Sep 2008 18:35:27 +0000
Content-class: urn:content-classes:message
Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)
Date: Tue, 2 Sep 2008 11:24:26 -0700
From: "Drake, John E" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>, "Yakov Rekhter" <[email-masked]>, "Lou Berger" <[email-masked]>
Cc: "Yakov Rekhter" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>, <[email-masked]>

Igor,

Several years ago when OSPF was first proposed as an autodiscovery
mechanism for L1VPNs, you were told that it was a bad idea due to its
scaling properties and impact on the IGP.

You are now tacitly agreeing with those who told you it was a bad idea.

For your suggested approach to work with sufficient redundancy, the
topology of the overlay needs to be configured such that every selected
P router is connected to at least two other selected P routers and every
PE router needs to be connected to at least two selected P routers.

When you are done with this configuration, you are left with a situation
in which *every* PE and selected P router will have *all* L1VPN routes.

Thanks,

John=20

>-----Original Message-----
>From: Igor Bryskin [mailto:[email-masked]]=20
>Sent: Friday, August 29, 2008 12:10 PM
>To: Drake, John E; Yakov Rekhter; Lou Berger
>Cc: Yakov Rekhter; Adrian Farrel; [email-masked];=20
>[email-masked]
>Subject: Re: [Softwires] BGP TE attr last call by softwires WG=20
>(2nd question)
>
>Are you calling me silly? Are you coming to Minneapolis? :=3D)
>
>Seriously, what is wrong in your opinion with this approach?=20
>Many people are talking about multi-instance IGPs. What they=20
>have in mind is improving the IGP scalability:
>a) by removing non-IP advertisements from the instance of IGP=20
>that manages IP routing/forwarding tables into separate IGP=20
>instance(s);
>b) by distributing non-IP information only to and via=20
>inerested parties leaving the bulk of Ps out of the process.
>
>In my opinion this is exactly what is needed for the=20
>OSPF-based L1VPN application.
>
>Igor
>
>
>
>
>
>
>----- Original Message ----
>From: "Drake, John E" <[email-masked]>
>To: Igor Bryskin <[email-masked]>; Yakov Rekhter=20
><[email-masked]>; Lou Berger <[email-masked]>
>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel=20
><[email-masked]>; [email-masked]; [email-masked]
>Sent: Friday, August 29, 2008 2:31:36 PM
>Subject: RE: [Softwires] BGP TE attr last call by softwires WG=20
>(2nd question)
>
>So you are proposing an OSPF route reflector?  At what point=20
>does the silliness stop?=20
>
>>-----Original Message-----
>>From: Igor Bryskin [mailto:[email-masked]]
>>Sent: Friday, August 29, 2008 11:29 AM
>>To: Drake, John E; Yakov Rekhter; Lou Berger
>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked];=20
>>[email-masked]
>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd=20
>>question)
>>
>>Hi John,
>>
>>No, not really. When you add a PE you configure local=20
>interfaces, local=20
>>VPN port mappings, stuff like that. While doing this you will also=20
>>configure an IPinIP tunnel to one of your spoke Ps and enable L1VPN=20
>>OSPF instance on the tunnel.
>>Once you did that the local VPN information will be flooded=20
>accross the=20
>>overlay, likewise, the new PE will get all the necessary information=20
>>from other PEs.
>>
>>Cheers,
>>Igor
>>
>>
>>----- Original Message ----
>>From: "Drake, John E" <[email-masked]>
>>To: Igor Bryskin <[email-masked]>; Yakov Rekhter=20
>><[email-masked]>; Lou Berger <[email-masked]>
>>Cc: Yakov Rekhter <[email-masked]>; Adrian Farrel=20
>><[email-masked]>; [email-masked]; [email-masked]
>>Sent: Friday, August 29, 2008 11:20:16 AM
>>Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd=20
>>question)
>>
>>Igor,
>>
>>Doesn't this defeat auto-discovery?  I.e., how is a new PE added to a=20
>>given L1VPN?
>>
>>Thanks,
>>
>>John
>>
>>>-----Original Message-----
>>>From: Igor Bryskin [mailto:[email-masked]]
>>>Sent: Friday, August 29, 2008 5:51 AM
>>>To: Yakov Rekhter; Lou Berger
>>>Cc: Yakov Rekhter; Adrian Farrel; [email-masked];=20
>>>[email-masked]
>>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
>>>question)
>>>
>>>Yakov,
>>>
>>>You said:
>>>
>>>
>>>... And while on the subject of scaling, please keep in mind=20
>that BGP=20
>>>only stores L1VPN routes on PEs that have sites of that VPN=20
>connected=20
>>>to them, and on an RR if used, but *not* on any of the P routers. In=20
>>>contrast, rfc5252 (OSPF for L1VPN
>>>autodiscovery) results in storing *all VPN TE information for all the
>>>VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based=20
>>>approach scales better than OSPF-based approach.
>>>
>>>Yakov.
>>>
>>>This is not true in case of multi-instance OSPF: one can build an=20
>>>overlay interconnecting PEs via one or small number of Ps
>>using IPinIP
>>>tunnels and run in this overlay an instance of OSPF specifically=20
>>>designated for distribution of L1VPN information. In this
>>case the OSPF
>>>solution won't scale any worse than the BGP approach. Note.=20
>>that rfc252
>>>never said that the instance of OSPF used for flooding of the L1VPN=20
>>>information must be the same instance that is used for the
>>distribution
>>>of IP-related LSAs.
>>>
>>>Regards,
>>>Igor
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>

Delivery-date: Tue, 02 Sep 2008 17:28:46 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Greg Bernstein" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Comments on ITU's Work Plan for Optical Transport Networks
Date: Tue, 2 Sep 2008 18:23:21 +0100

OK.

Thanks, I will point at the I-Ds, summarise how we are splitting RWA for 
immediate attention and impairments for future work, note that we do not 
intend to define impairments (but will defer to the ITU-T on this), and 
comment that we believe that the modeling of asymmetric switches such as 
ROADMs may be an area that the ITU-T would like to work on.

Cheers,
Adrian
----- Original Message ----- 
From: "Greg Bernstein" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 02, 2008 4:06 PM
Subject: Re: Comments on ITU's Work Plan for Optical Transport Networks

> Hi Adrian and WGs, looking at the ITU-T SG 15's Optical work plan. They 
> put an emphasis on Metro Optical Networks and point out that these can be 
> different from long haul networks in that that they may not need to use 
> regenerators and that these may be significantly more "dynamic" with 
> respect to provisioning than long haul DWDM networks. We should point them 
> at CCAMP's  WSON work which includes both the Framework document and the 
> RWA info model document.  The modeling of asymmetric switches such as 
> ROADMs seems to have been overlooked at the ITU-T.
>
> Regards
>
> Greg
>
> Adrian Farrel wrote:
>> Hi,
>>
>> We received a liaison back in February 
>> (https://datatracker.ietf.org/liaison/425/) asking for our comments on 
>> ITU-T Study Group 15's "Optical Transport Networks & Technologies 
>> Standardization Work Plan" 
>> (http://www.itu.int/ITU-T/studygroups/com15/otn/index.html)
>>
>> Please let me know by Friday September 5th if you have any comments you 
>> would like us to make. If I don't receive anything, I will send a 
>> response to thank them for keeping us informed and asking them to share 
>> any future work plans with us.
>>
>> Thanks,
>> Adrian
>>
>>
>
> -- 
> ===================================================
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>
> 

Delivery-date: Tue, 02 Sep 2008 15:11:52 +0000
Date: Tue, 02 Sep 2008 08:06:47 -0700
From: Greg Bernstein <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Comments on ITU's Work Plan for Optical Transport Networks

Hi Adrian and WGs, looking at the ITU-T SG 15's Optical work plan. They 
put an emphasis on Metro Optical Networks and point out that these can 
be different from long haul networks in that that they may not need to 
use regenerators and that these may be significantly more "dynamic" with 
respect to provisioning than long haul DWDM networks. 
We should point them at CCAMP's  WSON work which includes both the 
Framework document and the RWA info model document.  The modeling of 
asymmetric switches such as ROADMs seems to have been overlooked at the 
ITU-T.

Regards

Greg

Adrian Farrel wrote:
> Hi,
>
> We received a liaison back in February 
> (https://datatracker.ietf.org/liaison/425/) asking for our comments on 
> ITU-T Study Group 15's "Optical Transport Networks & Technologies 
> Standardization Work Plan" 
> (http://www.itu.int/ITU-T/studygroups/com15/otn/index.html)
>
> Please let me know by Friday September 5th if you have any comments 
> you would like us to make. If I don't receive anything, I will send a 
> response to thank them for keeping us informed and asking them to 
> share any future work plans with us.
>
> Thanks,
> Adrian
>
>

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

Delivery-date: Tue, 02 Sep 2008 15:11:46 +0000
Date: Tue, 02 Sep 2008 08:06:59 -0700
From: Greg Bernstein <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Comments on ITU's Work Plan for Optical Transport Networks

Hi Adrian and WGs, looking at the ITU-T SG 15's Optical work plan. They 
put an emphasis on Metro Optical Networks and point out that these can 
be different from long haul networks in that that they may not need to 
use regenerators and that these may be significantly more "dynamic" with 
respect to provisioning than long haul DWDM networks. 
We should point them at CCAMP's  WSON work which includes both the 
Framework document and the RWA info model document.  The modeling of 
asymmetric switches such as ROADMs seems to have been overlooked at the 
ITU-T.

Regards

Greg

Adrian Farrel wrote:
> Hi,
>
> We received a liaison back in February 
> (https://datatracker.ietf.org/liaison/425/) asking for our comments on 
> ITU-T Study Group 15's "Optical Transport Networks & Technologies 
> Standardization Work Plan" 
> (http://www.itu.int/ITU-T/studygroups/com15/otn/index.html)
>
> Please let me know by Friday September 5th if you have any comments 
> you would like us to make. If I don't receive anything, I will send a 
> response to thank them for keeping us informed and asking them to 
> share any future work plans with us.
>
> Thanks,
> Adrian
>
>

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

Delivery-date: Tue, 02 Sep 2008 14:45:58 +0000
Date: Tue, 02 Sep 2008 07:40:55 -0700
From: Greg Bernstein <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: [email-masked], "Brungard, Deborah A, ALABS" <[email-masked]>
Subject: Re: Draft response to ITU-T on VCAT

Adrian and Deborah, this looks good.

Thanks

Greg B.

Adrian Farrel wrote:
> Hi CCAMP,
>
> We have a liaison to respond to from the ITU-T on VCAT 
> (https://datatracker.ietf.org/liaison/429/).
>
> Please a draft response below.
> Comments to me by Friday September 5.
>
> Thanks,
> Adrian
>
> =====
>
> The IETF CCAMP working group thanks you for your liaison on GMPLS 
> control of VCAT/LCAS dated February 1st 2008, and received February 29th.
>
> Please find our responses in line.
>
>> Here are our comments to the responses provided in your liaison:
>>
>> a) Regarding your response to Question 1 on protocol
>>    extensibility to encompass technologies other than
>>    SONET/SDH, we notice that the recent I-D
>>    (draft-ietf-ccamp-gmpls-vcat-lcas-04.txt) limits the
>>    number of VCGs per call to one. We support this
>>    position and consider this to be a VCAT call.
>
> Thank you. Your support is noted.
>
>> b) Regarding your response to Question 4 on multiple calls
>>    support, VCAT is viewed as a layer of its own and has its
>>    own call controller.
>>    As per the interlayer architecture in G.8080 section 6.6,
>>    the VCAT call would be associated with a server layer call
>>    or calls, each of which would have/own one or more server
>>    layer connections.  It is these connections that are part of the
>>    VCG. In retrospect, a single call is sufficient for diverse
>>    routing as it can hold details of both connections so that they
>>    don't use the same resources.
>>    An example where multiple server calls associated with one
>>    VCAT call would be useful is when all VCAT connections
>>    are to be protected.
>>    Here, rather than one call maintain the knowledge of all
>>    working/protection pairs, it is simpler to have multiple calls
>>    each of which only maintains one working/protection pair.
>>    This is even more convenient when restoration behavior is
>>    applied when the protection connection fails.
>
> We note that in a functional architecture it makes good sense to 
> separate the VCAT layer from the server/protection layer. We also 
> observe that the protocol solution does not need to be tied rigidly to 
> the functional architecture where optimizations may be made from 
> collapsing layers into a single set of protocol exchanges.
>
>> c) Regarding your response to Question 6 on IP address format in
>>    GMPLS, we suggest the I-D clarifies that there are different name
>>    (or identifier) spaces even though they may all use the same IP
>>    address format, e.g.
>>    - Control component
>>      The identifiers used to identify the entities that perform the 
>> control
>>      plane functions, such as route computation, signaling, control 
>> plane
>>      message delivering, etc.
>>    - Transport resource
>>      The identifiers used to identify transport resource when they are
>>      referred to in the control plane messages. Note that these 
>> identifiers
>>      may not be the same as those referred to in the management plane
>>      messages.
>>    - SCN
>>      The addresses used to deliver control plane messages
>>
>>    Examples of a similar address format in use in two different name
>>    spaces can be seen in the OSPF routing protocol, where router ID
>>    (control and transport link scope) and IP address (used by the
>>    forwarder) do not have to be the same.
>
> While we understand that these distinctions are not clear from reading 
> this particular Internet-Draft, we believe that the distinction is 
> clear from the weight of GMPLS RFCs. However, we thank you for 
> pointing out that further clarity could be achieved, and will look at 
> ways to add text to this document.
>
> The CCAMP working group is currently entering the final phase of work 
> on this topic. The current version of the draft can be seen at 
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-05.txt 
> and we would welcome any final input from ITU-T SG15 before we 
> complete the publication process. With that in mind, we invite you to 
> review this document and send us any comments before our November 
> meeting. The response date to this liaison is set accordingly.
>
>
>
>
>
>

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

Delivery-date: Tue, 02 Sep 2008 11:27:56 +0000
Content-class: urn:content-classes:message
Subject: FW: draft-rhodes-rsvp-recovery-signaling-00
Date: Tue, 2 Sep 2008 12:23:24 +0100
From: "David McWalter" <[email-masked]>
To: <[email-masked]>
Cc: "Andrew Rhodes" <[email-masked]>, "Nic Neate" <[email-masked]>

Dear all,

This mail contains an udpate on our work with RSVP recovery signaling.

We are considering changes to RSVP signaling that
-  allow segment recovery to use merge points other than egress (rhodes
draft section 3.1)
-  allow inter-domain e2e and SR (section 3.2)

Initially, we will not propose solutions that
-  allow protecting LSPs themselves to be protected (section 3.3)
-  prevent loss of traffic on overlapping repairs (section 3.4)

We shall aim to be backward-compatible with 4872, as we know that
deployments exist.  We shall not aim to be back-compatible with 4873, as
there seem to be fundamental problems, described in sections 3.1 & 4.1
of the rhodes problem draft, below.  We shall try to keep changes
minimal.

We'd be glad to hear opinions, and we would welcome collaboration.

Andrew Rhodes, Nic Neate, David McWalter.
=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David McWalter
Sent: 06 August 2008 10:05
To: [email-masked]
Cc: Andrew Rhodes; Nic Neate
Subject: draft-rhodes-rsvp-recovery-signaling-00

Dear all,

We would welcome comments on this draft.

Andrew Rhodes, Nic Neate, David McWalter.

http://www.ietf.org/internet-drafts/draft-rhodes-rsvp-recovery-signaling
-00.txt

Title:
Problems observed with RSVP recovery signaling

Abstract:
Implementation experience with RSVP-TE recovery signaling has uncovered
some problems.  Associations between LSPs in different sessions are
forbidden.  Protecting LSPs cannot themselves be protected.  Overlapping
repairs cause loss of traffic.  This draft provides details of these
problems for the community to consider.