Subject: 答复: ??: Huawei draft

From: Bin Li <[email-masked]>
Date: Mon, 11 Nov 2002 11:05:28 +0800

Hey Robert,

Please check my reply in origin message.

----- Original Message ----- 
发件人: "Robert Raszuk" <[email-masked]>
收件人: "Bin Li" <[email-masked]>
发送时间: 2002年11月10日 19:25
主题: Re: ??: Huawei draft

> Hey Bin,
> 
> > I am glad that you agree to HoPE is better than Multi-VRF.
> 
> No - I have not said this. Both static and dynamic options are well
> proven to be usefull - so there should be no jugment made that one is
> better then the other. Customers should decide which one to use.
*************************************************************************************************************************************************************************************************
Maybe I misunderstand your reply. you said some YES when I listed the diffrence between HoPE and Multi-VRF. I think you misunderstood me early when I listed the diffrence between HoPE and inter-as option b.
I aggre to that both of HoPE and Multi-VRF are useful to improve the scability of 2547bis .
*************************************************************************************************************************************************************************************************
> 
> > HoPE will be confused with inter-as solution easily. But they are distinct.
> 
> I dobut it.
> 
> > 1 SPE only send aggregate vpnv4 routes or a default vpnv4 route to UPE. SPE should not filter vpnv4 routes which UPE advertises. On the other hand, UPE must not filter aggregate routes or default route which SPE advertises.
> 
> All of this is fully doable with ASBR-ASBR inter-as option b.
******************************************************************************************************************************************************************
It can do able with inter-as option b AFTER the HoPE draft was commited : ).
******************************************************************************************************************************************************************
> 
> > 2 Because vpnv4 routes are aggregated in SPE, SPE must terminate the LSP which is from UPE. It pop the vpn label and look forward vrf routing table, then push a new vpn label. In inter-as case, ASBR just swap the vpn label.
> 
> No. That is not correct. There can be Inter-AS case where ASBR set's
> next hop self for vpnv4 routes (your case) as well as the scenario where
> ASBR's do not set next hop self (LSP is not terminated at them).
******************************************************************************************************************************************************************
No. The inner LSP is established between two PEs in diffrent ASes in inter-as option b. The inner label is swithed at ASBRes. Only one ASBR swithes label if It does NOT set  next hop self. Both two ASBRs swith label if It set next hop self. The inner LSP does NOT terminate at both of them.
******************************************************************************************************************************************************************
> 
> > 3 UPE should advertise its import route target list to SPE.
> >  SPE will form a HoPE-wide import route target list to filter vpnv4 routes from other PEs. In inter-as case, ASBR may send a ORF to a peer ASBR, but the ORF is used to filter the routes which the peer ASBR send to itself.
> 
> Yes I see what you are trying to achive here. Limit the number of vpnv4
> routes not just advertised by SPE to UPEs (as that would be do with ext
> community ORF on the UPE-SPE), but you also want to limit the number of
> vpnv4 routes which SPE keeps (to match given HoPE requirements). 
> 
> That alone IMHO does not justify to have a draft for it :) And if even
> that should be idr WG draft not ppvpn as what you are really after is to
> install ORF filter from any UPE as inbound on the SPE. That is also
> implementation detail (all is internal to ASBR/PE/SPE internal operation
> - how it handles incomming ext community ORF messages). But the idea is
> no bad to implement it ... :).

******************************************************************************************************************************************************************
If nobody knows HoPE mechanism. It will not be implemented wildly.
******************************************************************************************************************************************************************
> 
> > 4 I must describe twice, SPE and UPE can be in same AS. In inter-as case, two ASBRs are in different AS.
> 
> That really does not matter. You simple have instead of EBGP vpnv4
> sessions to UPEs IBGP vpnv4 sessions (with SPE most likely reflecting
> the vpnv4 routes _at least_ within the HoPE.
> 
> > The above mechanisms are not described in draft 2547bis. And the PE just according 2547bis can't work as a SPE now. So I commit this proposal.
> 
> Good luck :).
> 
> R.
> 
> 
> > ----- Original Message -----
> > å'ä»¶äºº: "Robert Raszuk" <[email-masked]>
> > æ"¶ä»¶äºº: "Bin Li" <[email-masked]>
> > æS"é?: <[email-masked]>
> > å'é?æ-¶é-′: 2002å¹′11æo^9æ-￥ 17:00
> > ä¸»é￠~: Re: ??: Huawei draft
> > 
> > > Bin,
> > >
> > > >   It seems like inter-as mechanism.
> > >
> > > I am glad you agree.
> > >
> > > > But they solve different thing.
> > > > SPE and UPE are in same AS most time.
> > >
> > > That is fine. That is why I said trival Inter-As case.
> > >
> > > > And according inter-as mechanism,
> > > > SPE and UPE should advertise all
> > > > VPN-IPv4 prefixes to each other.
> > >
> > > No - absolutely not. If you found somewhere any statemnt like this it is
> > > a doc bug :). It would be highly not scalable to have such a requiremnt
> > > in place. Filtering on advertisemnt of vpnv4 routes or at inbound
> > > processing of those incomming is a key to scalability of any inter-as
> > > case.
> > >
> > > Cheers,
> > > R.
> > >
> > >