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

From: Mahesh Akula <[email-masked]>
Date: Tue, 17 Aug 2010 11:48:18 -0700

Hi Nitin,

>From this mail thread, can it be assumed that LSP Tracing without IP
Encapsulation does not work for Associated bidirectional LSP's since there
may not be a return LSP path from the responding transit node?

Also when a node receives LSP Echo request w/o IP encapsulation and
replymode "not" set to 4, should it drop the packet or should it try to
respond back with Malformed Echo request error?

Regards,
Mahesh

On Thu, Jun 24, 2010 at 8:59 PM, Mach Chen <[email-masked]> wrote:

> Hi Nitin,
>
> Thanks for your reply!
>
> See my reply inline...
>
> --------------------------------------------------
> From: "Nitin Bahadur" <[email-masked]>
> Sent: Friday, June 25, 2010 1:56 AM
>
> To: "'Mach Chen'" <[email-masked]>; <[email-masked]>
> Subject: RE: [mpls-tp] Comments on draft-nitinb-mpls-tp-on-demand-cv-00
>
>
> 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.
>>
>
> IMHO, it's better for transport network to have bi-directioanl phyical
> paths, but it could not exclude the situation where the two directions are
> diverse(at least partially diverse), and this is one of the reasons that
> associated bidrectional LSP required in MPLS-TP.
>
>
>
>> 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....
>>
>
> I basically agree with you analyse, so for associated bidirectional LSP,
> the operation is almost the same unidirectional LSP.
>
> One more question: does the tracing result of an associated bidirectional
> LSP inlcude the reverse path, or just one direction? if incluing reverse
> direction, how to process and present the result?
>
> Best regards,
> Mach
>
>
>
>
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: Nitin Bahadur <[email-masked]>
Date: Tue, 17 Aug 2010 12:13:10 -0700

Hi Mahesh,

> From this mail thread, can it be assumed that LSP Tracing without IP Encapsulation does not work for Associated bidirectional LSP's since there may not be a
> return LSP path from the responding transit node?

For co-routed LSPs, there will always be a return path. For non co-routed LSPs, there may not be a return path and non-IP encap might not work.

> Also when a node receives LSP Echo request w/o IP encapsulation and replymode "not" set to 4, should it drop the packet or should it try to respond back with
>  Malformed Echo request error?

   It should either drop the packet or respond back with the requested reply mode.

Thanks
Nitin

---

From: Mahesh Akula <[email-masked]>
Date: Tue, 17 Aug 2010 12:47:32 -0700

Hi Nitin,

On Tue, Aug 17, 2010 at 12:13 PM, Nitin Bahadur <[email-masked]> wrote:

> may not be a
> For co-routed LSPs, there will always be a return path. For non co-routed
> LSPs, there may not be a return path and non-IP encap might not work.
>
[MA] Okay.

>    It should either drop the packet or respond back with the requested

[MA] Responding back with the requested reply mode may not be correct
because while sending the packet, draft explicitly specifies that reply mode
in the lsp ping request MUST be set to 4. If it is not, it means the request
packet is malformed right? If it is suggested to drop the packet in such
case,  I think text may be added in the draft stating this.

> Nitin

Thanks,
Mahesh

---

From: Nitin Bahadur <[email-masked]>
Date: Tue, 17 Aug 2010 13:06:31 -0700

Will add relevant text.

On 8/17/10 12:47 PM, "Mahesh Akula" <[email-masked]> wrote:

[MA] Responding back with the requested reply mode may not be correct because while sending the packet, draft explicitly specifies that reply mode in the lsp ping request MUST be set to 4. If it is not, it means the request packet is malformed right? If it is suggested to drop the packet in such case,  I think text may be added in the draft stating this.

Thanks
Nitin

Thanks,
Mahesh