Subject: [Mpls-interop] Requirements Section 2.8

From: "Drake, John E" <[email-masked]>
Date: Thu, 16 Oct 2008 15:05:35 -0700

1)  All SHOULDs will be changed to MUSTs (the MPLS TP technology MUST,
as opposed to what a vendor decides to build or an SP decides to deploy)

2)  Lou Berger will make the terminology consistent with RFC 4427

3)  Current text:

"*  Restoration priority MAY be implemented to determine the order
         in which transport paths should be restored (to minimize
         service restoration time as well as to gain access to available
         spare capacity on the best paths).  Preemption priority MAY be
         used in the event that not all transport paths can be restored,
         in which case transport paths with lower preemption priority
         should be released.  When preemption is supported, its use MUST
         be operator configurable."

Proposed text:

"*  Restoration priority MUST be implemented to determine the order
         in which transport paths should be restored (to minimize
         service restoration time as well as to gain access to available
         spare capacity on the best paths).  Preemption priority MUST be
         used in the event that not all transport paths can be restored,
         in which case transport paths with lower preemption priority
         should be released."

Current text:

"*  MPLS-TP MAY support mechanisms that are optimized for specific
         network topologies (Ring, Mesh) in order to handle protection
         switching in an efficient manner.

      *  If optimised mechanisms for ring topologies are supported then
         they MUST:

         +  Support switching times within 50 ms (depending on CV rate
            configuration) assuming a reference network of a 16 node
            ring with less than 1200 Km of fiber.

         +  Support the sharing of ring protection bandwidth, both

            A.  When protection switching is not activated, by allowing
                the allocation of "best effort" traffic along the ring,
                depending on the ring protection bandwidth availability.

            B.  When protection switching is active. by allowing all of
                the connections configured to access the ring protection
                bandwidth, according to the priority logic defined for
                coexisting switching events.

         +  Support inter-ring connectivity, in cases where:

            A.  The rings are connected at a single node and no links
                are shared between the rings.

            B.  The rings are connected at two nodes and the connecting
                link is shared by the rings"

Proposed text:

"*  MPLS-TP MAY support mechanisms that are optimized for specific
	network topologies (e.g., ring). 

 *  These mechanisms must be interoperable with the mechanisms defined
for          	mesh (arbitrary topology) networks

 *  If optimised mechanisms for ring topologies are supported then
	they MUST:

	+  Support switching times within 50 ms (depending on CV rate
	   configuration) assuming a reference network of a 16 node
	   ring with less than 1200 Km of fiber."

John Drake
Boeing Satellite Systems
2260 East Imperial Highway MC W-S10-S545
El Segundo, CA 90245
[email-masked]
(412) 370-3108
_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 17 Oct 2008 00:40:31 +0100

Can the others that took notes, documented actions etc. send them to me and
I will edit up draft-jenkins and push out a new version next week.

Thanks
Ben

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 17 Oct 2008 05:54:15 +0200

John,

I think there are more specific requirements for optimised mechanisms
for ring topologies in addition to the reference network and the 50ms
switching time.

Given the current status of the discussion, I think we just need to
track this as an open issue for this draft.

Italo 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Drake, John E
> Sent: Thursday, October 16, 2008 6:06 PM
> To: [email-masked]
> Subject: [Mpls-interop] Requirements Section 2.8
>

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Mon, 20 Oct 2008 17:33:56 -0400

I'm not sure when it was discussed to change item (3) below? The current
text was based on 4426 (and at least one operator's preference;-) This
is from 4426:
"In the case of end-to-end shared mesh restoration, priorities MAY be
implemented for allocating shared link resources under multiple failure
scenarios.  As described in Section 3.3, more than one LSP can claim
shared resources under multiple failure scenarios.  If such resources
are first allocated to a lower-priority LSP, they MAY have to be
reclaimed and allocated to a higher-priority LSP.

Preemeption is only one of many ways to give higher priority paths
priority e.g. backoff timers are also possible so as to prevent the
churn of preempting. Use of preemeption, reversion to original path, etc
need to be operator configurable as each operator will have their
preference on using.

I prefer the current text for (3) or if changing - a "MUST" for
supporting priority and a "MAY" for supporting preemption.

Deborah  

-----Original Message-----

3)  Current text:

Proposed text:

Current text:

Proposed text:

John Drake
Boeing Satellite Systems

---

From: <[email-masked]>
Date: Tue, 21 Oct 2008 11:31:19 +0200

Hi.

I completely agree with you, Deborah. If we say "be implemented" about
priorities, then it is rather a "MAY". The same for preemption: I'm not
a big fan of it and if there is a requirement, it is not on the way to
implement priorities, so it is definitely a "MAY".

Julien

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of BRUNGARD, DEBORAH A,
ATTLABS

Deborah  

-----Original Message-----

3)  Current text:

Proposed text:

Current text:

Proposed text:

John Drake
Boeing Satellite Systems

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 21 Oct 2008 09:00:12 -0700

Deborah,

We were trying to distinguish between what the MPLS-TP prtocol needs to
support versus what a vendor might build or an SP might deploy.  You
might want to scrub the all of the requirements I-Ds wrt this.

Thanks,

John 

>From: BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
>Sent: Monday, October 20, 2008 2:34 PM
>To: Drake, John E; [email-masked]
>Subject: RE: [Mpls-interop] Requirements Section 2.8
>
>I'm not sure when it was discussed to change item (3) below? 
>The current text was based on 4426 (and at least one 
>operator's preference;-) This is from 4426:
>"In the case of end-to-end shared mesh restoration, priorities 
>MAY be implemented for allocating shared link resources under 
>multiple failure scenarios.  As described in Section 3.3, more 
>than one LSP can claim shared resources under multiple failure 
>scenarios.  If such resources are first allocated to a 
>lower-priority LSP, they MAY have to be reclaimed and 
>allocated to a higher-priority LSP.
>
>Preemeption is only one of many ways to give higher priority 
>paths priority e.g. backoff timers are also possible so as to 
>prevent the churn of preempting. Use of preemeption, reversion 
>to original path, etc need to be operator configurable as each 
>operator will have their preference on using.
>
>I prefer the current text for (3) or if changing - a "MUST" 
>for supporting priority and a "MAY" for supporting preemption.
>
>Deborah  
>
>1)  All SHOULDs will be changed to MUSTs (the MPLS TP 
>technology MUST, as opposed to what a vendor decides to build 
>or an SP decides to deploy)
>
>2260 East Imperial Highway MC W-S10-S545 El Segundo, CA 90245 
>[email-masked]
>(412) 370-3108

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Tue, 21 Oct 2008 12:11:10 -0400

Hi John,

Agree we need to scrub wrt to this, but to prevent confusion (which some
vendors have wrt to the GMPLS RFCs even though it's clear that
preemption needs to be user configurable), I'd prefer to say instead of
"preemption priority MUST be used" then to say "preemption priority MUST
be supported" and also keep the last sentence intact with the paragraph
"Preemption use MUST be operator configurable."

Thanks,
Deborah

-----Original Message-----
From: Drake, John E [mailto:[email-masked]] 
Sent: Tuesday, October 21, 2008 12:00 PM
To: BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
Subject: RE: [Mpls-interop] Requirements Section 2.8

Deborah,

Thanks,

John

---

From: <[email-masked]>
Date: Tue, 21 Oct 2008 18:25:26 +0200

Hello John.

To emphasize Deborah's point, we agreed on wording like "The MPLS-TP
technology MUST support", but your proposed praragraph is saying:
"Restoration priority MUST be implemented", which is not the same...

I also agree on strengthening the "operator configurable" aspect, even
if it states the obvious.

Best regards,

Julien

-----Original Message-----

Hi John,

Thanks,
Deborah

-----Original Message-----

Deborah,

Thanks,

John

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 21 Oct 2008 09:31:41 -0700

That's all fine with me 

>Sent: Tuesday, October 21, 2008 9:11 AM
>Agree we need to scrub wrt to this, but to prevent confusion 
>(which some vendors have wrt to the GMPLS RFCs even though 
>it's clear that preemption needs to be user configurable), I'd 
>prefer to say instead of "preemption priority MUST be used" 
>then to say "preemption priority MUST be supported" and also 
>keep the last sentence intact with the paragraph "Preemption 
>use MUST be operator configurable."
>
>Thanks,
>Deborah
>
>We were trying to distinguish between what the MPLS-TP prtocol 
>needs to support versus what a vendor might build or an SP 
>might deploy.  You might want to scrub the all of the 
>requirements I-Ds wrt this.
>
>Thanks,
>
>John 
>
>>The current text was based on 4426 (and at least one operator's 
>>preference;-) This is from 4426:
>>churn of preempting. Use of preemeption, reversion to original path, 
>>etc need to be operator configurable as each operator will have their 
>>preference on using.
>>
>technology MUST,

---

From: "Igor Umansky" <[email-masked]>
Date: Wed, 22 Oct 2008 17:41:16 +0200

John,

The original version of the text related to "specific network
topologies" is just fine. Could you please explain the rational for
changing it?

Regards,
Igor.

-----Original Message-----
Sent: Friday, October 17, 2008 00:06

3)  Current text:

Proposed text:

Current text:

Proposed text:

John Drake
Boeing Satellite Systems

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 22 Oct 2008 09:54:48 -0700

Igor,

As I recall, it was editorial tweaking by the participants at last
week's meeting.

Thanks,

John   

>From: Igor Umansky [mailto:[email-masked]] 
>Sent: Wednesday, October 22, 2008 8:41 AM
>topologies" is just fine. Could you please explain the 
>rational for changing it?
>
>Regards,
>Igor.
>
>
>
>

---

From: "Igor Umansky" <[email-masked]>
Date: Thu, 23 Oct 2008 08:54:48 +0200

John,

It looks a bit more that just an editorial changes. It would also be
helpful to clarify the meaning of second bullet in the modified text:
"These mechanisms must be interoperable with the mechanisms defined for
mesh (arbitrary topology) networks".

Thanks,
Igor.

-----Original Message-----
From: Drake, John E [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 18:55
To: Igor Umansky; [email-masked]
Subject: RE: [Mpls-interop] Requirements Section 2.8

Igor,

Thanks,

John

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 26 Oct 2008 01:04:49 +0100

I think John took his instructions from the meeting.
Let's not debate why the changes. Let's try to arrive at text we all agree 
with.

You ask
> It would also be

I wonder what it is that lacks clarity here. It is kind of hard to add 
clarity when you don't know what the problem is :-)

This is saying that any protocol features that are developed as 
optimizations for specific network topologies must not give rise to a 
specific implementation variant that cannot participate in other types of 
network, and must not cause protocol elements that would not be understood 
or would be mistreated if they crossed other parts of the network.

Hmmm, I think John's words were clearer than mine :-(

A

---

From: "Igor Umansky" <[email-masked]>
Date: Mon, 27 Oct 2008 09:08:46 +0200

If you are referring to the _protocol_ interoperability, this should be
explicitly mentioned in the requirement. Current text is too vague.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Sunday, October 26, 2008 02:05
To: Igor Umansky; Drake, John E; [email-masked]
Subject: Re: [Mpls-interop] Requirements Section 2.8

I think John took his instructions from the meeting.
Let's not debate why the changes. Let's try to arrive at text we all
agree 
with.

You ask

This is saying that any protocol features that are developed as 
optimizations for specific network topologies must not give rise to a 
specific implementation variant that cannot participate in other types
of 
network, and must not cause protocol elements that would not be
understood 
or would be mistreated if they crossed other parts of the network.

A