Hi Igor,
Igor Bryskin wrote:
Acee,
Thanks for joining this discussion. Please, see in-line, I've got some
questions to you.
Igor
----- Original Message -----
From: "Acee Lindem" <[EMAIL PROTECTED]>
To: "Lou Berger" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, May 10, 2006 12:22 PM
Subject: Re: [L1vpn] Issues and concerns about Basic Mode OSPF Discovery
Lou,
See inline.
Lou Berger wrote:
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.
At 01:40 PM 5/1/2006, Adrian Farrel wrote:
Hi,
In a previous message, I said...
[...]
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.
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.
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.
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.
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).
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!
BGP is an EGP - not an IGP :^)
More seriously, if there's a technical point here can someone help me
find it.
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.
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 :-)) ?
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 :^)
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.
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
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
Thanks,
Igor
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.
Thanks,
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!
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
Lou
_______________________________________________
L1vpn mailing list
L1vpn@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/l1vpn
_______________________________________________
L1vpn mailing list
L1vpn@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/l1vpn
