Subject: Re: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05

From: "Zhangxian (Xian)" <[email-masked]>
Date: Tue, 3 May 2016 03:13:18 +0000

Hi, all,

I've reviewed this document and believe it is ready for publication.

I have one suggestion on the encoding section: could we add the bit number for each field explanation? It may be a bit redundant, but I find it usually clearer if we have such information in the text.

Others are just some nits:
1： s/Note that specification of the the use of the collected SRLGs is outside the scope of this document./Note that specification of the use of the collected SRLGs is outside the scope of this document.
2：s/SRLG information is for each hop is added to the Path RRO during Path message processing./SRLG information is added by each hop to the Path RRO during Path message processing.(?)
3: consider relocating the following sentence to the very beginning of this section(5.1), maybe?
A node SHOULD NOT add SRLG information without an explicit request for it being made by the ingress node in the Path message.
4: The points listed in Section 6.1 started with “o” are squeezed together in one paragraph; please rectify.

Regards,
Xian

From: Teas [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: 2016年4月29日 4:42
To: [email-masked]
Subject: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05

All,
This starts a two week working group last call on
draft-ietf-teas-rsvp-te-srlg-collect-05.

The working group last call ends on Thursday, May 12th. Please
send your comments to the TEAS mailing list.

As is always the case, 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 draft.

Thanks,
Pavan (and Lou)

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Tue, 3 May 2016 15:11:48 +0000

Thanks for the comments, Xian!

On the encoding section: the feedback I’ve received in the past is that it’s better not to do add the bit numbers to the encoding section as you have to mark them as provisional/TBD, and that’s then more work for the RFC Editor to clean up when IANA does the assignment… but I agree, the doc would read better if you didn’t have to go to another section to see the values. Chairs, Deborah – any comment on this?

Thanks for the nits – I’ll sort those out when LC is done.

Cheers

Matt

Hi, all,

Regards,
Xian

From: Teas [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: 2016年4月29日 4:42
To: [email-masked]<mailto:[email-masked]>
Subject: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05

All,

Thanks,
Pavan (and Lou)

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Wed, 4 May 2016 03:47:50 +0000

Hi, Matt,

    Great; just one clarification inline:

   From: Matt Hartley (mhartley) [mailto:[email-masked]]
Sent: 2016年5月3日 23:12
To: Zhangxian (Xian); Vishnu Pavan Beeram; [email-masked]
Cc: Matt Hartley (mhartley)
Subject: RE: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05

Just to make sure I get my point through, I am not talking about the code point allocation, but just how many bits each field takes (for example: Is length field 8-bit or 7-bit? A bad example, just to illustrate the point). AFAIK, IANA section does not cover this information. If it is not provided, the reader/implementer may need to do a manual count.  But the encoding in this draft is so simple that you may not see the necessity, so up to you/the draft editor.

Regards,
Xian

Cheers

Matt

Hi, all,

Regards,
Xian

All,

Thanks,
Pavan (and Lou)

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Wed, 4 May 2016 15:50:42 +0000

Xian,

OK – I understand what you mean now. I’ll do that too.

Cheers

Matt

Hi, Matt,

   From: Matt Hartley (mhartley) [mailto:[email-masked]]
Sent: 2016年5月3日 23:12
To: Zhangxian (Xian); Vishnu Pavan Beeram; [email-masked]<mailto:[email-masked]>
Cc: Matt Hartley (mhartley)
Subject: RE: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05

Regards,
Xian

Cheers

Matt

Hi, all,

Regards,
Xian

All,

Thanks,
Pavan (and Lou)

---

From: "Shah, Himanshu" <[email-masked]>
Date: Fri, 13 May 2016 18:07:54 -0400

Sorry for the late reply.. (On PTO..)

While adding of “completion flag” (or similar to “partial bit” used in BGP) would have been a nice feature
to have, the SRLG collect draft by itself is an important feature to have, so..

I support progressing the document to publication.

Thanks,
Himanshu

From: Teas [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: Thursday, April 28, 2016 4:42 PM
To: [email-masked]
Subject: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05

All,

Thanks,
Pavan (and Lou)

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 13 May 2016 20:15:53 -0400

The WG LC for this document is now closed.

Matt (and other authors),
Please go ahead and publish a new revision addressing the minor comments
received during the LC.

Regards,
-Pavan (and Lou)

On Fri, May 13, 2016 at 6:07 PM, Shah, Himanshu <[email-masked]> wrote:

> *Sorry for the late reply.. (On PTO..)*
>
>
>
> *While adding of “completion flag” (or similar to “partial bit” used in
> BGP) would have been a nice feature*
>
> *to have, the SRLG collect draft by itself is an important feature to
> have, so..*
>
>
>
> *I support progressing the document to publication.*
>
>
>
> *Thanks,*
>
> *Himanshu*
>
>
>
> *From:* Teas [mailto:[email-masked]] *On Behalf Of *Vishnu Pavan
> Beeram
> *Sent:* Thursday, April 28, 2016 4:42 PM
> *To:* [email-masked]
> *Subject:* [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05
>
>
>
> All,
>

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Wed, 18 May 2016 21:00:14 +0000

Thanks, Himanshu.

FWIW, I see no reason why the completion flag can’t be added as a subsequent enhancement in a new draft, if there’s a desire to do so.

Cheers

Matt

Thanks,
Himanshu

All,

Thanks,
Pavan (and Lou)

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Wed, 25 May 2016 14:12:50 -0400

Authors, Hi!

I'm in the process of updating the Shepherd's write-up for this document.
I'm expecting you to submit another rev for this draft (addressing the nits
that were raised during the LC). I found a few other nits (pasted below)
during my review. Please see if you can take care of these as well in the
next rev.

I'll resubmit the publication request as soon as the new version shows up.

Regards,
-Pavan

**
Section 1.

- s/This document provides a mechanism to collect the SRLGs used by a
LSP,/This document provides a signaling mechanism to collect the SRLGs used
by a LSP,
[Comment - signaling mechanism as opposed to routing mechanism; The
introduction section doesn’t explicitly say (maybe it should) that this
mechanism is useful in scenarios where the SRLG info cannot be obtained via
IGP-TE (via routing)]

- s/Note that specification of the the use of the collected SRLGs is
outside the scope of this document./Note that specification of the use of
the collected SRLGs is outside the scope of this document.
[Comment - You may even consider removing the above line altogether (given
that the document does discuss an applicability example in 1.1)]

Section 3.1:

- Fix indentation for the whole section

Section 3.2:

- Fix indentation for the whole section.

- s/SRLG information is for each hop is added to the Path RRO during Path
message processing./SRLG information is added by each hop to the Path RRO
during Path message processing.

- Consider removing the following line [Comment - it doesn’t seem to be
bringing in any additional value in this section]:
The endpoints of the LSP can make use of the collected SRLG information,
for example, for routing, sharing and TE link configuration purposes.

Section 3.3:

- Fix indentation for the whole section.

- s/This means that that the signaling procedure needs to be capable of
updating the new SRLG information./This means that the signaling procedure
needs to be capable of updating the new SRLG information.

Section 3.4:

- Fix indentation for the whole section.

Section 4.1:

- Fix indentation for the first paragraph.

Section 6.1 - Policy Configuration:

- Fix the bullets; All bullet points “o” are squeezed together in one
paragraph.

Section 8.2 ROUTE_RECORD Object

- Fix the indentation of the table (align it with the table in 8.1)

Section 8.3 Policy Control Failure Error subcodes

- Fix the indentation of the table (align it with the table in 8.1)

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Fri, 27 May 2016 02:23:37 +0000

Pavan, all,

V6 posted with markups from the LC comments.

Cheers

Matt

Authors, Hi!
I'm in the process of updating the Shepherd's write-up for this document. I'm expecting you to submit another rev for this draft (addressing the nits that were raised during the LC). I found a few other nits (pasted below) during my review. Please see if you can take care of these as well in the next rev.
I'll resubmit the publication request as soon as the new version shows up.

Regards,
-Pavan

**
Section 1.

- s/This document provides a mechanism to collect the SRLGs used by a LSP,/This document provides a signaling mechanism to collect the SRLGs used by a LSP,
[Comment - signaling mechanism as opposed to routing mechanism; The introduction section doesn’t explicitly say (maybe it should) that this mechanism is useful in scenarios where the SRLG info cannot be obtained via IGP-TE (via routing)]

- s/Note that specification of the the use of the collected SRLGs is outside the scope of this document./Note that specification of the use of the collected SRLGs is outside the scope of this document.
[Comment - You may even consider removing the above line altogether (given that the document does discuss an applicability example in 1.1)]

Section 3.1:

Section 3.2:

- s/SRLG information is for each hop is added to the Path RRO during Path message processing./SRLG information is added by each hop to the Path RRO during Path message processing.

- Consider removing the following line [Comment - it doesn’t seem to be bringing in any additional value in this section]:
The endpoints of the LSP can make use of the collected SRLG information, for example, for routing, sharing and TE link configuration purposes.

Section 3.3:

- s/This means that that the signaling procedure needs to be capable of updating the new SRLG information./This means that the signaling procedure needs to be capable of updating the new SRLG information.

Section 3.4:

Section 4.1:

- Fix the bullets; All bullet points “o” are squeezed together in one paragraph.

On Fri, May 13, 2016 at 8:15 PM, Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>> wrote:
The WG LC for this document is now closed.
Matt (and other authors),
Please go ahead and publish a new revision addressing the minor comments received during the LC.
Regards,
-Pavan (and Lou)

On Fri, May 13, 2016 at 6:07 PM, Shah, Himanshu <[email-masked]<mailto:[email-masked]>> wrote:
Sorry for the late reply.. (On PTO..)

Thanks,
Himanshu

From: Teas [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Vishnu Pavan Beeram
Sent: Thursday, April 28, 2016 4:42 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Teas] WG Last Call on draft-ietf-teas-rsvp-te-srlg-collect-05

All,

Thanks,
Pavan (and Lou)