Subject: [Mpls-interop] MPLS-TP Ring Protection

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 17 Nov 2008 16:28:55 -0000

Hi,

John and I have been discussing "ring protection requirements" since Loa was 
so kind as to forcibly place the subject on the agenda for Wednesday.

We have put together the attached slides on the subject in an attempt to net 
down what a ring is, how it might be used, and what the requirements are.

Please have a look and send us any comments at the latest Tuesday so that we 
can update in tome for the meeting.

Cheers,
Adrian 
_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 18 Nov 2008 09:53:53 +0000

Adrian Farrel wrote:
> Hi,
>
> John and I have been discussing "ring protection requirements" since 
> Loa was so kind as to forcibly place the subject on the agenda for 
> Wednesday.
>
> We have put together the attached slides on the subject in an attempt 
> to net down what a ring is, how it might be used, and what the 
> requirements are.
>
> Please have a look and send us any comments at the latest Tuesday so 
> that we can update in tome for the meeting.
>
> Cheers,
> Adrian
> ------------------------------------------------------------------------
>
This is a good dummary.

Looking at the last slide:

Do we really need an I-D to describe ring protection requirements?

Which of the requirements listed would not be applicable in generic mesh 
networks?

It might be valuable to have an applicability statement

How to use existing mechanisms to provide optimized protection in ring 
deployments
Show how all “ring protection requirements” are solved

I think that the place to start would be with a description
of how to protect physical and layered rings using the
techniques we have to hand and see how they stack up
against the requirements. i.e. start with the last part
first.

I think that we need to write the descriptive part of that
in any case simply to address the large number of requests
to address the problem.

The gap analysis will drive how we proceed from there.

Stewart

---

From: "Malcolm Betts" <[email-masked]>
Date: Tue, 18 Nov 2008 11:08:14 -0500

Adrian, first apologies for making a vague comment at this late stage.

I have often heard from the people who run transport networks that the
real value of a ring is that it is easy to relate the traffic to the
physical topology.  This has a number of practical/pragmatic values:
- It is simple to plan maintenance activities or to account for
increased risk due, for example to construction.
- It is easy to demonstrate route diversity to a customer

So I think that a key element is missing from the ring requirements -
i.e. the ability to simply relate the working and backup paths to the
physical topology and the ability to provide the status of those paths.

This is counter to the "normal" packet network, but remember this is a
MPLS-Transport Profile requirement....

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Monday, November 17, 2008 11:29 AM
> To: [email-masked]
> Subject: [Mpls-interop] MPLS-TP Ring Protection
> 
> Hi,
> 
> John and I have been discussing "ring protection 
> requirements" since Loa was so kind as to forcibly place the 
> subject on the agenda for Wednesday.
> 
> We have put together the attached slides on the subject in an 
> attempt to net down what a ring is, how it might be used, and 
> what the requirements are.
> 
> Please have a look and send us any comments at the latest 
> Tuesday so that we can update in tome for the meeting.
> 
> Cheers,
> Adrian 
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 18 Nov 2008 17:20:33 -0000

I think there may be some nervousness that John and I are saying that 
operation of MPLS-TP in rings is out of scope in some way.

Far from it. As the slides show, there are some good and interesting 
deployment scenarios where traffic is placed on physical or logical rings.

Furthermore, we are stating that it is a definite requirement to be able to 
protect traffic in any topology.

What I hear from several conversations on and off the list, is that there 
are strong requirements to use ring topologies in certain situations. That 
is very OK. But we are not describing to operators how they can lay fiber. 
What we *are* describing is how MPLS-TP can provide the right level of 
function in all of the topologies that people want to use.

So it is good to hear that ring deployments are required. We have heard it 
and we are working to support it.

But, it continues to be the case that we have not heard any requirements 
that arise from the deployment of MPLS-TP in a ring that is not also a 
requirement in a more general network. It is not hard, therefore, to write a 
specific requirements draft for ring topologies, but it would be a 
considerable waste of time and effort.

Now, it may well turn out to be the case that the choice of MPLS-TP building 
blocks for different topologies will be different. Some features may be 
better suited to specific environments and may allow "optimizations", but in 
all cases, the features must interoperate so that if one topology is 
migrated to another topology the implementations will continue to work 
without needing to be changes (although, maybe, with loss of optimality). 
[So, there is a requirement we might put in the ring protection requirement 
draft - the solutions must be interoperable or work in other topologies.]

The reason we propose applicability statements (rather than a requirements 
draft) is that this allows more flexibility to the use of the core 
components of MPLS-TP to achieve the optimizations that people may want. 
Such documents would say: if you want to deploy in this type of network, you 
need to use these tools from the toolbox.

I will try to add this discussion to the slides.

Malcolm's specific requirement

> physical topology and the ability to provide the status of those paths.

I can certainly see that one might want to deploy such that working traffic 
goes one way on the ring, or some other clustering. More generally, to allow 
the operator to predict where the working/protection traffic is likely to be 
in the network from a knowledge of the topology.

This is clearly simpler to achieve in a ring, but surely we would want to 
achieve it in other network topologies. And isn't it also a feature of 
implementation at the LSRs?

Cheers,
Adrian

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 18 Nov 2008 09:26:21 -0800

Adrian,

Wrt the 'What Next' slide, I thought that the plan was to recast your
existing recovery framework I-D to describe how each of the seventeen
arbitrary topology MPLS TP protection/restoration requirements would be
met by current MPLS/GMPLS mechanisms, with examples of ring topologies
included.  (Btw, as the slides demonstrate, at the MPLS TP layer, there
is actually no difference betweeen a physical and a logical ring.)

As part of this activity, we would identify any holes that require new
work.  

Thanks,

John 

>From: Adrian Farrel [mailto:[email-masked]] 
>Sent: Monday, November 17, 2008 8:29 AM
>Cc: Drake, John E
>Subject: MPLS-TP Ring Protection
>
>Hi,
>
>John and I have been discussing "ring protection requirements" 
>since Loa was so kind as to forcibly place the subject on the 
>agenda for Wednesday.
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 18 Nov 2008 18:24:15 -0000

Hi John,

How nice to hear from you again. How are you?

> included.

Are you sure it is seventeen? That is a problem because we need more than 
one nibble to encode it.

> (Btw, as the slides demonstrate, at the MPLS TP layer, there

Yes.

> As part of this activity, we would identify any holes that require new

Absolutely. I meant to write this, but I forgot again before I got to the 
end of the email.

Yes, the porcess of writing about stuff (framework == set of 
applicabilities) will possibly uncover lacunae and these will need to be 
filled as they are found.

Adrian

Thanks,

John

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 18 Nov 2008 23:09:53 +0000

> implementation at the LSRs?

Yes being able to map traffic (i.e. An LSP) to specific topology is
important - e.g. To demonstrate to a customer that the diverse paths we are
selling them are really diverse.  But I do not see this as ring specific,
sure it is easier to do with a ring. I am also not sure that it is a
function of the technology beyond being able to pin routes to ensure that
the path you tell the customer their traffic is taking is the path it really
is taking.

Of course it is predicated on the assumption that operators know where their
fibre is routed in the first place.

Ben

---

From: <[email-masked]>
Date: Wed, 19 Nov 2008 18:41:12 +0100

Hi.

I agree that mapping easiness is really required. It is obvious that
rings imply this capability. However, some people have already been
operating mesh network for long without loosing this feature, therefore
this requirement definitely does not imply rings. (Especially as I think
about people operating Sonet/SDH networks which keep being pointed as a
reference...)

Furthermore, to support Ben's comment, let's recall that the only layer
that could proove actual diverse routing is the "fiber and duct" layer
(by the way that is why SRLGs in the control plane are made for). As a
result, building a ring in an upper layer without considering this
information does not guarantee anything.

Regards,

Julien

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins

Yes being able to map traffic (i.e. An LSP) to specific topology is
important - e.g. To demonstrate to a customer that the diverse paths we
are
selling them are really diverse.  But I do not see this as ring
specific,
sure it is easier to do with a ring. I am also not sure that it is a
function of the technology beyond being able to pin routes to ensure
that
the path you tell the customer their traffic is taking is the path it
really
is taking.

Of course it is predicated on the assumption that operators know where
their
fibre is routed in the first place.

Ben

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 19 Nov 2008 19:01:49 +0100

Hello Adrian,

You wrote:

> John and I have been discussing "ring protection requirements" since Loa 
> was so kind as to forcibly place the subject on the agenda for Wednesday.

I am really surprised by these slides.
As you mention these were drafted by you and John, however I
was under the assumption that I was part of a team that would
investigate/analyse the ring protection requirements.

Was there any particular reason not to include the team?

> We have put together the attached slides on the subject in an attempt to 
> net down what a ring is, how it might be used, and what the requirements 
> are.

On slide 8 you mention that you "translated" into "English"
the requirements from the ITU-T.

Why was this necessary? And why did you not ask the ITU-T
members in the team whether your interpretation is correct?

> that we can update in tome for the meeting.

Unfortunately my response is past the deadline, so too late
to change the slides, but maybe you can address my concerns
during the presentation, i.e. these slides are not reviewed
by the team and the "translation" on slide 8 is in fact an
interpreteation.

Thanks, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...
_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 19 Nov 2008 10:53:07 -0800

Huub,

Loa asked for a status report and I asked Adrian to create one, as I am
technology challenged.  The team saw the slides as soon as I did and had
the same window to comment, roughly two days, as I did.  I think the
phrase 'translated into English' is just an example of Adrian's
shameless pandering to his audience.

I thought the detailed requirements were copied directly from Ben's
requirements I-D, and everyone agreed to them at the interim meeting.

Thanks,

John 

>From: Huub van Helvoort [mailto:[email-masked]] 
>Sent: Wednesday, November 19, 2008 10:02 AM
>To: Adrian Farrel
>Cc: [email-masked]
>Subject: Re: [Mpls-interop] MPLS-TP Ring Protection
>
>Hello Adrian,
>
>You wrote:
>
>> Loa was so kind as to forcibly place the subject on the 
>agenda for Wednesday.
>
>Unfortunately my response is past the deadline, so too late to 
>change the slides, but maybe you can address my concerns 
>during the presentation, i.e. these slides are not reviewed by 
>the team and the "translation" on slide 8 is in fact an 
>interpreteation.
>
>Thanks, Huub.
>
>--

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 19 Nov 2008 19:08:10 -0000

Additionally, I have modified some of the more offensive words from my first 
draft.

John will present in a moment and we can take it from there.

A
----- Original Message ----- 
From: "Drake, John E" <[email-masked]>
To: <[email-masked]>; "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 19, 2008 6:53 PM
Subject: RE: [Mpls-interop] MPLS-TP Ring Protection

Huub,

Thanks,

John