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

From: Lou Berger <[email-masked]>
Date: Sat, 1 Jul 2017 09:57:12 -0400

Hi Pavan/Authors,

    Reviewing these diffs (whcih look good to me) made me reread the
whole document and I noticed two things:

1) Doesn't flow control really only work if the RI mechanisms are
implemented?  For example, if refreshes get delayed, state will be
removed.  This is pretty unlikely with RI (and thing 2 should make it
even less so).  I actually thought flow control built on RI, and this
was part of the justification for keeping them in the same document (I'd
need to go find messages to confirm, but that's just past history
anyway).  To address this I propose:

OLD:
   An implementation that supports "Per-Peer RSVP Flow-Control":
   o  MUST support all the recommendations made in Section 2.1

NEW

   An implementation that supports "Per-Peer RSVP Flow-Control":
   o  MUST support all the recommendations made in Section 2.1 and 2.2

If you want to keep FC independent of RI, I think the FC compatibility
section needs to go into (a) how to not break a peer's hello state and
(b) implications of delaying refresh mechanisms and how a flow control
implementation ensures not to break a peer's per-session state. -- Note,
this text is only needed if FC remains independent of RI.

2)  Independent of 1, when flow control is used, Hello messages really
should be prioritized 1st when they need to be sent, you're also missing
ACKs.  How about adding the following *before* the " SHOULD prioritize
Tear/Error ..." bullet.

  o SHOULD prioritize Hello messages and messages carrying
Acknowledgements over other RSVP messages.

That's it,
Lou

On 6/28/2017 11:09 PM, Vishnu Pavan Beeram wrote:
> Adrian, Hi!
>
> On Wed, Jun 28, 2017 at 7:37 PM, Adrian Farrel <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Snipped..
>     >>
>     >> 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
>     >
>     > [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  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.
>
>        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
>
>
> 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
>
>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

---

From: Lou Berger <[email-masked]>
Date: Sat, 1 Jul 2017 10:02:12 -0400

All,

    The WG LC is closed.  Authors please address any comments that have
been received, and let the WG know how the issues were addressed and
when a version is available that is ready to be submitted for publications

Thank you,
Lou
(As Chair)

On 6/16/2017 11:31 AM, Lou Berger wrote:
> 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: Sun, 2 Jul 2017 09:00:28 -0400

Lou, Hi!

Thanks reviewing the diffs. Please see inline (prefixed VPB)

Regards,
-Pavan

>    o  MUST support all the recommendations made in Section 2.1 and 2.2
[VPB] Though it is possible to do FC without RI, I do believe that an
implementation would get the best possible results if both techniques are
employed together in tandem. So yes, 'll go ahead and make the above change.

> Acknowledgements over other RSVP messages.

[VPB] The intent here is to say that the "messages that remove state"
SHOULD have higher priority than the "messages that bring up new LSP
state". The messages that are needed to maintain the existing state are
very important -- but that isn't explicitly stated. With Per-Peer FC now
being made dependent on RI, I agree that there is a strong case to
prioritize the Node-ID based Hello messages (to keep the signaling
adjacency intact). The comment on ACKs also makes sense. I'll submit a new
revision with the suggested changes in place.

---

From: Lou Berger <[email-masked]>
Date: Sun, 02 Jul 2017 09:54:41 -0400

Hi Pavan,

On July 2, 2017 9:01:05 AM Vishnu Pavan Beeram <[email-masked]> wrote:

>> ...

> very important -- but that isn't explicitly stated.

This sounds like a good addition.

>  With Per-Peer FC now

Thanks!

> ----------

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Sun, 2 Jul 2017 14:01:13 +0000

https://datatracker.ietf.org/doc/html/draft-ietf-teas-rsvp-te-scaling-rec-05

We just posted Rev-5. This should address all the comments that were raised during LC.

Regards,
-Pavan

From: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Date: Sunday, July 2, 2017 at 9:00 AM
To: Lou Berger <[email-masked]<mailto:[email-masked]>>
Cc: TEAS WG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] WG Last Call: draft-ietf-teas-rsvp-te-scaling-rec-04
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>, Ina Minei <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent-Date: Sunday, July 2, 2017 at 9:00 AM

Lou, Hi!

Regards,
-Pavan

On Sat, Jul 1, 2017 at 9:57 AM, Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pavan/Authors,

OLD:

NEW

[VPB] Though it is possible to do FC without RI, I do believe that an implementation would get the best possible results if both techniques are employed together in tandem. So yes, 'll go ahead and make the above change.

[VPB] The intent here is to say that the "messages that remove state" SHOULD have higher priority than the "messages that bring up new LSP state". The messages that are needed to maintain the existing state are very important -- but that isn't explicitly stated. With Per-Peer FC now being made dependent on RI, I agree that there is a strong case to prioritize the Node-ID based Hello messages (to keep the signaling adjacency intact). The comment on ACKs also makes sense. I'll submit a new revision with the suggested changes in place.

That's it,
Lou

On 6/28/2017 11:09 PM, Vishnu Pavan Beeram wrote:
> Adrian, Hi!
>
> On Wed, Jun 28, 2017 at 7:37 PM, Adrian Farrel <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     Snipped..
>     >>
> [email-masked]<mailto:[email-masked]>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Sun, 2 Jul 2017 10:09:46 -0400

Please see inline.

> This sounds like a good addition.
The two "SHOULD prioritize .." statements in Rev-05 address this.
Alternatively, we could replace both of those statements with the following
statement:

- SHOULD prioritize messages that maintain or remove existing LSP state
over messages that bring up new LSP state.

 Regards,
-Pavan

---

From: Lou Berger <[email-masked]>
Date: Sun, 02 Jul 2017 10:11:51 -0400

Thanks Pavan (and coauthors)

All,

Please take a look at the changes and confirm that you don't have any 
comments on the changes.  While not a formal 2nd LC, I will wait a week 
before submitting the publication request to allow time for review.

Lou

On July 2, 2017 10:01:50 AM Vishnu Pavan Beeram <[email-masked]> wrote:

> Cc: TEAS WG <[email-masked]<mailto:[email-masked]>>, 
> "[email-masked]<mailto:[email-masked]>" 
> <[email-masked]<mailto:[email-masked]>>
> Resent-To: Vishnu Pavan Beeram 
> <[email-masked]<mailto:[email-masked]>>, Ina Minei 
> <[email-masked]<mailto:[email-masked]>>, 
> <[email-masked]<mailto:[email-masked]>>, 
> <[email-masked]<mailto:[email-masked]>>, 
> <[email-masked]<mailto:[email-masked]>>
> On Sat, Jul 1, 2017 at 9:57 AM, Lou Berger 
> <[email-masked]<mailto:[email-masked]>> wrote:
> Hi Pavan/Authors,
>
>> On Wed, Jun 28, 2017 at 7:37 PM, Adrian Farrel 
>> <[email-masked]<mailto:[email-masked]>

---

From: Lou Berger <[email-masked]>
Date: Sun, 9 Jul 2017 16:00:52 -0400

Hi,

    As no additional comments were received, I have submitted this for
publication. Please see
https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/
for the write up if interested.

Cheers,

Lou

On 7/2/2017 10:11 AM, Lou Berger wrote:
> comments on the changes.  While not a formal 2nd LC, I will wait a
> week before submitting the publication request to allow time for review.
>
> Lou
>
>> To: Lou Berger <[email-masked] <mailto:[email-masked]>>
>> Cc: TEAS WG <[email-masked] <mailto:[email-masked]>>,
>> "[email-masked]
>> <mailto:[email-masked]>"
>> <[email-masked]
>> <mailto:[email-masked]>>
>> Resent-From: <[email-masked] <mailto:[email-masked]>>
>> Resent-To: Vishnu Pavan Beeram <[email-masked]
>> <mailto:[email-masked]>>, Ina Minei <[email-masked]
>> <mailto:[email-masked]>>, <[email-masked] <mailto:[email-masked]>>,
>> <[email-masked] <mailto:[email-masked]>>,
>> <[email-masked] <mailto:[email-masked]>>
>>     and 2.2
>> implementation would get the best possible results if both techniques
>> are employed together in tandem. So yes, 'll go ahead and make the
>> above change.
>>
>>
>> state". The messages that are needed to maintain the existing state
>> are very important -- but that isn't explicitly stated. With Per-Peer
>> FC now being made dependent on RI, I agree that there is a strong
>> case to prioritize the Node-ID based Hello messages (to keep the
>> signaling adjacency intact). The comment on ACKs also makes sense.
>> I'll submit a new revision with the suggested changes in place.
>>  
>>
>>
>>     That's it,
>>     Lou
>>
>>     <[email-masked] <mailto:[email-masked]>
>>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>     >
>>     >     Snipped..
>>     >     >>
>>     <https://drive.google.com/file/d/0B5qbViWSXJ2CVzNkUlR6ci1INHM/view?usp=sharing>
>>     >
>>     > [email-masked] <mailto:[email-masked]>
>>     <https://www.ietf.org/mailman/listinfo/teas>
>>
>>
>> [email-masked] <mailto:Teas%40ietf.org>