Subject: [PWE3] Bandwidth Resources Unavailable

From: Stewart Bryant <[email-masked]>
Date: Fri, 28 Mar 2008 19:50:36 +0000

Moran, David,

In the draft-ietf-pwe3-fc-encap you say

6.1.2. Data Sender Protocol 
                  
In case the transmission rate is equal to CIR for a period greater
than RTT, and transmitted frames are still lost in transit, as
indicated to the sender by receiving SREJ frames, the sender SHOULD
signal PW status of ìBandwidth resources unavailableî (refer to IANA
registry of STATUS CODE NAME SPACE) as specified in [RFC4447], and
SHOULD shut the PW down for a duration of at least R_A_TOV, as
described in Section 6.5 of [RFC3985].

I note that you are talking about a PW status here.

but you have been asking about sharing a status code point with
draft-ietf-pwe3-dynamic-ms-pw-06.

However this draft says

   In the case where PSN resources towards the previous hop are not
   available the following procedure MUST be followed:

      -iii. If the S-PE cannot get enough resources to setup the segment
            in the MS-PW a label release MUST be returned to the
            previous hop with a status message of "Bandwidth resources
            unavailable"

and in its IANA section it says

      11.1. LDP Status Codes

This document uses several new LDP status codes, IANA already
maintains a registry of name "STATUS CODE NAME SPACE" defined by
RFC3036 <http://tools.ietf.org/html/rfc3036>. The following values have 
been pre-allocated:

Range/Value E Description Reference
------------- ----- ---------------------- ---------
0x00000037 0 Bandwidth resources unavailable RFCxxxx
0x00000038 0 Resources Unavailable RFCxxxx
0x00000039 0 AII Unreachable RFCxxxx
0x0000003A 0 PW Loop Detected RFCxxxx

This seems to me to be referring to a MS PW path status rather than a PW
status.

It also seems to me to be heavy wieght to tear down the whole PW when you
run out of PSN bandwidth, rather than simply asking it to be quiet
for the timeout period.

So should which should we be using -

1) a dedicated PW status bit from
Registry Name: Pseudo Wire Status Codes Registry or

2) a new LDP status code or

3) the LDP status code proposed in draft-ietf-pwe3-dynamic-ms-pw-06

and should we be tearing down the whole PW, or simply telling it to be
quiet?

Regards

Stewart

_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: "Moran Roth" <[email-masked]>
Date: Fri, 28 Mar 2008 14:56:43 -0700

Stewart,

The draft states that in case of severe congestion the PW should be teardown for a duration of at least R_A_TOV. It also should indicate insufficient bandwidth.
My intention is to use the same status code proposed in draft-ietf-pwe3-dynamic-ms-pw-06, however in MS-PW this indication is used during setup, and in FC-PW to indicate a failure after the PW is up and running.
I would be happy to here more opinions on whether this is allowed or we should define a new PW status to indicate insufficient bandwidth for PW operation.

Best Regards,
Moran

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Friday, March 28, 2008 12:51 PM
To: Moran Roth; [email-masked]
Cc: pwe3; Luca Martini (lmartini); Danny McPherson
Subject: Bandwidth Resources Unavailable

Moran, David,

                  
In case the transmission rate is equal to CIR for a period greater than RTT, and transmitted frames are still lost in transit, as indicated to the sender by receiving SREJ frames, the sender SHOULD signal PW status of ìBandwidth resources unavailableî (refer to IANA registry of STATUS CODE NAME SPACE) as specified in [RFC4447], and SHOULD shut the PW down for a duration of at least R_A_TOV, as described in Section 6.5 of [RFC3985].

but you have been asking about sharing a status code point with draft-ietf-pwe3-dynamic-ms-pw-06.

However this draft says

      11.1. LDP Status Codes

This document uses several new LDP status codes, IANA already maintains a registry of name "STATUS CODE NAME SPACE" defined by
RFC3036 <http://tools.ietf.org/html/rfc3036>. The following values have been pre-allocated:

This seems to me to be referring to a MS PW path status rather than a PW status.

It also seems to me to be heavy wieght to tear down the whole PW when you run out of PSN bandwidth, rather than simply asking it to be quiet for the timeout period.

and should we be tearing down the whole PW, or simply telling it to be quiet?

Regards

Stewart

---

From: [email-masked]
Date: Fri, 28 Mar 2008 20:19:33 -0400

Stuart,

There are two concerns in here:

(A) What type of status code?

> In case the transmission rate is equal to CIR for a period 
> greater than RTT, and transmitted frames are still lost in 
> transit, as indicated to the sender by receiving SREJ frames, 
> the sender SHOULD signal PW status of ìBandwidth resources 
> unavailableî (refer to IANA registry of STATUS CODE NAME 
> SPACE) as specified in [RFC4447], and SHOULD shut the PW down 
> for a duration of at least R_A_TOV, as described in Section 
> 6.5 of [RFC3985].
> 

Actually, it's not.  It's supposed to be an LDP status code for
the PW, cf. RFC 4447, Section 7.2.  The full name of the IANA
Registry is:
 	Status Code Name Spaces
which is one of the registries for:
	Label Distribution Protocol (LDP) Name Spaces

This is at http://www.iana.org/assignments/ldp-namespaces, but
the URL does not belong in the draft.

> with draft-ietf-pwe3-dynamic-ms-pw-06.

[... Large Snip ...]

> This seems to me to be referring to a MS PW path status 

Not exactly.  The dynamic-ms-pw draft has defined an LDP
status code:

that appears to be useful for the FC pseudo-wire in general,
not just when the FC pseudo-wire is a multi-segment pseudo-wire,
hence the attempt to reuse it, which seems to have caused
confusion.

The good news here is that in contrast to pseudo-wire status
codes, LDP status codes are not a scarce resource.  Given the
confusion that's been caused in trying to reuse that status code,
let's just define a new one (3B is the next value available):

    0x0000003B     0     Unable to maintain minimum transmission rate   RFCxxxx

That should be clearer, and removes the interaction between this
draft and the dynamic-ms-pw draft.  Does that make sense?

When Moran writes "PW status" in his email below, what he means
is an LDP status code for the PW.

(B) Reaction to running out of bandwdith:

> It also seems to me to be heavy weight to tear down the whole 
> PW when you run out of PSN bandwidth, rather than simply 
> asking it to be quiet for the timeout period.

This may need a better explanation in the draft because the situation
involves more than running out of PSN bandwidth.  The intended use of
CIR is that the PSN is provisioned so that bandwidth sufficient to
support sending at CIR is always available to the FC PW.  If the FC PW
detects that it cannot sustain that rate (it's transmitting at CIR and
seeing drops, implying congestion), something is seriously wrong because
the provisioning assumption has been violated (e.g., provisioning
didn't anticipate a backhoe event at *that* location).  If this
situation is sustained, the FC PW needs to come down because
continuing to transmit at CIR risks damage to the network.

What the draft currently says is that when CIR can't be maintained, the
PW is torn down for a timeout (R_A_TOV, usually 10 seconds), and then
set back up.  If the PW goes down again within the same timeout for
inability to maintain CIR, the PW stays down.  At the PW level, it's
probably more efficient to have the PW go silent the first time, but
the second time around the PW needs to be torn down so that the logical
FC link that is using it is taken down and FC reacts accordingly.  I
think an FC inter-switch link will usually ride through an R_A_TOV
outage, as it takes over 80 seconds of non-responsiveness for FC to
take it down, but the non-responsiveness will probably cause some FC
errors.

> 3) the LDP status code proposed in draft-ietf-pwe3-dynamic-ms-pw-06

Let's use a new LDP status code for simplicity.

> and should we be tearing down the whole PW, or simply telling 

It should go quiet for the first R_A_TOV timeout, but if it fails to
maintain CIR within that timeout after restarting, it needs to be
torn down.

While I'm thinking about it, let me go check with some FC experts
about whether R_A_TOV is the right timeout for this purpose.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> From: Moran Roth [mailto:[email-masked]] 
> Sent: Friday, March 28, 2008 5:57 PM
> To: [email-masked]; Black, David
> Subject: RE: Bandwidth Resources Unavailable
> 
> Stewart,
> 
> The draft states that in case of severe congestion the PW 
> should be teardown for a duration of at least R_A_TOV. It 
> also should indicate insufficient bandwidth.
> My intention is to use the same status code proposed in 
> draft-ietf-pwe3-dynamic-ms-pw-06, however in MS-PW this 
> indication is used during setup, and in FC-PW to indicate a 
> failure after the PW is up and running.
> I would be happy to here more opinions on whether this is 
> allowed or we should define a new PW status to indicate 
> insufficient bandwidth for PW operation.
> 
> Best Regards,
> Moran
> 
> In case the transmission rate is equal to CIR for a period 
> greater than RTT, and transmitted frames are still lost in 
> transit, as indicated to the sender by receiving SREJ frames, 
> the sender SHOULD signal PW status of ìBandwidth resources 
> unavailableî (refer to IANA registry of STATUS CODE NAME 
> SPACE) as specified in [RFC4447], and SHOULD shut the PW down 
> for a duration of at least R_A_TOV, as described in Section 
> 6.5 of [RFC3985].
> 
> It also seems to me to be heavy wieght to tear down the whole 
> PW when you run out of PSN bandwidth, rather than simply 
> asking it to be quiet for the timeout period.
>

---

From: Stewart Bryant <[email-masked]>
Date: Sat, 29 Mar 2008 00:30:33 +0000

David

Thanks for the clarifications - I think that they need to go in the 
draft to clarify things.

R_A_TOV is still a number pulled out of a hat - I could not see
the definition in the draft, but whatever number you use you
really need to define the name and either use or point to the
rational for its value.

> draft and the dynamic-ms-pw draft.  Does that make sense?
I agree
> Let's use a new LDP status code for simplicity.
OK - we will do that.
> maintain CIR within that timeout after restarting, it needs to be
OK
> about whether R_A_TOV is the right timeout for this purpose.
Let us know what you come up with, but the fact that you need to look 
into it
suggests that some explanatory material is needed in the draft.

Stewart

---

From: [email-masked]
Date: Fri, 28 Mar 2008 20:34:29 -0400

> really need to define the name and either use or point to the

Indeed it is - I pulled it out of my hat.  One of my last call
comments was that the FC standard that defines it needs to be cited,
and I'm about to go double-check the reasoning behind R_A_TOV with
FC experts, and will supply the result and explanation to Moran
for inclusion in the draft.

Thanks,
--David

> Sent: Friday, March 28, 2008 8:31 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: Bandwidth Resources Unavailable
> 
> David
>