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

From: Mach Chen <[email-masked]>
Date: Tue, 22 Jun 2010 19:03:39 +0800

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.

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

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

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

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.

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

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

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