draft-otani-ccamp-interas-gmpls-te-00.txt

["Adrian Farrel" <[e-mail]>]

Hi,

A nice short draft. Congratulations!

Also, it is very good to see SPs bringing forward requirement drafts. Thank you.

I understand the point you are making in the draft, but I am not sure it is specific to GMPLS and switching capabilities.

For example, suppose we modify the bandwidth in your MPLS example network to:

  +----+          +----+    |    +----+          +----+ 
  | A1 |----//----| A3 |---------| B1 |----//----| B3 | 
  +----+   10G    +----+   10G   +----+   2.5G   +----+ 
     |               |      |        |               |     
     =2.5G           =10G   |        =2.5G           =2.5G 
     |               |      |        |               |   
  +----+          +----+    |    +----+          +----+ 
  | A2 |----//----| A4 |---------| B2 |----//----| B4 | 
  +----+   2.5G   +----+   10G   +----+   10G    +----+ 
                            | 
         MPLS AS 1          |         MPLS AS 2 

Now, set up a 10G service from A1 to B4.
AS 1 is going to select the ASBR pair A3/B1 as the shortest path out of AS 1.
But B1 will fail the setup.
We must rely on crankback or a wider view (PCE, TE aggregation, etc.) in order to be successful.


I think what your draft points out, however, is that the complexity for GMPLS is increased considerably (perhaps to a power of three). It is further worth noting that if we added some speculative future routing constraints (such as source-based lambda selection, optical impairments, etc.) the problem would get even more complex.

Essentially, however, the problem is the same: IP route aggregation is not sufficient to enable inter-domain TE and some other solution is needed. Your proposal for EGP extensions to general reachability information is certainly one option. 

The concern that I have heard voiced is that there may be significant churn in this information, and this would result in a significant amount of aggregation computation by the ASBRs. My view is that:
- in a non-PSC GMPLS network the rate of change is 
  not likely to be significant
- we should, in any case, specify damping of computation
  and updates if we proceed with this approach.
But I would be interested to hear this debated further especially by the EGP experts.



Your point about SRLGs is very valid. Currently, however, (as I understand it) we don't have a satisfactory encoding for SRLG IDs to allow an ID to be globally unique *and* to allow an SRLG to span ASs.

Thanks,
Adrian