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

[Sam Aldrin <[e-mail]>]

Hi Mach,

See inline.
On Sep 1, 2014, at 12:45 AM, Mach Chen <[e-mail]> wrote:

> Hi Sam,
> 
> Please see inline...
> 
>> 
>> From: Sam Aldrin [mailto:[e-mail]]
>> Sent: Sunday, August 31, 2014 2:05 AM
>> 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,
>> 
>> 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.
> 
> To make traceroute work, two conditions are required;
> 1) intermediate nodes must know how to process reply mode; with the Reply mode TLV and the mechanisms defined in this document, a node could easily chose proper reply mode when it does not support the reply mode in echo request; simultaneously ping would require the operators or the smart ingress LSR to guess/compute which reply mode should be used.
> 
> 2) there MUST be return path(s) from intermediate nodes to ingress LSR; for whatever mechanisms used, this is a "MUST" condition.
> 
> According to the above two conditions, a node should at least support one reply mode and should have one return path to the ingress LSR. So for the question, if you ask me it does not support "IP", I can answer it could support LSP return path, we may not need to circle the question and answer :-)

If you use the logic above to support the case, it will totally fail.
You are discounting your own solution by the above logic.
In order to make your logic really really work, all nodes MUST support the new TLV, which will be a non-starter.

I have provided explanations for the topologies provided so far and how to make it work w/o the need for new TLV. You can refer to earlier emails.
Whether a node supports one or two reply modes is dependent on LSP type, Pick a LSP and we could discuss.

> 
>> 
>> 
>> 
>> 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?
> 
> I revised my saying in another email, my original meaning is that the node will not reply if it does not support a specific mode, of cause, increasing the TTL could make the subsequent echo requests reach to the next hop. 
That is how trace works, be it ICMP or LSP ping, uses ttl to go to next hop, which is not what you said earlier.
It will not reply if the node do not understand the new tlv either.


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