Subject: [L1vpn] Issues and concerns about Basic Mode OSPF Discovery

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 1 May 2006 18:40:53 +0100

Hi,

In a previous message, I said...

> There is not clear consensus yet about
> draft-bryskin-l1vpn-ospf-auto-discovery-01.txt.
>
> Although the chairs think that this draft is very readable
> and clear, it has changed quite a lot since the previous
> revision, and it was clear that some people had not yet had a
> chance to read and digest.
>
> Additionally, the chairs polled the OSPF WG
> chairs who have some concerns that they would like to discuss
>
> We note that the meeting in Dallas was clear that theri should not
> be a beauty contest between these I-Ds, but that both should be
> allowed to proceed leaving the choice to develop as the I-Ds
> proceed based on implementaiton and deployment.
>
> What we propose for this draft is as follows:
> - people need to read the latest version

I hope that some more of you have had a chance to look at this draft by now.

>- the chairs will summarise the issues that have been raised (including
> from the OSPF chairs)

That is the purpose of this email.

> - we can discuss the issues on the list
>
> We will aim to make a more firm decision over the next 6 to 8 weeks
> so that we know where we stand before Montreal

Here are the issues raised, in no particular order, with some commentary 
from me. It would be good to have some discussion of these points.

1. We need to have only one solution

I'm inclined to agree with this. It is not helpful to the industry to have 
two solutions in the same space. However, if there are significantly 
different applicabilities this would be a justification.

My interpretation of the discussion in Dallas was that we would not make 
this decision at this time.

2. The L1VPN solution should be aligned with the L2/L3VPN solutions

We need to be clear to what extent the Basic Mode discovery problem is the 
same as / different from the L3VPN problem.

3. The Basic Mode discovery solution must extend to the Extended Mode

4. There are scaling concerns with using OSPF in this way.

A couple of comments on scaling.
- It is certainly safe to assume that in the near term, the size of optical
  networks will not come close to the current size of OSPF packet
  networks.
- OSPF used in this way will not need to handle external routes, and
  this saving more than outwieghs the cost of Basic Mode discovery
- The "per-port" nature of L1VPN connectivity means that there is
   no multiplexing of VPNs to a CE-PE link (athough a single PE may
   give access to multiple VPNs).

5. This is 'naturally' an iBGP function not an IGP function

If there are more discussion points that I have dropped, please feel free to 
raise them as well.

Thanks,
Adrian 

_______________________________________________
L1vpn mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l1vpn

---

From: Lou Berger <[email-masked]>
Date: Tue, 09 May 2006 15:44:57 -0400

Adrian,
         Much thanks for brining the "OPSF L1VPN issues" to the list 
and out into the open.  I sincerely appreciate it.

My bet is that you'd like a bit of discussion on this.  So here're 
some comments to help move it along.

>In a previous message, I said...

[...]

>Here are the issues raised, in no particular order, with some 
>commentary from me. It would be good to have some discussion of these points.
>
>I'm inclined to agree with this. It is not helpful to the industry 
>to have two solutions in the same space. However, if there are 
>significantly different applicabilities this would be a justification.
>
>My interpretation of the discussion in Dallas was that we would not 
>make this decision at this time.

I agree, there was a definite sentiment to let both approaches 
progress for now and "let the market decide".  IMO Experience has 
shown that a good decision point will come when it's time for 
implementation reports.

>We need to be clear to what extent the Basic Mode discovery problem 
>is the same as / different from the L3VPN problem.

agree with your point.  To the general point my question is why?

>3. The Basic Mode discovery solution must extend to the Extended Mode

Why?  Also, this implies this isn't possible with OSPF, I don't think 
this is clear.  And would like those who have made the point to state 
why it does not.

>   give access to multiple VPNs).

I think you make excellent points and see no need to add to 
it.  Again, if there are those who have further objections, they 
should raise them on this list.

>5. This is 'naturally' an iBGP function not an IGP function

well that's nice.  and my IGP is better than yours - hah!

More seriously, if there's a technical point here can someone help me find it.

>If there are more discussion points that I have dropped, please feel 
>free to raise them as well.

I guess the lack of response speaks volumes.

>Adrian

BTW, I really don't like the "dark smoky-room" approach being taken 
here.  If a WG participant/AD/etc. has an issue, then they should 
raise it themselves and not ask the WG chair to do it for them.  If 
they don't care enough to raise it themselves, then IMO we, the WG, 
shouldn't waste our time on it!

Lou

---

From: Acee Lindem <[email-masked]>
Date: Wed, 10 May 2006 12:22:00 -0400

Lou,

See inline.

Lou Berger wrote:

>> I'm inclined to agree with this. It is not helpful to the industry to 
>> have two solutions in the same space. However, if there are 
> I think you make excellent points and see no need to add to it.  
> Again, if there are those who have further objections, they should 
> raise them on this list.
>

BGP is an EGP - not an IGP :^)

> More seriously, if there's a technical point here can someone help me 

For L2VPN and L3VPN the job of dissemination and discovery has been done
in iBGP since it lends itself very nicely to  limiting the scope of the 
information
to the PE that need. With the proposal of using opaque AS LSAs, every router
in the OSPF routing domain must receive the L1VPN information.

Additionally, heretofore, we've avoided making OSPF a generalized transport
mechanism for flooding information. Before we'd take such a direction, 
you'd need to
convince the OSPF WG that this is a prudent direction. IMHO, this probably
isn't going to happen.

> shouldn't waste our time on it!

Better that Adrian solicted input from the OSPF WG than have you wait 
for this to be
rejected by the OSPF WG at a later IETF. Your L1VPN solution hasn't been
presented to OSPF WG or even posted to the OSPF WG list. Lest you make the
same mistake twice, I suggest you socialize the IDR WG (where this 
application
belongs) early on in the process.

Acee

---

From: Lou Berger <[email-masked]>
Date: Wed, 10 May 2006 13:43:40 -0400

Hi Acee,
         Thanks for the response, see below.

At 12:22 PM 5/10/2006, Acee Lindem wrote:

[...]

>in iBGP since it lends itself very nicely to  limiting the scope of 
>the information

correct.  But keep in mind that the context of operation is a L1 
transport network, who's sole purpose is to support delivery of 
transport services.  The scale of these networks, and the number of 
total routes carried, is radically different than in the general IP 
network case where L2 and L3VPNs operate.  Also, most (actually, I 
think it is all) of these L1 networks do not run BGP and have no 
intention of running BGP.  Furthermore, the sole purpose for running 
BGP would be to support L1VPNs.  BGP isn't something that is already 
present to be leveraged.

so, for the time being (say 3-5 years) the choices are:
(a) no solution
(b) a proprietary solution
(c) a standardized OSPF solution

The plan of the WG, as I understand it, is to work on both a BGP and 
OPSF solution and then (possibly based on an implementation survey) 
decide if both should move forward to PS.

What would you suggest as a way forward?

>mechanism for flooding information. Before we'd take such a 
>direction, you'd need to

huh???  That horse escaped the barn with RFC2370.  To quote "The 
information field may be used directly by OSPF or by other 
applications."  Certainly TE, rfc3630, also falls into the category 
of using OSPF as a generalized transport mechanism.

>>>If there are more discussion points that I have dropped, please 
>>>feel free to raise them as well.
>>
>>
>Better that Adrian solicted input from the OSPF WG than have you 
>wait for this to be
>same mistake twice, I suggest you socialize the IDR WG (where this application

My apologies, this comment was *not* directed at the OSPF WG 
chairs.  I think it *is* appropriate for one WG chair to consult with 
another WG chair and report back to the WG on that conversation.  I 
also think it appropriate for the other WG chair to chime in on the 
follow-up discussion as you have thankfully done.  My comment was 
really directed at the comments by other L1VPN WG member's that where 
represented in Adrian's mail.

Much thanks,
Lou

---

From: "Igor Bryskin" <[email-masked]>
Date: Wed, 10 May 2006 13:54:08 -0400

Acee,

Thanks for joining this discussion. Please, see in-line, I've got some
questions to you.

Igor

----- Original Message ----- 
From: "Acee Lindem" <[email-masked]>
To: "Lou Berger" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 10, 2006 12:22 PM
Subject: Re: [L1vpn] Issues and concerns about Basic Mode OSPF Discovery

> convince the OSPF WG that this is a prudent direction. IMHO, this probably

IB>> Here are my questions:

1. If OSPF WG has avoided making OSPF a generalized transport, why then we
need opaque LSAs (which do nothing but expose OSPF transport to various
applications and hence make the transport generalized :-)) ?

2. Why is it OK to use OSPF for TE purposes but not for L1VPN purposes?

3. Would you agree that there could be networks (specifically,  L1 networks)
and applications that do not use BGP at all and have no plans to use it in
foreseeable future which yet could benefit from L1VPN services? Nobody said
after all that BGP is a mandatory part of any control plane in any network
layer

Thanks,
Igor

---

From: Acee Lindem <[email-masked]>
Date: Thu, 11 May 2006 16:40:46 -0400

See one clarification below:
Acee Lindem wrote:

> Hi Lou,
> I guess maybe I don't fully understand the L1VPN requirements.
> Are you saying an SP offerring L2 and L3 VPN services would not want 
> to offer
> L1 services as well? It seems that you're saying that the environment 
> is similiar to a
> control plane for a SONET network - correct? I also thought these type 
> of networks
> were heavily dependent on the provisioning system anyway.
>
>>
> I think the experimental realm is where this belongs if it is done in
> OSPF at all.
>
>>
> I know Igor made this point as well so I'll both of you here. TE was
> the first opaque LSA application. The tunnels provided are internal
> to the routing domain (yeah I know inter-AS TE has been proposed).
> Potentially, every router in the area will need to advertise and maintain
> a TE database. This is not the case with VPNS where only PEs that
> are endpoints for a common VPN need to share the information.
>
> We've rejected other attempts to put dynamic discovery into the IGPs 
> (e.g.,
> IPSec tunnels). I don't see why we should reverse this position now.

For those of you who don't remember, there was a proposal similar to 
this one
to use OSPF opaque LSAs to advertise IPSec tunnel group IDs and endpoint
addresses and similarly self-configure one or more meshes of  IPSec tunnels
between PEs.

Acee

> Thanks - I wasn't aware that other people concerns had been raised 
> through Adrian.
>
> Acee
>
>>>
>>> Acee
>>
>>
>>
>> My apologies, this comment was *not* directed at the OSPF WG chairs.  
>> I think it *is* appropriate for one WG chair to consult with another 
>> WG chair and report back to the WG on that conversation.  I also 
>> think it appropriate for the other WG chair to chime in on the

---

From: [email-masked]
Date: Thu, 11 May 2006 23:10:17 +0200

acee - one specific question from my side then 

it seems you do not want to consider auto-mesh of tunnels, why is this 
specific to IPSEC

because there is a draft called <draft-ietf-ccamp-automesh-01.txt> that 
does the same
kind of discovery process but for MPLS tunnels ?

ps: that draft has also a group number ID and end-name ... where is the 
difference ?

Acee Lindem <[email-masked]>
11/05/2006 22:40
 
        To: 
        cc:     [email-masked], Rohit Dube <[email-masked]>
        Subject:        Re: [L1vpn] Issues and concerns about Basic Mode 
OSPF Discovery

For those of you who don't remember, there was a proposal similar to 
this one
to use OSPF opaque LSAs to advertise IPSec tunnel group IDs and endpoint
addresses and similarly self-configure one or more meshes of  IPSec 
tunnels
between PEs.

Acee

---

From: "Igor Bryskin" <[email-masked]>
Date: Thu, 11 May 2006 17:16:52 -0400

Acee,

> > are endpoints for a common VPN need to share the information.

IB>> Although it is true that each provider node (P or PE) should advertise
their TE links,  not
all of the nodes actually use the TE information. In the context of L1VPN
application only PEs will perform path
computation and hence only they will use the TE information distributed via
opaque LSAs.  Ps, on the other hand, will have to keep
in their LSDBs and flood the TE info advertised by all other nodes on the
network but not use it. So, in fact, I see
 a striking similarity between TE and L1VPN applications in this respect.

Igor

tunnels

---

From: Lou Berger <[email-masked]>
Date: Thu, 11 May 2006 17:19:00 -0400

Acee,
         See below.

At 04:30 PM 5/11/2006, Acee Lindem wrote:
>>>in iBGP since it lends itself very nicely to  limiting the scope 
>>>of the information
>>intention of running BGP.  Furthermore, the sole purpose for 
>>running BGP would be to support L1VPNs.  BGP isn't something that 
>>is already present to be leveraged.
>>
>>The plan of the WG, as I understand it, is to work on both a BGP 
>>and OPSF solution and then (possibly based on an implementation 
>>survey) decide if both should move forward to PS.
>
>Are you saying an SP offerring L2 and L3 VPN services would not want to offer
>L1 services as well?

not using the same network.

>It seems that you're saying that the environment is similiar to a
>control plane for a SONET network - correct?

yes, SONET or other transport technology, e.g., DWDM - which is the 
networks I know about.

>I also thought these type of networks

we're concerned with those that are using GMPLS. From the charter:
"The L1VPN Working Group's task is to specify mechanisms necessary for
providing layer-1 VPN services (establishment of layer-1 connections
between CE devices) over a GMPLS-enabled transport service-provider
network."

>I think the experimental realm is where this belongs if it is done in

IMO I think we can defer that call until the time we're ready to go 
to IETF last call.  The implementation survey may even say it 
shouldn't go forward as anything more than informational.

>We've rejected other attempts to put dynamic discovery into the IGPs (e.g.,

I think Dimitri already responded to this point.

>>>>BTW, I really don't like the "dark smoky-room" approach being 
>>>>taken here.  If a WG participant/AD/etc. has an issue, then they 
>>>>should raise it themselves and not ask the WG chair to do it for 
>>>>them.  If they don't care enough to raise it themselves, then IMO 
>>>>we, the WG, shouldn't waste our time on it!
>>>
>>>

I could always be wrong, but that's my understanding....

Lou

>>I think it *is* appropriate for one WG chair to consult with 
>>really directed at the comments by other L1VPN WG member's that 
>>where represented in Adrian's mail.
>>
>>Much thanks,
>>Lou
>

---

From: Acee Lindem <[email-masked]>
Date: Thu, 11 May 2006 16:30:56 -0400

Hi Lou,

I guess maybe I don't fully understand the L1VPN requirements.
Are you saying an SP offerring L2 and L3 VPN services would not want to 
offer
L1 services as well? It seems that you're saying that the environment is 
similiar to a
control plane for a SONET network - correct? I also thought these type 
of networks
were heavily dependent on the provisioning system anyway.

> applications."  Certainly TE, rfc3630, also falls into the category of 
> using OSPF as a generalized transport mechanism.

Acee

> WG chair and report back to the WG on that conversation.  I also think 
> it appropriate for the other WG chair to chime in on the follow-up 
> discussion as you have thankfully done.  My comment was really 
> directed at the comments by other L1VPN WG member's that where

---

From: Acee Lindem <[email-masked]>
Date: Thu, 11 May 2006 20:40:01 -0400

>ps: that draft has also a group number ID and end-name ... where is the 
Dimitri,

I do think TE is a far different application than VPN. For one thing, I 
view the
TE tunnels as part of the intra-domain topology. Accepting this premise, 
TE tunnels
themselves are part of the same control plane as the IGP. Additionally, it
is more likely that the volume of TE information is bounded by the size
of the routing domain. Conversely, VPNs represent the services provided 
external
to the routing domain of the IGP and the amount of VPN information is 
not at all
bounded by the routing domain.

As for the mesh groups, I've been assured that a given router will be 
part of one
or a "small" number of mesh groups :^).

Thanks,
Acee

>>Potentially, every router in the area will need to advertise and 
>>    
>>
>maintain
>  
>

---

From: Acee Lindem <[email-masked]>
Date: Thu, 11 May 2006 21:00:46 -0400

Hi Igor,

Igor Bryskin wrote:

>>>>>- the chairs will summarise the issues that have been raised
>>>>>          
>>>>>
>(including
>  
>
>>>>>from the OSPF chairs)
>>>>>          
>>>>>
>>to the PE that need. With the proposal of using opaque AS LSAs, every
>>    
>>
>router
>  
>
>>Additionally, heretofore, we've avoided making OSPF a generalized
>>    
>>
>transport
>  
>
The fact that opaque LSAs are supported doesn't preclude us from being 
judicious
about what we carry in them. Let me make an analogy - the trunk of your 
BMW is
a general purpose storage area - however, you'd be wise not to use it 
for manure.

>2. Why is it OK to use OSPF for TE purposes but not for L1VPN purposes?
I just happen to have an answer to this question :^)

>after all that BGP is a mandatory part of any control plane in any network
I agree that there are optical or other L1 networks that have their own 
control
plane. I just don't see why one would want to offer VPNs on top of these
without an intervening L3 network.

Thanks,
Acee

---

From: Lou Berger <[email-masked]>
Date: Thu, 11 May 2006 21:15:36 -0400

At 09:00 PM 5/11/2006, Acee Lindem wrote:
>I agree that there are optical or other L1 networks that have their 
>own control

Acee,
         I think we still have a "context" issue.  In this contect 
the "VPN" is itself a Layer 1 service, e.g., a SONET interface or a 
lambda.  There are no packet services in these networks, only an IP 
control plane controlling circuits.

Lou

---

From: Richard Rabbat <[email-masked]>
Date: Fri, 12 May 2006 00:11:11 -0400

Acee,
Comments inline:

Acee Lindem wrote:
>> ----- Original Message ----- From: "Acee Lindem" <[email-masked]>
> about what we carry in them. Let me make an analogy - the trunk of 
> your BMW is
By the same token, you don't drive a M1 tank to cross the street (or 
maybe you do) :-)
> I do think TE is a far different application than VPN. For one thing, 
> I view the
> TE tunnels as part of the intra-domain topology. Accepting this 
> premise, TE tunnels
> of the routing domain. Conversely, VPNs represent the services 
> provided external
you're thinking in terms of intra-domain because transport network 
operators had not listed inter-domain as a priority earlier (will 
probably change in future). It should be an indication to you of the 
size of the considered transport network.
> without an intervening L3 network.
I think you're incorrect about the objective of the wg. this mailing 
list is for layer 1 vpn service, a service provided for people who want 
to buy sonet or lambda service. you may want to read the charter
> Acee
thanks,
richard.
>>> _________

---

From: [email-masked]
Date: Fri, 12 May 2006 09:20:36 +0200

acee 

OSPF has been already proposed as a discovery mechanism where not all 
nodes 
are required to keep a copy in the database to make the application 
working
and this is the <draft-ietf-ccamp-automesh-01.txt> that also assumes 
flooding 
advertised using a.o. type 11 RI LSA 

now:

if you mean that TE should be confined to "intra-domain" meaning area then 

how they differ since both are supporting AS wide flooding 

if you are concerned by passing "external" information in the VPN case, i 
buy 
your argument iff this information can be summarized but both TE mesh and 
VPN 
do not benefit from this property; hence, being opaque information 
describing
"internal" information or "external" information doesn't change much to 
the
scalability issue; in the TE mesh/tunnel case you would be describing in 
the 
the mesh-groups you can associate to a set of LSPs terminating on a node 
(and 
the number of LSP per i/f can be quite high since bound by the Min LSP 
bandw. 
which is 2Mbps) whereas in the VPN case you would be describing the 
external 
interfaces id allowing connectivity across the single AS network (the 
number 
of those is also limited by the capacity associated to a TDM port an E1 in 

lowest granularity case) 

last point, you seem to rely on the fact that only a small set of groups 
will
be instantiated - how do you guarantee this ? - meaning where is the 
guarantee
that this condition is met and OSPF has the capability to prevent from any
potential problem that may arise ?

thanks,
- dimitri.

12/05/2006 02:40
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked], Rohit Dube <[email-masked]>
        Subject:        Re: [L1vpn] Issues and concerns about Basic Mode 
OSPF Discovery

Dimitri,

I do think TE is a far different application than VPN. For one thing, I 
view theTE tunnels as part of the intra-domain topology. 

Accepting this premise, TE tunnels

As for the mesh groups, I've been assured that a given router will be 
part of one or a "small" number of mesh groups :^).

Thanks,
Acee

---

From: "Igor Bryskin" <[email-masked]>
Date: Fri, 12 May 2006 09:07:11 -0400

Acee,

Please, see in line.

Igor

> a general purpose storage area - however, you'd be wise not to use it

IB>> As Dimitri and other people pointed out there is plenty of proposed
solutions that use OSPF (opaque LSAs) based discovery. I can add to this
heap the PCE capabilities discovery developped within the PCE WG.
Responding to your analogy I'd say that there is nothing wrong about
transporting manure in the BMW trunk if:
a) you don't have another car available;
b) transporting manure is beneficial/profitable;
c) manure is wisely packed

> bounded by the routing domain.

IB>> I have already answered to this. In the context of the L1VPNs only PEs
are the users of the TE info, because only them who perform path
computation, and the only purpose of TE info distribution is to enable the
path computation. Likewise PEs are the only users of the L1VPN information.
So I don't see any conceptual difference between L1VPN and TE applications
in this respect.

Furthermore, the information passed in the L1VPN opaque LSAs is PE-CE port
information and, therefore, is bound to the number of CE-PE links of the
Provider domain.

> without an intervening L3 network.

IB>> I think you are confused with the "VPN" part  in L1VPN. Acoording to
the ITU-T definition L1VPN is a L1 service and hence is concerned with
lambdas, timeslots, etc. and have noting to do with (IP) packets.

Igor

---

From: Acee Lindem <[email-masked]>
Date: Mon, 15 May 2006 13:24:22 -0400

Lou Berger wrote:

>         I think we still have a "context" issue.  In this contect the 
> "VPN" is itself a Layer 1 service, e.g., a SONET interface or a 

Lou,

Understood  - but are saying that there is no requirement to ever offer 
these L1VPN
services in parallel with over L2/L3 services over a shared provider 
network? If you can
truly limit the applicable to an environment where the control plane 
only has the purpose
of L1VPNs then I wouldn't be that concerned (although I'd ask that the 
IANA opaque
LSA ID allocation clearly state this - this WG chooses to go forward 
with this approach).

Thanks,
Acee

---

From: "Lou Berger" <[email-masked]>
Date: Mon, 15 May 2006 17:34:29 +0000 GMT

Acee,

I believe the limited scope you refer to matches the charter or the WG.

Lou

-----Original Message-----
From: Acee Lindem <[email-masked]>
Date: Mon, 15 May 2006 13:24:22 
To:Lou Berger <[email-masked]>
Cc:Igor Bryskin <[email-masked]>, [email-masked]
Subject: Re: [L1vpn] Issues and concerns about Basic Mode OSPF Discovery

Lou,

Thanks,
Acee