acee
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
and this is the <draft-ietf-ccamp-automesh-01.txt> that also assumes
flooding
advertised using a.o. type 11 RI LSA
now:
if you mean that TE should be confined to "intra-domain" meaning area then
how they differ since both are supporting AS wide flooding
if you are concerned by passing "external" information in the VPN case, i
buy
your argument iff this information can be summarized but both TE mesh and
VPN
do not benefit from this property; hence, being opaque information
describing
"internal" information or "external" information doesn't change much to
the
scalability issue; in the TE mesh/tunnel case you would be describing in
the
the mesh-groups you can associate to a set of LSPs terminating on a node
(and
the number of LSP per i/f can be quite high since bound by the Min LSP
bandw.
which is 2Mbps) whereas in the VPN case you would be describing the
external
interfaces id allowing connectivity across the single AS network (the
number
of those is also limited by the capacity associated to a TDM port an E1 in
lowest granularity case)
last point, you seem to rely on the fact that only a small set of groups
will
be instantiated - how do you guarantee this ? - meaning where is the
guarantee
that this condition is met and OSPF has the capability to prevent from any
potential problem that may arise ?
thanks,
- dimitri.
Acee Lindem <[EMAIL PROTECTED]>
12/05/2006 02:40
To: Dimitri PAPADIMITRIOU/BE/[EMAIL PROTECTED]
cc: [EMAIL PROTECTED], Rohit Dube <[EMAIL PROTECTED]>
Subject: Re: [L1vpn] Issues and concerns about Basic Mode
OSPF Discovery
[EMAIL PROTECTED] wrote:
>acee - one specific question from my side then
>
>it seems you do not want to consider auto-mesh of tunnels, why is this
>specific to IPSEC
>
>because there is a draft called <draft-ietf-ccamp-automesh-01.txt> that
>does the same
>kind of discovery process but for MPLS tunnels ?
>
>ps: that draft has also a group number ID and end-name ... where is the
>difference ?
>
>
Dimitri,
I do think TE is a far different application than VPN. For one thing, I
view theTE 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.
As for the mesh groups, I've been assured that a given router will be
part of one or a "small" number of mesh groups :^).
Thanks,
Acee
>
>
>
>
>
>Acee Lindem <[EMAIL PROTECTED]>
>11/05/2006 22:40
>
> To:
> cc: [EMAIL PROTECTED], Rohit Dube <[EMAIL PROTECTED]>
> Subject: Re: [L1vpn] Issues and concerns about Basic Mode
>OSPF Discovery
>
>
>See one clarification below:
>Acee Lindem wrote:
>
>
>
>>Hi Lou,
>>
>>Lou Berger wrote:
>>
>>
>>
>>>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. Also, most (actually, I
>>>think it is all) of these L1 networks do not run BGP and have no
>>>intention of 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.
>>>
>>>so, for the time being (say 3-5 years) the choices are:
>>>(a) no solution
>>>(b) a proprietary solution
>>>(c) a standardized OSPF solution
>>>
>>>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.
>>>
>>>
>>I guess maybe I don't fully understand the L1VPN requirements.
>>Are you saying an SP offerring L2 and L3 VPN services would not want
>>to offer
>>L1 services as well? It seems that you're saying that the environment
>>is similiar to a
>>control plane for a SONET network - correct? I also thought these type
>>of networks
>>were heavily dependent on the provisioning system anyway.
>>
>>
>>
>>>What would you suggest as a way forward?
>>>
>>>
>>I think the experimental realm is where this belongs if it is done in
>>OSPF at all.
>>
>>
>>
>>>>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.
>>>
>>>
>>I know Igor made this point as well so I'll both of you here. TE was
>>the first opaque LSA application. The tunnels provided are internal
>>to the routing domain (yeah I know inter-AS TE has been proposed).
>>Potentially, every router in the area will need to advertise and
>>
>>
>maintain
>
>
>>a TE database. This is not the case with VPNS where only PEs that
>>are endpoints for a common VPN need to share the information.
>>
>>We've rejected other attempts to put dynamic discovery into the IGPs
>>(e.g.,
>>IPSec tunnels). I don't see why we should reverse this position now.
>>
>>
>
>For those of you who don't remember, there was a proposal similar to
>this one
>to use OSPF opaque LSAs to advertise IPSec tunnel group IDs and endpoint
>addresses and similarly self-configure one or more meshes of IPSec
>tunnels
>between PEs.
>
>Acee
>
>
>
>>
>>
>>>
>>>
>>>>>>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.
>>>>
>>>>
>>>
>>>
>>Thanks - I wasn't aware that other people concerns had been raised
>>through Adrian.
>>
>>Acee
>>
>>
>>
>>>>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.
>>>
>>>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
