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!
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.
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!
Lou
_______________________________________________
L1vpn mailing list
L1vpn@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/l1vpn