Re: [mpls-tp] Alarm Reporting (aka AIS)

[<[e-mail]>]

Sasha,

Fully agree. As you point out AIS with IP as the client is truly meaningless. And as John Drake pointed out earlier, the only currently defined clients for MPLS-TP are IP, MPLS, and PW. And all of these happily look after themselves without AIS.

So we have something which is both untrustworthy and unnecessary. However, the implementation doesn't come for free - we all pay for it anyway. More importantly, the reason always cited for implementing it is 'compatibility with existing transport network operational models'. In these current operational models, AIS is fully trustworthy. So if we follow the logic of it implementation, we will have operational staff trusting something as if it is fully trustworthy when in fact it is not. This is where the true cost of the misguided use of AIS may well lie.

Andy


Andy Reid
Chief Network Services Strategist
BT Innovate

Office: [phone]
Mobile: [phone]
Fax :       [phone]
Email:  [e-mail]<mailto:[e-mail]>
WWW:    http://www.bt.com/

This email contains BT information, which may be privileged or confidential.
It's meant only for the individual(s) or entity named above. If you're not the intended
recipient, note that disclosing, copying, distributing or using this information
is prohibited. If you've received this email in error, please let me know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.

British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000



________________________________
From: Alexander Vainshtein [mailto:[e-mail]]
Sent: 09 December 2010 10:05
To: Maarten Vissers
Cc: Reid,ABD,Andy,DEE1 R; [e-mail]
Subject: RE: [mpls-tp] Alarm Reporting (aka AIS)

Maarten,
One brief comment that you probably have heard quite a few times from me.

You have said in your response to Andy Reid:
The adaptation sink functions in the transport network technologies not only "can know" this information, they actually "do know" this information.
The problem with MPLS-TP is that, as long as its data plane is aligned with that of MPLS (and it is!) its analog of the "adaptation sink function", namely the ILM entry with the "Pop and Loop" action on a specific label do not have this information. I.e., when MPLS pops a label, it can handle both labeled and unlabeled packets that result from this action. When the resulting packet is labeled, handling of the next label does not depend on the previous one.
And of course handling unlabeled packets (IP as an immediate client of an MPLS-TP LSP) is just as possible and, IMHO, just as relevant...

After writing this, I think (and I apologize that I've only noticed it that late), that IP as an MPLS-TP client that does not have any AIS is a great counter-example to AIS into the clients...

Regards,
     Sasha