Re: [mpls-tp] Comments on draft-nitinb-mpls-tp-on-demand-cv-00

[Nitin Bahadur <[e-mail]>]

Hi, Xia,

        Let me clarify what I meant. Consider

  A ----> B ----> C ---> D
   <-----    <----     <---

   Node B is a MIP. Node B does not have a direct LSP from B to A.....since it's a MIP. By the text in the draft, I meant
that node B should be able to identify that there is a LSP in the reverse direction (going to A via it) and should send
the echo response on that LSP. If there is no such LSP (going to A) for which node B is the transit, then node B should
just drop the packet.

Hope that helps
Nitin


 Hi Nitin:
  About the question of LSP trace, I still have some confusions with your answer. In the draft, section 4.2.3 says "If there is an error and the node is unable to identify the LSP on which the echo response would to be sent, the node MUST drop the echo request packet and not send any response back." This means that response must be sent on a return LSP. But in associated bi-directional LSP, MIP does not have an in band return LSP. So it seems that LSP tracing can not directly be supported in associated bi-directional LSP scenarios.
  Can you clarify it further? thanks!

                                 xia.liang
                                Best regards


[e-mail] 写于 2010-06-24 05:34:32:

> Hi Mach,
>
> On 6/21/10 8:47 PM, "Mach Chen" <[e-mail]> wrote:
> > Some comments or questions below:
> >
> > 1. Reverse path Connectivity verification(Section)
> > It says:"For bi-directional LSPs, when the egress sends the echo response,
> > the egress MAY attach the target FEC stack TLV [RFC4379] in the echo
> >    response.  The ingress (on receipt of the echo response) can use the FEC
> > stack TLV to perform reverse path connectivity verification..."
> > But in RFC 4379(Section 4.5), it says "...The FEC Stack TLV from the echo
> > request MAY be copied to the reply...", so based on the current LSP Ping
> > specification and the existing implementations, the ingress will interpret
> > the FEC Stack TLV is for the forward direction LSP.
> > For co-routed bidirectional LSP, since the FECs for both directions are the
> > same, this is OK to re-use the FEC stack TLV for reverse path CV. But for
> > associated bidirectional LSP, when the ingress received the echo reponse
> > with a FEC stack TLV, how does it determine whether the FEC is of the
> > forward direction or backward direction?  IMHO, it's better to use separate
> > FEC stack TLV for each direction, especially for associated bi-dir LSP.
>
> You are right that there might be some confusion. I'll look into this.
>
> > 2. MPLS-TP LSP trace
> > It seems that the current draft does not consider associated bi-directional
> > LSP scenarios where each direction may follow diverse paths and some MIP
> > nodes can not send echo reponse along the reverse lsp directly. Sothere may
> > be need some return path specified mechanisms to help associated
> > bidirectional LSP tracing.
>
> In non-error cases, I believe all MIPs should be able to send the response
> back on the reverse lsp path. In error cases, a MIP might be unable to send
> the response (because of the fault). In such a case, the first MIP which is
> unable to send the response back is the MIP where the fault is. The spec
> currently says that we must reply using application control channel. We can
> make that a should, so that if one wants, one can ask that the reply be sent
> via UDP....if there is another available path in the network.
>
> Thanks
> Nitin
>
> P.S: Please cc: one of the authors always, so that it's easier to dig
> through the incoming email flood.
>
> > Best regards,
> > Mach
> >
> >
> > _______________________________________________
> > mpls-tp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls-tp
>
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.