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

[Mach Chen <[e-mail]>]

Hi Sam,

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

Here I mean the nodes that do not support IP path will not correctly return the echo reply.


Best regards,
Mach

> -----Original Message-----
> From: Mach Chen
> Sent: Saturday, August 30, 2014 5:40 PM
> To: 'Sam Aldrin'
> 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 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