Thank you for the reply. Comments in line.
Yours,
Joel
On 10/30/15 4:46 AM, Dhruv Dhody wrote:
Hi Joel,
Thanks for a review. See inline...
On Fri, Oct 30, 2015 at 2:42 AM, Joel M. Halpern <[email protected]
<mailto:[email protected]>> wrote:
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: 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?
[Dhruv]: I guess this would depend on the PCE behavior during inter-AS
path computation i.e. PCEmay feel the area id subobjectis irreleventand
strips from the XRO before sending the request to another PCE
or it might keep it intact.
This would be in s
pi
ritof 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.
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
Computation Engine Protocol."
[Dhruv]: The draft was initially on standard track :)
I can live with the name change.
Thanks.
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.
[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.
That would work for me.
Regards,
Dhruv
Nits/editorial comments:
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
