Subject: Re: Clarification on today discussions

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 19 Mar 2002 18:00:32 -0500

At 12:56 PM 3/19/2002 -0800, Shahram Davari wrote:
>Hi All,
>
>During today's MPLS meeting, Ping Pan raised the question that the 
>application should
>derive the solution, and that he is not aware of any application needs 
>that can't be
>met by LSP-ping and GTTP.
>
>My answer was:
>
>ATM/FR over MPLS application requires that upon any failure detection in the
>MPLS network, AIS should be sent from the egress LSR on the ATM/FR connections
>in order to suppress the downstream alarms at the terminating point of those
>connections. This can't be done with ICMP/LSP-ping or GTTP, because in 
>these solutions
>the egress is not the node that detects the failure. While in Y.1711 it is 
>the egress
>LSR that detects the failure and can correctly inject AIS in to the ATM/FR 
>connections.
>
>Talking to Ping Pan after the meeting, I realized where his comments are 
>coming from.
>His argument is that since he doesn't know of any deployed ATM/FR over 
>MPLS network, he thinks
>there is no problem to be solved.
>
>In other words he thinks we should not try to fix a problem which has not 
>occurred
>in the real world yet. Although this might be an acceptable approach to 
>some folks/companies,
>this is not simply true for many others. In my opinion anticipation of the 
>problems and
>providing solutions upfront is a sound engineering practice and leads to 
>easier adaptation
>of the technology in shortest amount of time without frustrations.

         This is a problem that can be solved using the existing tools. 
Same for the PWE
case.  If you set up a bidirectional ping (one on each PE), then one or 
both ends of the connection
can detect the failure (egress or ingress).  Alarms can be suppressed or
alternate actions can be taken appropriately.

         --Tom

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.

---

From: Shahram Davari <[email-masked]>
Date: Tue, 19 Mar 2002 15:28:25 -0800

Interesting. 

1) Could you please clearly indicate how can the egress LSR find that there is a 
failure on the forward LSP using LSP-ping?

2) I would actually not misguide people by words such as "existing solution". 
In fact I would say Y.1711 is an existing solution because it is ITU standard.
Regardless, It seems that your so called "existing solution" had a 180 degree 
change in the last version (03).

Yours,
-Shahram

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Tuesday, March 19, 2002 6:01 PM
> To: Shahram Davari
> Cc: [email-masked]'
> Subject: Re: Clarification on today discussions
> 
>

---

From: Scott Bradner <[email-masked]>
Date: Tue, 19 Mar 2002 18:54:20 -0500 (EST)

> In fact I would say Y.1711 is an existing solution because it is ITU standard.

I did not think that it had been formally approved yet - was I
misled?

Scott

---

From: [email-masked]
Date: Wed, 20 Mar 2002 01:59:09 -0000

Thomas D. Nadeau wrote 19 March 2002 23:01
<snip>
> alternate actions can be taken appropriately.
NH=> Tom, can you please clarify how you tell the higher layer network
trails supported (eg ATMoverMPLS) that they should not raise any alarms?
Note that these trail term pts my be in another network domain.
BTW - If you do do as you suggest then it seems you are slowly getting there
but:
-	the solution is more complex than CV
-	its not clinet layer or control-plane agnostic like CV
-	AFAIK there is no agreed definitions of defects or consequent
actions defined anywhere (like Y.1711 has)
So, you are proposing we accept a worse solution that is still not thought
through or developed right?

---

From: "Cuevas, Enrique G, ALASO" <[email-masked]>
Date: Wed, 20 Mar 2002 10:09:40 -0500

>I am not interested in working a "Long Term Solution for 
>Generations to 
>Come". That's just my personal opinion.

What is  "long term" for you?
I think your company has the opportunity and challenge to start designing now the robust OAM tools that are needed by Operators to support many applications. Yes, despite of all the different approaches being discussed, ATM/FR on MPLS is what many of your PWE3 colleagues are working on, some operators/vendors even claim that they are providing services/products already (?). So, it must be real. The question is, is the platform robust?

Enrique
_______________
[email-masked]
Tel. (732)-420-3252

>From: Ping Pan [mailto:[email-masked]]
>Sent: Wednesday, March 20, 2002 7:32 AM
>To: Shahram Davari
>Cc: [email-masked]'
>Shahram Davari wrote:
>> During today's MPLS meeting, Ping Pan raised the question 
>that the application should
>> derive the solution, and that he is not aware of any 
>application needs that can't be
>> connections. This can't be done with ICMP/LSP-ping or GTTP, 
>because in these solutions
>> the egress is not the node that detects the failure. While 
>in Y.1711 it is the egress
>> LSR that detects the failure and can correctly inject AIS in 
>to the ATM/FR connections.
>> 
>> Talking to Ping Pan after the meeting, I realized where his 
>comments are coming from.
>> His argument is that since he doesn't know of any deployed 
>ATM/FR over MPLS network, he thinks
>I am not interested in working a "Long Term Solution for 
>Generations to 
>Come". That's just my personal opinion.
>
>
>> I would like to bring your attention to the fact that such a 
>problem can also happen in the
>> L1/L2 over MPLS networks as well as static configured LSPs 
>and CR-LDP based LSPs, which can't 
>> use LSP-ping to solve. This is simply an engineering 
>observation and not a fortune telling.
>> 
>
>
>Base on the requirements and suggestions from other providers and 
>vendors, Kireeti has re-written the draft to support the applications 
>above. Please read -03 draft.
>
>Thank you!
>
>
>- Ping
>

---

From: Shahram Davari <[email-masked]>
Date: Wed, 20 Mar 2002 09:10:54 -0800

Ping,

> > LSR that detects the failure and can correctly inject AIS 
> in to the ATM/FR connections.
> > 

... therefore you don't want those who are interested to find a solution either.
Very interesting logic.

> 
> 
> > I would like to bring your attention to the fact that such 
> a problem can also happen in the
'

1) Version-03 can't still support defect mapping of LSPs to ATM/FR VP/VC AIS at the egress.
2) Although it says it can support CR-LDP, but the procedure is not defined.

Thank you,
-Shahram

---

From: "David Allan"<[email-masked]>
Date: Thu, 21 Mar 2002 09:41:44 -0500

George,

There's actually multiple scenarios to consider. If the network is LDP
driven, then the PW endpoint is not expected to have to take any action to
perform fault recovery, the network will recoverge, and if it is possible to
for the network to restore connectivity it will just happen. 

If the network is ER-LSPs because I needed to engineer some applications or
require high availability, I may also provide recovery paths for the service
that the PW layer does not know about, and the MPLS layer is expected to
take some proactive action to restore service on failure (e.g. protection
switching, re-balancing multilink...whatever) and this may frequently be in
the form of the LSP ingress needing to do somthing while the rest of the
network does not. In these recovery scenarios, the end point controls it's
MPLS destiny. This is a different application of the e2e principle and has
similar validity. Recovery takes place at a layer that can do somthing about
it. Availablity measurement is not the only function enabled here.

Pushing this functionality into the PW layer does not make sense, it is not
expected to be aware of the transport attributes. It is a passive partner.

cheers
Dave

> From: George Swallow [mailto:[email-masked]]
> Sent: Wednesday, March 20, 2002 6:07 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Neil -
> > NH=>Well, that means one has to question the viability of 
> what is happening
> > in PWE3 and whether anyone is intending to carry ATM, or 
> anything else like
> > Sonet (since exactly the same principles apply here), over 
> MPLS....or more
> > accurately any PSN.  It can't be argued both ways, which 
> seems the current
> > case. So what's the answer from the ADs on this?
> 
> I quite agree that an operator who uses MPLS to extend and or replace
> an ATM or FR service may well desire a level of OAM in the MPLS
> protion that matches what exists (or is expected) elsewhere.  But
> following the end-to-end argument, this should be built into PWE3
> solutions.  The vast majority of MPLS which is not offering such
> services should not be "strongly recommended" to adopt such methods.
> 
> ...George
> 
> ==================================================================
> George Swallow       Cisco Systems                  (978) 497-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
> 
>

---

From: George Swallow <[email-masked]>
Date: Thu, 21 Mar 2002 10:45:26 -0500

At 09:41 AM 3/21/2002 -0500, David Allan wrote:

>George,
>
>If the network is ER-LSPs because I needed to engineer some applications 
>or require high availability, I may also provide recovery paths for the 
>service that the PW layer does not know about, and the MPLS layer is 
>expected to take some proactive action to restore service on failure (e.g. 
>protection switching, re-balancing multilink...whatever) and this may 
>frequently be in the form of the LSP ingress needing to do somthing while 
>the rest of the network does not. In these recovery scenarios, the end 
>point controls it's MPLS destiny. This is a different application of the 
>e2e principle and has similar validity. Recovery takes place at a layer 
>that can do somthing about it. Availablity measurement is not the only 
>function enabled here.

When we say that were concerned about the implications of Y.1711 on IETF 
protocols, it's exactly the above
scenario that worries me.  If all it were, was a matter of letting the 
endpoints know whether MPLS-OAM were
being used or not then I wouldn't be too concerned.  Where my concern comes 
in is in the binding required
(or at least implied by your FDI/RDI stuff) between various things that 
currently run quite idependently.

Suppose I'm using LDP to set up a PW app.  Initially it's running over LDP 
in the core which (for scalablity
reasons) does do MPLS-OAM.  At some later time I set up a TE tunnel which 
can support MPLS-OAM and
routing sends the PW app packets over this.  Is some signalling needed at 
this point?

When the tunnel is created do I have to go look at what might be carried 
over it and figure out if they want me
to suppress or enable alarms.   If routing changes do I have to revisit all 
of this?

What's the impact on things like fast reroute?

Do you need additions to BGP for RFC2547 VPNs?

...George

---

From: [email-masked]
Date: Thu, 21 Mar 2002 16:10:57 -0000

George.....thanks, I largely agree that this is one application of MPLS that
needs such attention.  However, it can apply to other applications (eg
VPNs...and where a p2p transit LSP is merely a degenerate topological case
of such) if deemed appropriate (wrt to actual MPLS technology embodiment
used, and not all are) and required (eg because the operator/customer wants
to have strong/measurable SLAs).

regards, Neil

> Sent: 20 March 2002 23:07

---

From: "David Allan"<[email-masked]>
Date: Thu, 21 Mar 2002 11:56:06 -0500

George:

Apologies for the relatively long post, you had a lot of questions to
answer...I've snipped out my original comments.

> being used or not then I wouldn't be too concerned.  Where my concern
comes in is in the binding required 

But things like fast re-route imply similar bindings. 'x' is broken so the
box may be pre-configured to then do 'y'. Currently 'x' is notified by
signalling or some form of adjacency failure, in the future we'll have added
a user plane mechanism for notification. This enables global repair, as we
have eliminated the control plane latency bottleneck. 

Global protection schemes are in the recovery framework, emerging in GMPLS
yadda, yadda, yadda. The signalling extensions for such protection schemes
are happening independently of this work because they are required for
GMPLS. If the actual concern here is that applications that lever OAM stuff
to add to the suite of reliability constructs may result in extra protocol
changes, then I don't buy it. If anything, we're just hitting an overall
commonality of toolkits.

> reasons) does do MPLS-OAM.  

Does or does not?, not quite parsing this....

> At some later time I set up a TE tunnel which can support MPLS-OAM and 
this point?

If I understand the question correctly, is the OAM for the LDP layer and the
OAM for a TE tunnel that the LDP layer may ride over decoupled? If so the
answer is yes. The OAM is specific to the MPLS level.

> to suppress or enable alarms.   If routing changes do I have to revisit
all of this?

Not fully parsing the comment, are you suggeesting alarm generation is a
function of the application?

I simply have an extra tool for determining tunnel failure. To contrast it
with LSP PING, the tunnel egress detects the failure, rather than the
ingress. The egress can more easily to an authoritative determination. I
hate to compare apples, but I am not sure that the overall implications are
any different between the solutions beyond the complexity of fault
detection. 

> What's the impact on things like fast reroute? 

I presume the actual discussion here is if I use global repair and/or local
repair and I run OAM. IMHO I use 'a' or I use 'b', this is the network
operator decision. 

If the suggestion is that we are stochastically employing recovery
techniques, then I'll offer the following. If it is detours, this is
signalled by the ingress, and I can determine if there is a conflict in
repair styles. If it is bypass tunnels and this is somthing the ingress has
no knowledge of , then presumably the repair takes place faster than the OAM
would detect failure (or at leeast that's the claimm) and OAM would then
only measure availability or failures that the bypass tunnels could not
correct. If i am using 1:1 or 1+1 in a network where I am also using
detours/bypass tunnels...well no comment there. If I am stacking repair
techniques, there are issues, but then that is true across the board and
independent of this particular application.

> Do you need additions to BGP for RFC2547 VPNs? 

As the VRF layer and the transport layer are both typically mp2p, not clear
to me that there is a simple applicability of the OAM stuff in this
scenario. IMHO if I was using OAM, it would be easier and mjore scalable to
measure availability of the transport layer (PE-PE connectivity) and let the
VRFs inherit that information locally rather than measuring each VRF
adjacency uniquely. Besides, I am not going to try to signal recovery over
BGP. It is not useful and similar to the comment on the PW end to end
argument.

hope this helps
Dave