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

[Mach Chen <[e-mail]>]

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. 

> 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.

> 
> 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.


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