Subject: [Teas] WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04

From: Lou Berger <[email-masked]>
Date: Fri, 16 Jun 2017 11:31:17 -0400

All,
This starts a two-week working group last call on
draft-ietf-teas-rsvp-te-scaling-rec-04

The working group last call ends on June 30.
Please send your comments to the teas mailing list.

Positive comments, e.g., "I've reviewed this document and
believe it is ready for publication", are welcome!
This is useful and important, even from authors.

NOTE: IPR has been disclosed on this document

Thank you,
TEAS Chairs

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 16 Jun 2017 11:35:20 -0400

I've reviewed (as a co-author) the current version of the document and I do
believe the document is ready for publication.

Regards,
-Pavan

On Fri, Jun 16, 2017 at 11:31 AM, Lou Berger <[email-masked]> wrote:

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 19 Jun 2017 21:31:05 +0100

Hi Lou, 

I previously did a review of this document and the authors made some
edits to address my comments.

It's good work and we should push out an RFC, but I still have a few
comments.

Thanks,
Adrian

---

The Abstract is too polite! It makes "recommendations" and "advocates"
doing stuff.  But it is a Standards Track document and uses RFC 2119
"MUST". 

I think you should try to come down on one side of the fence or the
other :-) 

To further that point, Section 2.2 "proposes" stuff, but I think that a
Standards track RFC would be less flabby.

---

2.1.1 starts with 

   o  SHOULD indicate support for RSVP Refresh Overhead Reduction
      extensions (as specified in Section 2 of [RFC2961]) by default,
      with the ability to override the default via configuration.

This hides something because the mechanisms in 2.2 do not require full
implementation of 2961 (actually, I think you could run 2.2 without 
using 2961 at all). But (obviously?) you can't say you support 2961
unless you do support 2961. And manual configuration doesn't help here
if 2961 is not implemented.

You go on in 2.1.1 to state two required features of 2961 that
implementations must support, but do not call out full support for
2961.

So either:
- you should make support of all of 2961 a requirement (consistent with
  saying implementations say they support it)
or:
- you introduce a new capability switch for a specific sub-set of 2961
  function so that implementations will not be lying.

---

2.1.2 seeks to make the Ack response mandatory. I think I see the value 
of this from a stability/predictability point of view, but I wonder if
you mean exactly what the text implies.  In the context of scaling, 
isn't a good thing that acknowledgement is aggregated?  That is, that
one Ack can acknowledge multiple Message-Ids.

So while the text intends to say, I think, "no Message-id with 
ACK-Desired flag set should go unacknowledged," it appears to suggest
a one-for-one acknowledgement.  Do you want to clarify that or is it
actually what you wanted to say?

---

2.1.3 refers to "Tear/Err messages". I think it would be helpful to be
fully explicit by naming the messages. This will help the reader
understand (for example) whether a Notify message counts.

There is similar text in 2.1.1, but the context makes it clear.

---

In 2.1.3 I don't think you have fully clarified the situation. I think 
there are five types of Path message:
- establishing a new LSP
- making a modification to an LSP that changes significant qualities of
  the LSP and where failure to make the change would harm the intended
  service provided by the LSP
- making a modification to an LSP that changes significant qualities of
  the LSP and where failure to make the change would not harm the intended
  service provided by the LSP (e.g., a reduction in reserved bandwidth),
  but might harm usability of the network
- making a modification to an LSP that may be administratively or
  operationally useful, but which does not change the service offered nor
  the usability of the network
- state refresh

I think these indicate different behaviors by the transmitting node.

You go on to say:
   If it is the
   retransmission of Path/Resv messages and Rl has been reached, then
   the router starts periodic retransmission of these messages.
I think you were already transmitting periodically. So perhaps...
   If it is the
   retransmission of Path/Resv messages and Rl has been reached, then
   the router starts periodic retransmission of these messages on a 
   slower timer.
And when you say:
   The
   configurable periodic retransmission interval SHOULD be less than the
   regular refresh interval.  A default periodic retransmission interval
   of 30 seconds is RECOMMENDED by this document.
It might read better as...
   The
   configurable retransmission interval for this slower timer SHOULD be
   less than the regular refresh interval.  A default retransmission 
   interval for this slower timer of 30 seconds is RECOMMENDED by this
   document.

Lastly in this section, I am concerned by what happens when a refresh
timer pops while you are still retransmitting. You have...
   The
   configurable retransmission interval for this slower timer SHOULD be
   less than the regular refresh interval.
...and...
   This periodic retransmission SHOULD continue until an
   appropriate MESSAGE_ID ACK object is received indicating
   acknowledgement of the (retransmitted) Path/Resv message.
These mean that you could run into a refresh while still retransmitting.
You need to be explicit about what happens then.

---

In what way is a configurable refresh interval with a "default value of
20 minutes" actually "Refresh-interval independent"? 

I wonder whether you want to change the name? Perhaps that you are
defining "Extended refresh-interval" or something?

---

The Figure in 2.2.1 is a problem. But fortunately it is also an 
unnecessary picture.

The issue is that IANA is requested to assign *a* bit to indicate RI
capability. But IANA will decide that. Your figure forces the issue while
Section 5.1 leave it open.

You should just mention "bit number TBA1" and update 5.1 to use "TBA1".

---

2.2.1

   Any node that sets the new I-bit in its CAPABILITY object MUST also
   set Refresh-Reduction-Capable bit in common header of all RSVP-TE
   messages.

As previously noted, I don't see why there is this dependency. But
assuming it remains, you need to write how a receiver handles the case
where there is a mismatch.

---

2.2.2.  Compatibility

   The RI-RSVP functionality MUST be activated only between peers that
   indicate their support for this functionality.

I think this would read better using "MUST NOT".
But it did make me think...
The refresh timer is negotiated between peers according to local 
config. So setting this capability is not necessary.
That leave the I bit indicating only the use of the Node-ID Hello
per 4558. But a node is free to use Node-ID Hellos without prior
negotiation.
So what, exactly, does the I bit control? and how would an 
implementation not do RI-RSVP?

---

2.3
      MUST use lack of ACKs from a peer as an indication of peer's RSVP-
      TE control plane congestion.

Erm, there are other possible reasons, you know.

It is true that the Hellos indicate that the control plane connection is
probably still up, but if you really believed that you wouldn't even 
bother with retransmission and message Acks. 

So what about the case where Path messages are not getting delivered?
The messages may be being dropped because (for example) they are too 
large for some piece of the control plane path.

What about the case where Acks are getting deliberately squashed (or
corrupted) by an attacker?

---

2.3.1
  Ditto the F bit. No need for a figure. Use TBA2.

---

Section 6. As noted for 2.3, by changing the behavior of normal
processing (for example, prioritising Tear over setup) when congestion
is flagged, you open a way to change behavior in a subtle, less 
detectable way than already exists.

You should think about this type of attack more, and write about it.

===

Nits.

---

Section headings should be capitalized.

> -----Original Message-----
> From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: 16 June 2017 16:31
> To: TEAS WG
> Cc: [email-masked]
> Subject: [Teas] WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04
> 
> All,

---

From: Harish Sitaraman <[email-masked]>
Date: Tue, 20 Jun 2017 03:20:50 +0000

I've reviewed the document and think it's ready for publication.

Harish

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Wed, 21 Jun 2017 13:54:42 -0400

Adrian, Hi!

Much Thanks for the detailed review. Please see inline for responses
(prefixed VPB).

Regards,
-Pavan (on behalf of the authors/contributors)

> Standards track RFC would be less flabby.
[VPB] I don’t see a problem with being polite and assertive at the same
time :).
That said, your point is taken. Does the following text address your
comments?

<text>
The scale at which RSVP-TE Label Switched Paths (LSPs) get deployed is
growing continually and the onus is on RSVP-TE implementations across the
board to keep up with this increasing demand.

This document introduces a couple of techniques - "Refresh-Interval
Independent RSVP (RI-RSVP)" and "Per-Peer Flow-Control" - to help RSVP-TE
deployments push the envelope on scaling.
</text>

>   function so that implementations will not be lying.
[VPB]  I don't see any point in trying to figure out what the minimum
required features from [RFC2961] are. The goal here is to scale as high as
we possibly can -- so we do want all procedures/extensions specified in
[RFC2961] to be used.

"Reliable Message Delivery" and "Exponential back-off for retransmission of
messages awaiting acknowledgements” are necessary pre-requisites for the
techniques discussed in Sections 2.2 and 2.3. The intent in section 2.1.1
is to say that an implementation indicating support for RSVP Refresh
Overhead Reduction extensions (as specified in Section 2 of [RFC2961]) MUST
support reliable delivery of all messages and MUST support retransmission
using exponential back-off. This text was originally added because there is
nothing illegal from an [RFC2961] compliance perspective for an
implementation to set the Refresh-Reduction-Capable bit and not support the
exponential back off procedures.

Would the following text make more sense?

<text>
An implementation that supports either or both of the techniques discussed
in Sections 2.2 and 2.3 MUST support RSVP Refresh Overhead Reduction
Extensions/Procedures [RFC2961]. This MUST specifically include:
  o support for reliable delivery of Path/Resv and the corresponding
Tear/Err messages (as specified in Section 4 of [RFC2961])
  o support for retransmission of all unacknowledged RSVP-TE messages using
exponential-backoff (as specified in Section 6 of [RFC2961])
</text>

---
> actually what you wanted to say?
[VPB] The intent is certainly to say that “no Message-id Ack-Desired Flag”
should go unacknowledged (no intention to send individual ACK messages). I
couldn’t find the text that suggests a one-for-one acknowledgment. All that
the current text is saying is that "nodes receiving a non-out of order
message containing a MESSAGE_ID object with the ACK_Desired flag set, MUST
respond with a MESSAGE_ID_ACK object”. This MESSAGE_ID_ACK object can of
course be packed along with a set of other MESSAGE_ID_ACK objects in a
single ACK message (or in just any other message on which these objects can
be piggy-backed).

> There is similar text in 2.1.1, but the context makes it clear.
[VPB] Would the following address the comment?

<text>
If it is the retransmission of non Path/Resv messages and Rl has been
reached, the router need not take any further actions.
</text>

> I think these indicate different behaviors by the transmitting node.
[VPB] Agree with the classification — but I don’t see its relevance here.
The only thing that matters (in this I-D) is whether the Path or Resv has
changed in any way so that it requires a new message ID and an Ack (trigger
vs refresh).

>    the router starts periodic retransmission of these messages on a

[VPB] Ok. Made the change.

>    interval for this slower timer of 30 seconds is RECOMMENDED by this

[VPB] Ok. Made the change.

> You need to be explicit about what happens then.

[VPB] I don’t understand the concern here. Consider a rudimentary state
machine with the following states (assuming the defaults suggested in the
Appendix of the draft):
- first retransmit (exponential back off)
- second retransmit (exponential back off)
...
- seventh retransmit (exponential back off)
- 30s retransmission
- 20m refresh (regular refresh timer)

At any point when the Ack is received, you transition to the 20m refresh
state. Does this address your concern?

> defining "Extended refresh-interval" or something?

[VPB] The procedures outlined in this section 2.2 make RSVP not be reliant
on the refresh-interval in any of its procedures/features. Hence the name
-- Refresh-Interval Independent RSVP. Appendix A provides some context for
the recommended default.

"Given that an implementation supporting RI-RSVP doesn't rely on refreshes
for state sync between peers, the RSVP refresh interval is sort of
analogous to IGP refresh interval, the default of which is typically in the
order of 10s of minutes.  Choosing a default of 20 minutes allows the
refresh timer to be randomly set to a value in the range [10 minutes
(0.5R), 30 minutes (1.5R)]”.

> You should just mention "bit number TBA1" and update 5.1 to use "TBA1".
[VPB] Agree. Made the change.

> where there is a mismatch.
[VPB] As stated earlier, “Reliable Message Delivery” is a pre-requisite for
the RI-RSVP functionality. Would the following text address your comment?

<text>
Any node that sets the new I-bit in its CAPABILITY object MUST also set
Refresh-Reduction-Capable bit in common header of all RSVP-TE messages. If
a peer sets the I-bit in the CAPABILITY object but does not set the
Refresh-Reduction-Capable bit, then the RI-RSVP functionality MUST not be
activated for that peer.
</text>

> implementation not do RI-RSVP?
[VPB] Just signaling a large refresh-timer doesn’t make a node RI-RSVP
capable. For a node to claim that it supports RI-RSVP, it MUST support all
functions listed in Section 2.2 (support pre-requisites in 2.1, use large
refresh interval — not rely on refresh-interval to cleanup state, couple
the state of individual LSPs with the state of the corresponding RSVP-TE
signaling adjacency, use node-id based hellos for detecting signaling
adjacency failures). An implementation does not do RI-RSVP if it doesn’t
support all of these functions.

Coming back to your comment on using “MUST NOT”, does the following text
read better?
<text>
The RI-RSVP functionality MUST NOT be activated with a peer that does not
indicate support for this functionality.
</text>

---

> corrupted) by an attacker?
[VPB] The “Per-Peer Flow-Control” functionality is turned ON only if both
peers have indicated support for it. If a peer has indicated support for it
and is not sending ACKs, then it is because of either a “faulty
implementation” or an “unauthorized agent in the network”. The worst thing
that can happen as a result of this is that the affected peers would become
sluggish and start sending messages slowly (scalability wouldn't be at a
desired level). After a given point, someone would have to intervene and
take corrective measures (disable “Per-Peer Flow-Control” functionality on
the affected peers; eliminate the faulty/unauthorized entities from the
network).

---
>   Ditto the F bit. No need for a figure. Use TBA2.
[VPB] Agree. Made the changes.

> You should think about this type of attack more, and write about it.
[VPB] The change in behavior is very subtle (expected between peers that
indicate support for this) -- not sure if this needs to be classified as a
"security concern". That said, does the text above (response to the
comments on 2.3) address your concern?

> Section headings should be capitalized.
[VPB] Made the changes.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 22 Jun 2017 11:37:32 +0100

Hi Pavan,

Thanks for the speedy and detailed response.

>> Abstract
>
> The scale at which RSVP-TE Label Switched Paths (LSPs) get deployed is growing continually
> and the onus is on RSVP-TE implementations across the board to keep up with this increasing
> demand.
>
> This document introduces a couple of techniques - "Refresh-Interval Independent RSVP
> (RI-RSVP)" and "Per-Peer Flow-Control" - to help RSVP-TE deployments push the envelope
> on scaling.

Perfect.

>>      with the ability to override the default via configuration.
[snip]
>  I don't see any point in trying to figure out what the minimum required 
> features from [RFC2961] are. The goal here is to scale as high as we possibly
> can -- so we do want all procedures/extensions specified in [RFC2961] to be
> used.

Right. I can see the value in that.
But that is not what you are writing here. You are writing that to in order to support the procedures you are defining here, an implementation SHOULD support all of 2961.
I believe that this is not true. While it is clear that the best scaling will be achieved by using 2961 and the mechanisms defined in your document, the dependency is not so strong.
For example, SRefresh may improve scaling, but you don't rely on it or even mention it.

The flag that indicates "support of 2961" has always been a little vague, IMHO. In many cases it is assumed to mean, "Can receive 2961 messages, but will not generate them." I think you also see this problem as mentioned in your paragraph below.

I believe you are actually increasing this confusion, and I suggest you need to do several things:

1. Strongly recommend the use of 2961 procedures to improve scaling
2. Mandate passive support of 2961
3. Require that implementations indicate support for 2961 if (and only if) they support it
4. Indicate (as, for example, in your suggested new text) which features of 2961 are needed to enable the mechanisms defined in your document
5. Consider whether it is helpful to indicate support for the mechanisms defined in your document and if so, define a new capabilities flag.

> "Reliable Message Delivery" and "Exponential back-off for retransmission of messages
>  awaiting acknowledgements” are necessary pre-requisites for the techniques discussed
> in Sections 2.2 and 2.3. The intent in section 2.1.1 is to say that an implementation
> indicating support for RSVP Refresh Overhead Reduction extensions (as specified in
> Section 2 of [RFC2961]) MUST support reliable delivery of all messages and MUST support
> retransmission using exponential back-off. This text was originally added because there is
> nothing illegal from an [RFC2961] compliance perspective for an implementation to set the
> Refresh-Reduction-Capable bit and not support the exponential back off procedures. 
>
> An implementation that supports either or both of the techniques discussed in Sections
> 2.2 and 2.3 MUST support RSVP Refresh Overhead Reduction Extensions/Procedures
> [RFC2961]. This MUST specifically include:
>  o support for reliable delivery of Path/Resv and the corresponding Tear/Err messages
>    (as specified in Section 4 of [RFC2961])
>  o support for retransmission of all unacknowledged RSVP-TE messages using exponential-
>    backoff (as specified in Section 6 of [RFC2961])
> </text> 

> [VPB] The intent is certainly to say that “no Message-id Ack-Desired Flag” should
> go unacknowledged (no intention to send individual ACK messages). I couldn’t 
> find the text that suggests a one-for-one acknowledgment. All that the current
> text is saying is that "nodes receiving a non-out of order message containing a 
> MESSAGE_ID object with the ACK_Desired flag set, MUST respond with a
> MESSAGE_ID_ACK object”. This MESSAGE_ID_ACK object can of course be
> packed along with a set of other MESSAGE_ID_ACK objects in a single ACK 
> message (or in just any other message on which these objects can be piggy-
> backed).
 
Right. So it is just the inflection.
When you write "when you receive a non-out of order message containing a MESSAGE_ID object with the ACK_Desired flag set, MUST respond with a MESSAGE_ID_ACK object" thee *tone* is "MUST respond now". Adding your additional sentence would cover this...

"This MESSAGE_ID_ACK object can of course be packed along with a set of other MESSAGE_ID_ACK objects in a single ACK message (or in just any other message on which these objects can be piggy-backed)."

> If it is the retransmission of non Path/Resv messages and Rl has been reached, the router
> need not take any further actions.
> </text>
 
Yes, although, because I am not German, I prefer to avoid complex nouns.
Maybe 
If Rl has been reached for the retransmission of a message that is neither a Path nor a Resv message, then the router need not take any further action.

>> there are five types of Path message:
[snip]
> Agree with the classification — but I don’t see its relevance here. The 
> only thing that matters (in this I-D) is whether the Path or Resv has 
> changed in any way so that it requires a new message ID and an Ack
> (trigger vs refresh). 

Exactly.
And I think I didn't see that point made.

>[VPB] I don’t understand the concern here. Consider a rudimentary state machine
> with the following states (assuming the defaults suggested in the Appendix of the draft):

Thinking about this more, a "reasonable" implementation might decide to not run two timers on the same state. Thus the problem would not arrise. 

> The procedures outlined in this section 2.2 make RSVP not be reliant on the refresh-interval
> in any of its procedures/features. Hence the name -- Refresh-Interval Independent RSVP. 
> Appendix A provides some context for the recommended default.
>
> "Given that an implementation supporting RI-RSVP doesn't rely on refreshes for state
> sync between peers, the RSVP refresh interval is sort of analogous to IGP refresh interval,
> the default of which is typically in the order of 10s of minutes.  Choosing a default of 20 
> minutes allows the refresh timer to be randomly set to a value in the range [10 minutes

I am not picking at the default value. 
But I disagree that you have made "RSVP not be reliant on the refresh-interval in any of its procedures/features." If that was true, you would have completely scrapped the refresh. You decided to keep it (with a default value that is small compared to a hold time of years) and so you are not "independent".
 
But this is probably not an important discussion.

[snip]
> Would the following text address your comment?
>
> Any node that sets the new I-bit in its CAPABILITY object MUST also set Refresh-Reduction-Capable
> bit in common header of all RSVP-TE messages. If a peer sets the I-bit in the CAPABILITY object but
> does not set the Refresh-Reduction-Capable bit, then the RI-RSVP functionality MUST not be activated
> for that peer.

wfm
 
>> 2.2.2
[snip]
> The RI-RSVP functionality MUST NOT be activated with a peer that does not indicate
> support for this functionality.

wfm

>>      TE control plane congestion.
[snip]
> The “Per-Peer Flow-Control” functionality is turned ON only if both peers have indicated support
> for it. If a peer has indicated support for it and is not sending ACKs, then it is because of either a 
> “faulty implementation” or an “unauthorized agent in the network”. The worst thing that can
> happen as a result of this is that the affected peers would become sluggish and start sending 
> messages slowly (scalability wouldn't be at a desired level). After a given point, someone would
> have to intervene and take corrective measures (disable “Per-Peer Flow-Control” functionality
> on the affected peers; eliminate the faulty/unauthorized entities from the network). 

My point is not that procedures are broken. My point is that the text is incorrect.
Lack of ACKs does not necessarily mean that the peer's control plane is congested.

I think you should have something like...
If a peer's RSVP-TE control plane becomes congested, this may manifest as a lack of ACKs for messages sent to the peer. If the procedures described in this section are enabled, an implementation SHOULD treat any lack of ACKs in the same way as though caused by congestion at the peer.

>> Section 6

I'll leave the discussion to be picked up by the SecDir reviewers.

---

From: Sudharsana Venkataraman <[email-masked]>
Date: Thu, 22 Jun 2017 13:01:41 +0000

Support the work. This should progress to the next step in the publication process

Regards,
Sudha
    >    
    >    
    >    On 6/16/17, 11:31 AM, "Lou Berger" <[email-masked]> wrote:
    >    
    >    >All,

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Sat, 24 Jun 2017 06:49:27 -0400

Adrian, Hi!

Thanks! Please see inline.

Regards,
-Pavan

Snipped.. (retaining only the items that needed a response)

On Thu, Jun 22, 2017 at 6:37 AM, Adrian Farrel <[email-masked]> wrote:

> But that is not what you are writing here. You are writing that to in
> order to support the procedures you are defining here, an implementation
> SHOULD support all of 2961.
> I believe that this is not true. While it is clear that the best scaling
> will be achieved by using 2961 and the mechanisms defined in your document,
> the dependency is not so strong.
> The flag that indicates "support of 2961" has always been a little vague,
> IMHO. In many cases it is assumed to mean, "Can receive 2961 messages, but
> will not generate them." I think you also see this problem as mentioned in
> your paragraph below.
>
> 4. Indicate (as, for example, in your suggested new text) which features
> of 2961 are needed to enable the mechanisms defined in your document
>

[Pavan] I think we are in strong agreement on what the text needs to imply.
Can you please advise how we can specify the above (especially the "mandate
passive support" part) using RFC2119 language?

> 5. Consider whether it is helpful to indicate support for the mechanisms
> defined in your document and if so, define a new capabilities flag.
>

[Pavan] I don't think we need an additional capability flag for this. The
presence of the F Bit (Per-Peer Flow-Control) or the I Bit (RI-RSVP) should
be enough to indicate that all RFC2961 mechanisms of interest are supported.

Snipped..

> When you write "when you receive a non-out of order message containing a
> MESSAGE_ID_ACK object" thee *tone* is "MUST respond now". Adding your
> additional sentence would cover this...
>
> "This MESSAGE_ID_ACK object can of course be packed along with a set of
> other MESSAGE_ID_ACK objects in a single ACK message (or in just any other
> message on which these objects can be piggy-backed)."
>

[Pavan] Will add the additional sentence to make it clear.

> If Rl has been reached for the retransmission of a message that is neither
> a Path nor a Resv message, then the router need not take any further action.
>

[Pavan] Will rephrase the statement for clarity (as suggested).

Snipped...

> If a peer's RSVP-TE control plane becomes congested, this may manifest as
> a lack of ACKs for messages sent to the peer. If the procedures described
> in this section are enabled, an implementation SHOULD treat any lack of
> ACKs in the same way as though caused by congestion at the peer.
>
>
[Pavan] Will edit the text (as suggested).

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 27 Jun 2017 22:43:21 -0400

A new revision addressing the comments/nits that have been raised so far is
ready. This will be submitted at the end of the last call. You can take a
peek at the diffs here -
https://drive.google.com/file/d/0B5qbViWSXJ2CVzNkUlR6ci1INHM/view?usp=sharing

Regards,
-Pavan

On Sat, Jun 24, 2017 at 6:49 AM, Vishnu Pavan Beeram <[email-masked]>
wrote:

> [Pavan] I think we are in strong agreement on what the text needs to
> imply. Can you please advise how we can specify the above (especially the
> "mandate passive support" part) using RFC2119 language?
>
>
>> If Rl has been reached for the retransmission of a message that is
>> neither a Path nor a Resv message, then the router need not take any
>> further action.
>>
>

---

From: Markus Jork <[email-masked]>
Date: Wed, 28 Jun 2017 14:27:41 +0000

As a contributor, I support this document and believe it is ready for publication.
This believe is bolstered by the fact that I worked on implementing all the key mechanisms in this draft and that the implementation is already shipping.

-Markus

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Friday, June 16, 2017 11:31 AM
To: TEAS WG <[email-masked]>
Cc: [email-masked]
Subject: [Teas] WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04

All,

Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Thank you,
TEAS Chairs

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 29 Jun 2017 00:37:33 +0100

[snip]
>> But that is not what you are writing here. You are writing that to in order to support
>> the procedures you are defining here, an implementation SHOULD support all of 2961.
>> I believe that this is not true. While it is clear that the best scaling will be achieved by
>> using 2961 and the mechanisms defined in your document, the dependency is not 
>> so strong. For example, SRefresh may improve scaling, but you don't rely on it or even
>> mention it.
>>
>> The flag that indicates "support of 2961" has always been a little vague, IMHO. In many
>> cases it is assumed to mean, "Can receive 2961 messages, but will not generate them."
>> I think you also see this problem as mentioned in your paragraph below.
>>
>> 4. Indicate (as, for example, in your suggested new text) which features of 2961 are
>>    needed to enable the mechanisms defined in your document
>
> [Pavan] I think we are in strong agreement on what the text needs to imply. Can you
> please advise how we can specify the above (especially the "mandate passive support"
> part) using RFC2119 language?

How about...
OLD
2.1.1.  Basic Pre-Requisites

   An implementation that supports either or both of the techniques
   discussed in Sections 2.2 and 2.3:

   o  MUST support reliable delivery of Path/Resv and the corresponding
      Tear/Err messages using the procedures specified in [RFC2961].

   o  MUST support retransmit of all RSVP-TE messages using exponential-
      backoff, as specified in Section 6 of [RFC2961].
NEW
2.1.1.  Basic Prerequisites

   An implementation that supports any of the procedures described in 
   this document must meet certain basic prerequisites.

   o  It MUST indicate support for RSVP Refresh Overhead Reduction
      extensions (as specified in Section 2 of [RFC2961]).

   o  It MUST support receipt of any RSVP Refresh Overhead Reduction
      message as defined in [RFC2961].

   o  It SHOULD initiate all RSVP Refresh Overhead Reduction mechanisms
      as defined in [RFC2961] (including the SRefresh message) with the
      default behavior being to initiate the mechanisms but offering a
      configuration override.

   o  It MUST support reliable delivery of Path/Resv and the
      corresponding Tear/Err messages using the procedures specified in
      [RFC2961].

   o  It MUST support retransmit of all RSVP-TE messages using 
      exponential-backoff, as specified in Section 6 of [RFC2961].
END

And then we're done!

Thanks for your patience!

Adrian

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Wed, 28 Jun 2017 23:09:34 -0400

Adrian, Hi!

On Wed, Jun 28, 2017 at 7:37 PM, Adrian Farrel <[email-masked]> wrote:

> imply. Can you
Thanks! This looks good. I've made the suggested edits. The diffs are
available at:
https://drive.google.com/file/d/0B5qbViWSXJ2CVzNkUlR6ci1INHM/view?usp=sharing

I'll upload the new version as soon the LC is complete.

Regards,
-Pavan