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

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

mpls-tp-bounces@ietf.org 写于 2010-06-24 05:34:32:

> Hi Mach,
> 
> On 6/21/10 8:47 PM, "Mach Chen" <mach@huawei.com> 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
> > mpls-tp@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> 
> _______________________________________________
> mpls-tp mailing list
> mpls-tp@ietf.org
> 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.