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

[Sam Aldrin <[e-mail]>]

Hi Mach,

See inline.

On Aug 30, 2014, at 2:40 AM, Mach Chen <[e-mail]> wrote:

> Hi Sam,
> 
> Thanks for your prompt response!
> 
> Please see my reply inline...
> 
>> -----Original Message-----
>> From: Sam Aldrin [mailto:[e-mail]]
>> Sent: Saturday, August 30, 2014 4:33 PM
>> To: Mach Chen
>> Cc: Nobo Akiya (nobo); Ross Callon; [e-mail]; [e-mail]
>> Subject: Re: [mpls] Poll for Adoption
>> draft-akiya-mpls-lsp-ping-reply-mode-simple-02
>> 
>> 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.
> 
> No, it can help only if C, D, E and F know how to handle the Reply Mode TLV. For your case, if C does not support IP, but it should support at least one other reply mode and then use that mode to send back the echo reply. 
Please quote with real LSP example you are talking about and which other way and reply mode you are talking about.
Please refer to earlier emails, why I say that.

> 
>> 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.
> 
> The above scenario is a very typical MBB scenario that deploys pure MPLS-TP in access and reuse the IP/MPLS for core network. And even if operators know (and normally they do) the topologies, they cannot depend on the existing mechanisms to trace the path for reason that a single reply mode cannot apply to an LSP that across nodes support different modes.
I have deployed and helped networks operated and troubleshoot them, so I know what I am talking about.
Provided examples how one could make it work without the need. Also provided why this TLV cannot help in the so called mixed mode.
In your own example, if C, D, E and F do not support ‘IP’ (not just new TLV), your solution do not work.
> 
>> 
>> 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. 
> 
> Given the above example, since A', A, H and H' only support pure MPLS forwarding and do not support IP forwarding, you cannot perform IP and rely via LSP trace simultaneously. Because when you reply mode 2 (IP path) to perform trace, the echo request will be dropped at A and will not have chance to reach to other nodes. Similarly, if you use reply via LSP, C,D, E and F will not find a reverse path.
Really? Then what is the purpose of TTL? Could you care to explain how the node drops a packet when TTL do not expire?

-sam
> 
> 
> Thanks,
> Mach
> 
>> 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