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

[ogino <[e-mail]>]

Hi Adrian and Tomo,

Thank you for your interesting discussion.

Though I am not an EGP expert,  I suspect that it will be problematic to 
advertise the TE information by an EGP-TE from the viewpoints of 
scalability and complexity. Particularly, the TE information will be 
confidential in the Inter-Provider case even if such TE information can be 
aggregated.
The PCE model can solve this problem because no TE information is 
advertised to the externals and only the result of path computation is 
notified to the external node requesting the path computation (Head-end 
LSR, ASBRs, other PCEs, etc.). Even in the PCE model, the crankback 
function is necessary because the TE sate may change rapidly and the time 
lag between the path computation and the path establishemt may be 
relatively large.

As you pointed out, different SPs may have TE links included in the same 
SRLG. Moreover, even if appropriate SRLG can be allocated to each TE-link 
gloabally, such SRLG information will also be confidential in the 
Inter-Provider environment.
At least, the SRLG can be allocated appropriately within a provider's 
network according to the provider's policy, and multi-paths with the SRLG 
diversity can be correctly established within a provider's network. Thus, 
it is practical to establish the working path and the corresponding backup 
path through the same sequence of provider's networks in the case of 
Inter-Provider LSP establishment.
Anyway, if both the working path and the backup path have damage 
simultaneously, dynamic re-routing is necessary.

As you pointed out, it is required to develop the SRLG encoding that can 
indicate the SRLG level (area, duct, cable, fiber, etc.). Each SP can 
establish a pair of working path and backup path with the appropriate SRLG 
diversity and satsfying the SLA when he/she can recognise the level of each SRLG.

Best regards,

Nagao Ogino


At 10:44 04/07/28, Tomohiro Otani wrote:
>Hi Adrian,
>
>Thank you for your comments.
>
>Some of SPs including ourselves have a plan to introduce GMPLS control plane
>technologies for a NGN, and even NGNs should be interconnected with each other,
>as SONET/SDH networks are as well as IP/MPLS networks are.
>
>Your supposed model is another example to reveal the necessity of Inter AS TE.
>I agree that a crankback mechanism is one of the ways to achieve this.
>
>In terms of the amount of computation by the ASBR, we have to investigate
>the impact on the load to the ASBR, hearing from the routing (EGP: BGP4?) 
>expert.
>That's why, in the draft, we described that the TE information may be 
>statically or
>dynamically exchanged.  Operators would like to know the route of a GMPLS LSP
>within an AS and the pair of ASBR in advance, if the LSP is established across
>the inter AS, especially multiple ISPs, resulting in the implementation 
>of TE extensions.
>
>The network resiliency is getting significant more and more in a SP environment.
>There was a big discussion about SRLGs among us and so far, as you pointed out,
>we do not have any solutions for this.  Altouhgh each SP believes that 
>these TE links
>are not a SRLG because these are belonging to a different SP, fibers 
>accommodating
>such TE links may be laid in the same duct otherwise the same tunnel 
>under the road.
>Our conclusion is that the level of SRLG is another issue.....(one issue 
>is indeed how
>to assign SRLG IDs to each SP)
>
>Regards,
>
>tomo
>
>
>
>
>At 18:41 04/07/27, Adrian Farrel wrote:
>>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
>
>******************************
>Nagao Ogino, Dr. Eng.
>KDDI R&D Laboratories Inc.
>2-1-15 Ohara, Kamifukuoka-shi,
>Saitama 356-8502 Japan
>TEL   [phone]
>FAX   [phone]
>E-mail   [e-mail]
>******************************