Lou, Comments inline. My take is that using an IGP for auto-discovery is, shall we say, ill-advised.
Thanks, John > -----Original Message----- > From: Lou Berger [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 10, 2006 10:44 AM > To: Acee Lindem > Cc: [EMAIL PROTECTED] > Subject: Re: [L1vpn] Issues and concerns about Basic Mode OSPF Discovery > > Hi Acee, > Thanks for the response, see below. > > At 12:22 PM 5/10/2006, Acee Lindem wrote: > > [...] > > > >>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. > > 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. That sounds suspiciously like an assertion. I have heard anecdotal accounts of very substantial SONET networks. > Also, most (actually, I > think it is all) of these L1 networks do not run BGP > and have no intention of running BGP. You shouldn't be speaking for these operators. The few operators that I recall expressing an opinion didn't seem to mind 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. I think the real point is a technology issue rather than a deployment issue. BGP is a proven technology for auto-discovery and an IGP is not. Furthermore, as Acee points out it is not a perfect fit, because each node is required to keep *all* information in its copy of the link state database even if that node has no use for some (or any, in the case of a P router) of it. Also, because IGPs are chattier than BGP, there will be the added overhead of refreshing *all* of this information. Saying that a solution that doesn't have good scaling properties, relative to the known BGP solution, is acceptable because the networks it will be deployed in will be small when it is first deployed seems to be implicitly indicating that we will have to go to another solution when we do run into scaling issues and we will have to figure out how to migrate to that solution. > > so, for the time being (say 3-5 years) the choices are: > (a) no solution > (b) a proprietary solution > (c) a standardized OSPF solution (d) a standardized BGP solution. You and Igor seem to be the only ones that have excluded this possibility out of hand. > > 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? > > >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. > > 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. > >> > >> > >>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 > > 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. Oh, now. I think the points that Adrian made in his e-mail were all points that I heard raised in Dallas. Knowing the membership of the V1VPN group, I find it hard to believe that anyone coerced Adrian into making a point on their behalf. An e-mail summary of a specific situation is something that I have seen Adrian employ many times in the past. > > Much thanks, > 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
