Subject: Re: [mpls] "Questions and comments on draft-chen-mpls-return-path-specified-lsp-ping-02".

From: "Ehud Doron" <[email-masked]>
Date: Sat, 3 Jul 2010 07:26:17 +0300

Hi Mach

Thanks for your comprehensive answers. 
Please see my comments below. 

We are highly recommend to add a new field to the RP TLV, it will make
reply path specific LSP actions much
simple and less error prone. It also helps us to report both forward and
reply path results.

In addition, here are typos in: page 4 chapter 2.1 second paragraph ,
page 10 first paragraph (extra dot) 

Best wishes,  
Ehud Doron
Orckit - Corrigent 

-----Original Message-----
From: Mach Chen [mailto:[email-masked]] 
Sent: Tuesday, June 22, 2010 2:04 PM
To: Ehud Doron
Cc: Ehud Doron; Rafi Ram; [email-masked]
Subject: Re: "Questions and comments on
draft-chen-mpls-return-path-specified-lsp-ping-02".

Hi Ehud,

Thanks for your comments!

Please see my reply inline...

--------------------------------------------------
From: "Ehud Doron" <[email-masked]>
Sent: Tuesday, June 22, 2010 4:21 PM
To: "Mach Chen" <[email-masked]>
Cc: "Ehud Doron" <[email-masked]>; "Rafi Ram" <[email-masked]>; 
<[email-masked]>
Subject: "Questions and comments on 
draft-chen-mpls-return-path-specified-lsp-ping-02".

> Dear Mach
>
>
>
> We have a few questions and comment regarding current version of the
> draft:
>
>
>
> 1. In page 12 chapter 4.2 paragraph 1 :  If the egress LSR doesn't
find
> the desired return path, in which path it should sent an echo reply
with
> Errored TLVs? I assume that via the IP path. It should be specified in
> the text. In this case does the reply mode in the echo reply shall
> remain 5?
>
Here it actually assumes via default return path, it could be either IP
or 
LSP path. And in this case, although the return path may not be the one 
specified by the ingress, the echo reply is still a reply of previous
echo 
request with reply mode 5, so, it's better to keep the reply mode as 5.
Of 
cause, set to other return modes will work as well.

>>Ehud - I recommend to explicitly specify in the text that: 1. the
return 
>>code shall be 5 and that 2. The return path can be any suitable LSP or
IP.  

>
> 2. In page 12 chapter 4.2 paragraph 2 :  The paragraph shall be better
> explained. What in the meaning of "2) indicating whether the return
path
> SHOULD be tested (by carrying the FEC stack TLV of the return path)."
?

Sorry for the confusion, actually the follow up two paragraphs are
trying to 
explain the two functions, respectively.

In the draft, whether carrying the Any Candidate sub-TLV in the echo
request 
implicitly indicates whether testing/detecting the return path. That is,
if 
the Any Candidate sub-TLV present, means not to test the return path and
it 
just tells the egress to exclude some return paths or select an
alternate 
return path. If the Any Candidate sub-TLV does not carried in the echo 
request and only a RP TLV carried, means that the echo reply should
carry 
the FEC stack information of the return path and to test it.

>>Ehud - OK, please update the text it will be better explained.
>>Please see my comment to 4 below. Using ACTION field in RP TLV for the
forward
>>path, can make it much clearer.
>>

>
>
> 3. In page 12 chapter 4.2 paragraph 3 :  In "select other path to send
> the echo reply" , do you mean that the egress LER shall independently
> find other LSP that ends in the Ingress LER ?

Yes,

In this case, the egress should exclude the paths carried in the RP TLV
and 
find an alternate return path to send the echo reply (in this case, as
said 
above, the Any Candidate sub-TLV is carried). For example, if there are
3 
return paths(1,2,3), when path 1 failed, the operator may not want to 
specify path 2 or 3 as the return path specifically , it just carries
the 
previous tried return path (path 1) and the Any Candidate sub-TLV to
tell 
the egress to select one from path 2 and 3 as an alternate return path.
This 
is useful when the default return path is suspected, the operator just
needs 
to tell egress to choose an alternate path to confirm/exclude the
suspicion.

>>Ehud - OK. I think these explanations can make the text much clear, so
they 
>>need to be added to the text. 

>
> 4. In page 12 chapter 4.2 paragraph 1 : In cases the Egress LER
receives
> echo reply with Error TLV contains the RP TLV in it, how can the
Ingress
> LER can deduce whether the Egress LER didn't find the return path LSP
or
> just didn't recognized some TLV (maybe the return status)? We strongly
> claim that a dedicated status shall be added to the RP TLV, explicitly
> define the exact operation took by the Egress LER. Otherwise un
covered
> issues and misinterpretations might arise and cause problem. In
> addition, taking action according to existence or inexistence of
> sub-TLV, make the implementation cumbersome and bug sensitive.

In the current draft, if the egress could not find a matched LSP, the
egress 
reply with Error TLV to indicate this. If the egress does not recognize
the 
TLV, the existing LSP Ping return code 2( One or more of the TLVs was
not 
understood) can cover this.

>>Ehud - I think that this indication is wrong, adding the Error TLV
when all TLVs 
>>are OK  is problematic. I can describe some cases when it might be
troublesome:
>>1. Let's assume that all the forward path verifications passed
successfully. 
>>In the case the RP cannot be reached, the return code indicates a
problem, in spite of 
>>the fact that the forward path results are OK. What should be reported
to the operator 
>> about forward path results?
>>2. Or another case there is a failure in the return path (for example
"No label entry"), 
>>And again the RP cannot be reached. The return code MUST be 11 (for
forward path indication) 
>>rather than 2. 
>>I am sure one can think on other scenarios with difficulties. 

Since the current return code defined in the echo request/reply message
is 
for reporting the result of the forward direction detection, it could
not be 
re-used to reflect the egress operation anymore, unless defines a new
code 
somewhere, do you have any suggestion.

>>Ehud - I am strongly suggest to add a new field to the RP TLV named
"ACTION". 
>>It the echo request, the LSP head end can use the ACTION field to
explicitly 
>>define its desires (specific LSP, tunnel, any return path etc.).
>>More important, in the echo reply, the LSP tail end can use the ACTION
field to 
>>report its behaviors. For example, it the RP cannot be reached, we can
use an 
>>action code equal to "RP CAN NOT BE FOUND", and add the sub-TLV of
that RP in the RP TLV
>>and not in the Errored TLV.
>>Using a separate status for forward path and reply path is very useful
and allows a separate 
>>reports (to the operator) about tests results for both forward and
reply path. Verify both
>>paths is one of this draft targets.    

>
> 5. In page 13 chapter 4.3 paragraph 1 : Typo in the end of the
> paragraph.

OK, will fix it.

>
> 6. In page 13 chapter 4.3 paragraph 3 : This chapter shall be better
> explained. What is the exact scenario handled in the chapter?

The scenario is that the operator just want to specify the return path
in 
order to help doing fault localization, for example try to specify an 
alternate return path to exclude/comfirm the suspision of the default
return 
path.

>
> 7. In page 13 chapter 4.3 paragraph 4 : We strongly claim that the RP
> TLV is required with a dedicated status, describe the exact operations
> took by the egress LER.

Same as comments 4 above.

>>Ehud - Same as comment 4 above.

>
> 8. If there are some faults in the ping for the forward path, does the
> egress LER shall use the specified return path? I assume it should. It
> should be specified in the test.

Yes, it could if the echo requect can reach to the egress. The current
draft 
does not exclude this.

>>Ehud- OK, it should be added to the text. 

>
> 9. A considerations for Echo Request with RP TLV received by LSR are
> required to be added.

OK.

Best regards,
Mach

>
> I will forward you more comments after we will agreed on those stated
> above.
>
>
>
> Best wishes,
>
>
>
> Ehud Doron
>
> Orckit- Corrigent
>
>
>
>

---

From: Mach Chen <[email-masked]>
Date: Mon, 05 Jul 2010 09:16:45 +0800

Hi Ehud,

Thanks for your valuable comments and suggestions! We will think it over and 
try to make the draft clearer in the next reversion, especially for the new 
flag field to RP TLV.

Many thanks,
Mach

--------------------------------------------------
From: "Ehud Doron" <[email-masked]>
Sent: Saturday, July 03, 2010 12:26 PM
To: "Mach Chen" <[email-masked]>
Cc: "Rafi Ram" <[email-masked]>; <[email-masked]>; "Nir Ben Avraham" 
<[email-masked]>; "Yossi Fridman" <[email-masked]>
Subject: RE: "Questions and comments on 
draft-chen-mpls-return-path-specified-lsp-ping-02".

OK.