[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Please comment draft-kulmala-l3vpn-aggregation-pe-00
Luyuan,
Option B requires that there is a label switched path leading from a
packet's ingress PE to its egress PE as stated in RFC2547bis. There is
no IP layer forwarding at ASBR. In my mind that is then the same mpls
domain, but word "domain" may mean different things to us.
Option B does not require PSN tunnels between the packet's ingress and
ergess PEs but it will establish LSP by VPN label distributed by BGP.
But anyways there is LSP connectivity between routers in different ASes.
As stated earlier I think that what we propose would give better
isolation than option B.
Regards,
Marko
> -----Original Message-----
> From: l3vpn-bounces at ietf.org [mailto:l3vpn-bounces at ietf.org]
> On Behalf Of Fang, Luyuan, ALABS
> Sent: 7. maaliskuuta 2005 22:44
> To: l3vpn at ietf.org
> Subject: RE: Please comment draft-kulmala-l3vpn-aggregation-pe-00
>
> Marko,
>
> > One comment about option B and C. When Autonomous Systems are
> connected
> > by using those options they will share common MPLS domain. Is that
> good
> > if applied as an Inter Provider solution ?
>
> Option B does not share common MPLS domain. Many providers
> implemented Option B as Inter-provider solution already.
>
> Option C requires providing PE reachability to the connecting
> ASes/providers. It is an excellent solution for intra company
> connections. For Inter-provider, there are more security
> concerns, I don't know if anyone is using it for
> Inter-provider connections.
>
> Luyuan
>
>
> -----Original Message-----
> From: l3vpn-bounces at ietf.org
> [mailto:l3vpn-bounces at ietf.org]On Behalf Of l3vpn-request at ietf.org
> Sent: Friday, March 04, 2005 12:07 PM
> To: l3vpn at ietf.org
> Subject: L3vpn Digest, Vol 11, Issue 4
>
>
> Send L3vpn mailing list submissions to
> l3vpn at ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www1.ietf.org/mailman/listinfo/l3vpn
> or, via email, send a message with subject or body 'help' to
> l3vpn-request at ietf.org
>
> You can reach the person managing the list at
> l3vpn-owner at ietf.org
>
> When replying, please edit your Subject line so it is more
> specific than "Re: Contents of L3vpn digest..."
>
>
> Today's Topics:
>
> 1. RE: Please comment draft-kulmala-l3vpn-aggregation-pe-00
> (Kulmala, Marko)
> 2. slides (Ronald Bonica)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 4 Mar 2005 08:52:47 +0200
> From: "Kulmala, Marko" <marko.kulmala at tellabs.com>
> Subject: RE: Please comment draft-kulmala-l3vpn-aggregation-pe-00
> To: "Pedro Roque Marques" <roque at juniper.net>
> Cc: vph at iki.fi, l3vpn at ietf.org
> Message-ID:
>
> <4EE011314003124CA4389D37DC21940F01413C10 at FIESEX1.tellabs-east
.tellabsin
> c.net>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Pedro,
>
> It may be possible to get many features by building them on
> top of option B. But I do not think that it is right way to
> go. I agree with Robert when he said that it will be
> operationally difficult to do modify action in some mid point
> on a per VPN prefix granularity. Also I agree with you that
> those things break current option B.
>
> That is why we like to standardize this new method. It is
> fundamentally different compared to option B, even though at
> the first glance it seems pretty much alike. In my opinion
> the proposed method is straightforward and easy from
> operational point of view: We have VFRs at ASBR, just like in
> option A. But we make it possible to have mpls network between ASBRs.
>
>
> One comment about option B and C. When Autonomous Systems are
> connected by using those options they will share common MPLS
> domain. Is that good if applied as an Inter Provider solution
> ? The main conceptual point in our proposal is that the MPLS
> domains are isolated.
>
> Marko
>
> > -----Original Message-----
> > From: Pedro Roque Marques [mailto:roque at juniper.net]
> > Sent: 2. maaliskuuta 2005 22:26
> > To: Kulmala, Marko
> > Cc: vph at iki.fi; l3vpn at ietf.org
> > Subject: RE: Please comment draft-kulmala-l3vpn-aggregation-pe-00
> >
> > Marko Kulmala writes:
> >
> > > This is one example of the functionality that is achievable
> > with this
> > > concept. The concept is pretty straightforward: We propose
> > that we go
> > > to IP layer at the ASBR and still utilize mpls between
> ASBRs. There
> > > are other things (not yet mentioned) that are
> > > achievable: gathering traffic statistic per VPN at ASBR, IP
> > level ACLs
> > > per VPN at ASBR.
> >
> > Marko,
> > I think we need to disentangle several aspects being discussed.
> >
> > There are several topics in this discussion, some of them are
> > orthogonal.
> >
> > Let me try to make a list... please correct me if there is
> something
> > we wish to add.
> >
> > a) IP forwarding lookup on an ASBR or route reflector.
> > b) RT re-write.
> > c) RD re-write.
> > d) "spliting" a prefix, so that it gets advertised w/ 2
> different RDs
> > and RT sets.
> > e) advertising to ebgp post vrf path selection (?)
> >
> > a) gives you most of the features you quote above:
> > possibility to suppress more specific routes to downstream
> peers; IP
> > level (re)classification and accounting, etc.
> >
> > As i mentioned previously, it can be implemented as a
> implementation
> > extension on top of option B (or route reflection). In a
> transparent
> > way. This is also the bit that imposes higher costs in terms of
> > management.
> >
> > I think we agree that this can be useful. I just believe it
> need not
> > be standardized.
> >
> > b) & c) can be achieved in several different ways...
> > specially RD rewrite can be tricky regarding diagnostics.
> >
> > d) can be done either at the originator (another extension
> is current
> > implementations) or in the middle of the network as you propose.
> >
> > But the stuff that really makes me uneasy is e), specially when
> > combined w/ an RD rewrite. i don't think this is a
> necessary part of a
> > solution, in my mind it breaks the current option B model
> and it can
> > be tricky. For instance, one has to be really careful to
> assume that a
> > PE-received route doesn't end up getting reflected back to the ibgp
> > mesh after its RD is modified.
> >
> > imho a) though d) can be implemented as implementation
> extensions on
> > top of an option B model.
> >
> > Pedro.
> >
> >
> ============================================================
> The information contained in this message may be privileged
> and confidential and protected from disclosure. If the reader
> of this message is not the intended recipient, or an employee
> or agent responsible for delivering this message to the
> intended recipient, you are hereby notified that any
> reproduction, dissemination or distribution of this
> communication is strictly prohibited. If you have received
> this communication in error, please notify us immediately by
> replying to the message and deleting it from your computer.
> Thank you. Tellabs
> ============================================================
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 04 Mar 2005 11:00:21 -0500
> From: Ronald Bonica <rbonica at juniper.net>
> Subject: slides
> To: l3vpn at ietf.org
> Message-ID: <42288615.2040502 at juniper.net>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Folks,
>
> If you are presenting to our meeting on Monday, please send
> your slides to me in advance so that we won't have to move
> the projector from PC to PC at the beginning of each presentation.
>
> Ron
>
>
>
> ------------------------------
>
> _______________________________________________
> L3vpn mailing list
> L3vpn at ietf.org
> https://www1.ietf.org/mailman/listinfo/l3vpn
>
>
> End of L3vpn Digest, Vol 11, Issue 4
> ************************************
>
>
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================