[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LC comment on "considerations" inter-AS section

Hi Eric, folks,

15/06/2009 16:36, Eric Rosen:

In  the  discussion  of inter-AS,  I  think  the  draft should  discuss  the
following issues:

- In  order to  use the  segmented inter-AS  procedures, each  ASBR  must be
  pre-configured with the  MVPNs whose trees pass through  it.  (See section
  8.2.1.1 of draft-ietf-l3vpn-2547bis-mcast.)
If this is true that it has to be pre-configured and that auto-configuration is precluded for some reason, we can mention this point in the comparison.
(I don't think that would cancel the advantages of the segmented approach, though) 


- One of the most important scaling properties, that of making the number of
  P-tunnels be independent  of the number of PEs in other  ASes, may be more
  theoretical than real,  at least in the shorter  term.   A segmented S-PMSI
  carries traffic from only one PE, so the number of S-PMSIs used by an MVPN
  is still limited only by the total number of PEs in the MVPN.

I don't get your point:
- without considering S-PMSIs, there is already a big scaling advantage compared to the non-segmented approach (number of I-PMSI tunnels in an AS independent of the number of PEs in the remote ASes) - your sentence about S-PMSI is strange : since when "the number of S-PMSIs used by an MVPN" would be limited "by the total number of PEs in the MVPN" ? Whatever the choice of segmented vs non-segmented, and even in intra-AS, there is no such limitation, the only limit is virtually the number of C-multicast streams... (???) 
  To get  the desired  scaling improvement, one  must aggregate a  number of
  intra-AS segments of inter-AS tunnels  into a single intra-AS P-tunnel.  I
  don't believe there  is a specification of the method for  doing this in a
  fully  automated fashion.  Also,  this type  of aggregation  requires MPLS
  upstream-assigned labels.

I think that these are two bogus claims:
- aggregation of multiple tunnels into one tunnel does not require upstream assigned labels, except possibly if the tunnels are shared between distinct VPNs, but in that case you need upstream assigned labels even in intra-AS, without even considering segmented/non-segmented or aggregation - it doesn't seem to me that something would preclude automation of the merging, this is a purely local decision matter (you could also say that there is no spec of a method for deciding to put traffic on an S-PMSI; but that wouldn't be relevant, even though strictly speaking true) 

-Thomas