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

Nitin
I don't agree your opinions, according to your thinking. if there is no 
reverse path from B to A , B would 
not response to the request from A . or else, B would response to the 
request through existing reverse path 
from B to A .
IMO, for node A , how to know of whether to have a path from B to A ?
even if node A know there is a path from B to A , when the path have the 
failure.
do node B generate response packet to A? 
in additon, for node A ,if it can't receive the response packet from B , 
how to identify the error is in the path from A to B or not?

it will be confusion and diffcult to detect and localize the failure in 
the path.

best regards
liu

Nitin Bahadur <nitinb@juniper.net> 
发件人:  mpls-tp-bounces@ietf.org
2010-06-25 08:22

收件人
"'xia.liang2@zte.com.cn'" <xia.liang2@zte.com.cn>
抄送
"mpls-tp-bounces@ietf.org" <mpls-tp-bounces@ietf.org>rg>, "mpls-tp@ietf.org" 
<mpls-tp@ietf.org>
主题
Re: [mpls-tp] Comments on draft-nitinb-mpls-tp-on-demand-cv-00

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 

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