lou & john
>>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.
>
>I agree. This is a scalability consideration which must be taken
>into account when deploying the OSPF solution. Likewise, choice of
>using an otherwise unused protocol is a deployment consideration.
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
<draft-ietf-ccamp-automesh-01.txt>
that also assumes flooding advertised within a type 10 or 11 RI LSA (this
document is currently under CCAMP responsibility)
so i agree there is a scaling issue but i don't see what makes the VPN
proposal different from the automesh from that specific perspective (in
particular if the TE Link TLV proposed in the OSPF L1VPN document is not
considered);
imho it is appropriate to delve into scalability details but it is also
more than appropriate to use such argument in a consistent way (sincere
apologizes if i miss something in the process)
thanks,
- dimitri;
Lou Berger <[EMAIL PROTECTED]>
11/05/2006 21:26
To: "Drake, John E" <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED]
Subject: RE: [L1vpn] Issues and concerns about Basic Mode
OSPF Discovery
John,
Clearly we disagree. see below.
Lou
At 02:48 PM 5/11/2006, Drake, John E wrote:
>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.
My experience is that "substantial" in transport terms is minuscule
in Internet terms. Every case that I know of, and anyone I've had
contact with, share my view of scale. If someone can talk from
direct experience (either their's or their customer's) it would be
helpful.
> > 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.
I agree that hearing from the folks that operate *transport* networks
would be of huge value. Unfortunately, they typically don't show at
IETF. There actually was someone from such a group at the last
meeting who came up to me after the meeting and stated the (1) they
would only do OSPF and (2) that they would need a multi-area support
in the OSPF solution. I asked him if he'd post his opinion on the
list and he said he would, unfortunately we haven't seen this mail
and I didn't take down his name. Sigh...
> > 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.
Are you suggesting that automatic discovery of information doesn't
work in IGPs? I humbly submit that you are mistaken.
>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.
I agree. This is a scalability consideration which must be taken
into account when deploying the OSPF solution. Likewise, choice of
using an otherwise unused protocol is a deployment consideration.
>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.
all I'm saying is that there's place for IGPs and EGPs, and we should
support the demands of L1VPN providers. Again, if the market doesn't
support a solution it should be killed.
>
> >
> > 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.
actually, there were others who stated similar and even more extreme
positions on this list.
> >
> > 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.
Coercion, no. Helpfulness maybe. Summarizing is fine and good,
excluding the aforementioned caveat, presenting comments for others
is *not* desirable IMO. Again, you are free to hold a different opinion.
Lou
>
> >
> > 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
_______________________________________________
L1vpn mailing list
L1vpn@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/l1vpn
