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

From: "Drake, John E" <[email-masked]>
Date: Thu, 11 May 2006 11:48:12 -0700

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-masked]]
> Sent: Wednesday, May 10, 2006 10:44 AM
> To: Acee Lindem
> Cc: [email-masked]
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/l1vpn

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

---

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

John,
         Clearly we disagree.  see below.
Lou

>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.

>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...

>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.

>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

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.

>that have excluded this possibility out of hand.

actually, there were others who stated similar and even more extreme 
positions on this list.

>situation is something that I have seen Adrian employ many times in the

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

---

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

lou & john

>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-masked]>
11/05/2006 21:26
 
        To:     "Drake, John E" <[email-masked]>
        cc:     [email-masked]
        Subject:        RE: [L1vpn] Issues and concerns about Basic Mode 
OSPF Discovery

John,

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.

Lou