Re: ITP does not sent TFP for downed AS when connecting M2PA?

Ray Han · ‎08-30-2010

Hi all,

I wonder about TFP(Transfer prohibit) at connecting M2PA.

ITP#1 ------------(m2pa)---------ITP#2---------(m3ua)----------IPSP

down down

in above topology,

itp#1 ~ itp#2 connected with m2pa but its status was down.

itp#2 ~ IPSP connected with m3ua but its status was down.

as my opinion,

if itp#1 ~ itp#2 m2pa connection is active,

so itp#2 must send itp#1 a tfp for IPSP

because IPSP's status is down(it's unavailable)

but cisco itp(C7613) doesn't send tfp for IPSP

is this operation right?

i can't find the RFC or ITU document(Q.xxx) about this issue.

who's know about this?

sbolivar · ‎08-31-2010

Hello Sanghee Han,

Regarding your question. I think that under the circumtances mentioned ITP 2 would not send TFP for IPSP; however I would like that you let me know the following:

a) Did you shutdown AS on ITP 2, save the config and then reboot the ITP 2 on the mentioned scenario?

b) If answer to above question is "Yes", did you have traffic going to M3UA side before/after reloading ITP 2?

b) Please provide me with the detailed steps followed to reproduce the issue.

c) Also kindly test the following sequence of events and confirm their occurence:


1. Shutdown M3UA in ITP2
2. You should see ITP2 sends TFP(affected PC) to ITP1
3. Then ITP1 changes route status for PC from "avail" to "unavail" 

d) Please provide me with ITP IOS version that you are using and on which platform.

Hope that this helps to further isolate the problem.

Kind regards,

Samuel.

Ray Han · ‎08-31-2010

Hi Samuel,

as you know,

I opened a case about this issue and case owner is you v.

I think this issue isn't a critical issue to impact a service

but i hope to know about mtp3 management msg.

also without precise knowledge about this, i can't explain to my customer.

in reply, you commented shutdown M3UA in itp2

of course after shutdown and no shutdown steps,

itp2 will send a tfp(affected pc = m3ua pc).

i think your comment is right to change the management status for that pc.

but it's just a stopgap.

the essential is why itp2 does not send tfp for down as(affected pc==m3ua's pc).

detailed step

itp1 ~ itp2 m2pa connection status : down

itp2 ~ m3ua connection status : down (not shutdown)

1. activate the m2pa connection : down => active

itp2 ~ m3ua connection status down => not change

2. i expected itp2 would send tfp for m3ua as, but it didn't.

setps are very simple.

the reason that i opened a case,

I think this itp operation is seems to be a bug.

I hope to the cause is something to follow the standard,

otherwise it seems to be a bug.

ITP version : s72033-itpk9v-mz.122-18.IXH1.bin

platform : cisco7613

I will keep on eyes on this board,

if you have any idea about this, please update this board or case.

as much as i can, i will help you.

Thank you.

sbolivar · ‎09-01-2010

Hello Sanghee,

Thanks for the information. The specification that we should look into on this case is ITU Q.704 (Attached on this reply).

Over section 13.2.2 there is a list of the conditions when a TFP is sent, and it seems that according to this point ITP would send TFP for destination X, if X is inaccessible from ITP.

On the other hand and as far as my understanding goes, ITP2 from your topology is restaring MTP; so in section 9.2 there are two phases if signaling point has transfer functions. From your case phase 1 seems to be fine, however on phase 2 the broadcast on non-preventive TFP seems to occur for signaling link sets which are not available, and nothing else is mentioned on the speficiation apart from that.

I got a question on the test scenario:

a) Which part comes down first? M3UA and or M2PA? Becuase if M3UA goes down and M2PA is still up, ITP1 will receive TFP from ITP2; then when M2PA goes down and up on ITP2, ITP1 would send TFP to ITP2 with affected PC as M3UA's PC, and no TFP would be sent from ITP2 to ITP1 under such conditions.

Hope that this update helps you to clarify the current situation.

Regards,

Samuel.

sbolivar · ‎09-12-2010

Hi Sanghee,

Just wondering how you have progressed on this issue, so please drop me a quick note if you have any further questions.

Kind regards,

Samuel.

Ray Han · ‎09-14-2010

I updated the case.

please check the case.

Thank you.

sbolivar · ‎09-20-2010

Hello Sanghee,

ITP#1 ------------(m2pa)---------ITP#2---------(m3ua)----------IPSP

After further tests performed, during restart of M2PA link, ITP#2 does not send TFP to ITP#1 corresponding to IPSP (M3UA).

This is an expected behavior due to ITP design.

Route table becomes consistent once we ping or send traffic, so on IITP#2 route becomes unavailable.

Further details on the case opened with us in TAC.

Kind regards,

Samuel.

sbolivar · ‎11-24-2010

Hello all,

Just want to inform that this behavior has been studied by ITP Development Team, and I have opened enhacement bug CSCtj74184 that can be seen on the following link:

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtj74184

Roadmap information would be available shortly; so hopefully this would help anyone else having same issue.

Cheers,

Samuel.