Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02

[Sam Aldrin <[e-mail]>]

Hi Mach,

Inline for my brief comments
On Aug 29, 2014, at 8:32 PM, Mach Chen <[e-mail]> wrote:

> Hi Sam,
> 
> Some replies inline...
> 
> Sniped.
> 
>> 
>> Let us take the MPLS TP with IP on every node.
>> The scenario you are talking about is 'associated bidirectional' tunnel.
>> Just because a 'vendor' implemented certain default method doesn't require
>> new TLV support.
>> For associated bidirectional tunnel with IP on every node, perform reply mode as
>> IP.
>> I don't think RFC4379 warrants certain default type to be fixed type for a given
>> FEC.
>> 
>> [NOBO] What you say is true only if all operators prefer IP return path over
>> control channel and reverse LSP. I am aware of operators who wants to prefer
>> control channel or reverse LSP whenever available, over IP path. The preference
>> really varies depending on operators. This is exactly where this extension can
>> benefit.
>> %sam - We discussed this before but ended up with opposite conclusion :D. If
>> user want to perform return path via lsp or via IP, nothing prevents and one could
>> chose either of them. The same goes for bitmap size, selector size etc.
> 
> Your assumption is that all nodes along the path support both IP and LSP return path, this may not always true.  In some mobile backhaul networks that normally have access and core network parts, the nodes in the access may only support pure MPLS-TP and not support IP forwarding; the nodes in the core part normally support IP/MPLS. Then takes the picture in A.2 as an example:
> 
>                             +----C------D----+
>                           /                                   \
>  A'----A------B                                   G---H---H'
>                           \                                  /
>                            +----E------F----+
> 
> Where A', A, H and H' only support pure MPLS-TP and do not support IP forwarding, B and G support both LSP and IP return path, it means that reply mode 2 cannot be used when perform traceroute. But when  "Reply via reverse LSP" is used, since  C, D, E and F may not have reverse LSP path but have IP return path, it still cannot traceroute the whole path. In this case, actually, any single reply mode cannot satisfy the requirement. 
Neither does this new TLV will help, nor mandating IP reply mode only trace is what I am advocating.
Head end do not know which nodes support IP or which don't. 
For the same topology, If C,D,E and F do not support IP, this new TLV is not going to help you either.
Solution cannot be topology specific, where the initiator do not know what the topology is or will be.
What you have is a solution, trying to find a problem.

As I said in my earlier emails, performing IP and reply via LSP trace simultaneously could achieve the same result, for mixed mode (some nodes do not support IP) topology. Performance or diagnosing is not an issue as Timeout value, ttl value etc are all configurable and 4379 does not mandate what those values should be.


> 
> The essential of the Reply Mode Order TLV is to allow multiple reply modes to be used for a specific LSP, and each responder can select its appropriate reply mode to return the echo reply.
You could achieve that without the need for new TLV and upgrade of the network.

cheers
-sam
> 
> 
> Best regards,
> Mach