Subject: [Gen-art] A *new* batch of IETF LC reviews - 2015-10-28

From: "A. Jean Mahoney" <[email-masked]>
Date: Wed, 28 Oct 2015 15:43:43 -0500

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft
---------------------------------------------------------------------
Brian Carpenter   2015-11-09   draft-ietf-teas-rsvp-te-domain-subobjects-03

Christer Holmberg 2015-11-09   draft-ietf-ccamp-flexible-grid-rsvp-te-ext-03

Dan Romascanu     2015-11-09   draft-ietf-pce-pcep-domain-sequence-09

Francis Dupont    2015-11-10   draft-ietf-straw-b2bua-dtls-srtp-08

I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

The /updated/ template is included below.

Thanks,

Jean

-------------------------------------------------------------------

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

---

From: "A. Jean Mahoney" <[email-masked]>
Date: Thu, 29 Oct 2015 07:04:55 -0500

An update to the assignments:

Reviewer          LC date       Draft
---------------------------------------------------------------------
Joel Halpern      2015-11-09   draft-ietf-pce-pcep-domain-sequence-09

Thanks!

Jean

On 10/28/15 3:43 PM, A. Jean Mahoney wrote:
> Christer Holmberg 2015-11-09
> draft-ietf-ccamp-flexible-grid-rsvp-te-ext-03
>
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 29 Oct 2015 17:12:11 -0400

Document: draft-ietf-pce-pcep-domain-sequence
     Standard Representation of Domain-Sequence
Reviewer: Joel M. Halpern
Review Date: 29-October-2015
IETF LC End Date: 09-November-2015
IESG Telechat date: N/A

Summary: This draft is almost ready for publication as an experimental RFC.

Major issues:
     Given that Exclude Route Objects are not interleaved with include 
Objects, is there a restriction that Area IDs may only be excluded from 
paths within a single AS?

Minor issues:
     It seems a bit odd for an Experimental RFC to use "Standard" in its 
title.  As one possible solution, in parallel with the naming of the 
related TEAS draft, this could be "Domain Subobjects for Path 
Computation Engine Protocol."

     The procedure for updating AS number scope when observing an IP 
address at a PCE processing an IRO seems fragile as described.  Many of 
the real-time mechanisms for this are error prone.  I would recommend 
that a note be added that this construct be avoided in building IROs 
whenever possible.

Nits/editorial comments:

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 30 Oct 2015 14:16:59 +0530

Hi Joel,

Thanks for a review. See inline...

> paths within a single AS?

[Dhruv]: I guess this would depend on the PCE behavior during inter-AS path
computation i.e. PCE may feel the area id subobject is irrelevent and
strips from the XRO before sending the request to another PCE
​ or it might keep it intact. ​

This would be in s
​pi​
rit of RFC 4874 where
​-

​      ​
The number of subobjects to be avoided, specified in the
   signaled XRO, may be constant throughout the whole path setup, or the
   subobjects to be avoided may be removed from the XRO as they become
   irrelevant in the subsequent hops of the path setup.

We can always
​use ​
EXRS in IRO specify the intentions much more clearly.

If you agree, we can work on some text to add.

> related TEAS draft, this could be "Domain Subobjects for Path Computation
> Engine Protocol."
>

[Dhruv]: The draft was initially on standard track :)
I can live with the name change.

> address at a PCE processing an IRO seems fragile as described.  Many of the
> real-time mechanisms for this are error prone.  I would recommend that a
> note be added that this construct be avoided in building IROs whenever
> possible.
>
​[Dhruv]: Could you help frame this text, here is the initial version.

Note that it is advised that PCC should use AS are Area subobject while
building the domain-sequence in IRO and avoid using other mechanism to
change the "current AS" and "current Area" as described above.

Regards,
Dhruv

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 30 Oct 2015 08:31:04 -0400

Thank you for the reply.  Comments in line.
Yours,
Joel

On 10/30/15 4:46 AM, Dhruv Dhody wrote:
> On Fri, Oct 30, 2015 at 2:42 AM, Joel M. Halpern <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>          Given that Exclude Route Objects are not interleaved with
>     include Objects, is there a restriction that Area IDs may only be
>     excluded from paths within a single AS?
>
>
> [Dhruv]: I guess this would depend on the PCE behavior during inter-AS
> path computation i.e. PCEmay feel the area id subobjectis irreleventand
> ritof RFC 4874 where

I still can not see how the Excluded Route Object with an Area ID will 
work.  How will a PCE which receives such a request know what AS it 
applies to?  It works fine if the whole path is within one AS.  But if 
this is a multi-AS request, the AS elements, if present at all, are in 
the IRO.
The most obvious approach would be to declare that the PCE shall assume 
that all Area ID exclusions apply to the origin AS.

>
>
>     Minor issues:
>          It seems a bit odd for an Experimental RFC to use "Standard" in
>     its title.  As one possible solution, in parallel with the naming of
>     the related TEAS draft, this could be "Domain Subobjects for Path

Thanks.

>     address at a PCE processing an IRO seems fragile as described.  Many
>     of the real-time mechanisms for this are error prone.  I would
>     recommend that a note be added that this construct be avoided in
>     building IROs whenever possible.
>

That would work for me.

---

From: Julien Meuric <[email-masked]>
Date: Fri, 30 Oct 2015 16:35:16 +0100

Hi Joel, hi Dhruv,

Focusing on the Area ID issue, I'd support adding some text along with 
Dhruv's proposal, but stricter (not just deferring to "implementation's 
feeling"). I.e., Area IDs are AS-specific and mustn't cross AS borders; 
AS-local Area IDs may be used inside an AS (without restricting to the 
origin AS).

See you in Yokohama,

Julien