Re: [mpls-tp] Comments on draft-nitinb-mpls-tp-on-demand-cv-00

[Nitin Bahadur <[e-mail]>]

Hi Mach,

   Very good example. See more below.

> IMHO, even if in non-error cases(for associated bidirectional 
> LSP), the MIPs response may not be able to send the response, 

> see the figure below:
> A---B---C---D---E
>  \             /
>   F----G------H
> A associated bidirectional LSP combined with two 
> unidirectional LSPs( LSP1: 
> A->B->C->D->E, and LSP2: E->H->G->F->A), when the trace 
> request reach at 
> A->B->C->D->B,
> how does node B send the response? 

The above case is probably not how things get deployed in transport
networks (transport folks can correct me if I am wrong). Transport networks
typically have bi-directional physical paths.

In any case, there are 2 ways for B to send a response back, 
1) B sends the response back directly to A via IP or some other encapsulation.
2) B tunnels the packet to E and sends the response back.

Option 2 is not practical & insufficient, because if there is a fault at C, then the echo
response will never make it back...giving the impression that the fault is at B. 
Adding the complexity to tunnel the packet to E and then back seems too cumbersome 
and I don't see a real business case/requirement for the same.

Option 1 will not work if there is no IP/MPLS path back to A from B....but I consider that
more of a network design issue....

> there may not be direct 
> return path from B to A (including IP or LSP path), the only 
> way to send the response is continue to send the response 
> along LSP1, and round back at E and then send along LSP2 back 
> to A. In order to achieve this, IMHO, there need some 
> information to direct node B and node E to send the response, 
> including:
> 1. whether can send the response along the non-in-band path 
> or not 2. how to send the response along the round-path; and 
> if there exist both direct return path from a MIP to the 
> ingress and round-path, how to determine which path should be used.

Thanks
nitin