Re: [Pce] PCE WG Last Call on draft-ietf-pce-pcep-domain-sequence-07

["Adrian Farrel" <[e-mail]>]

Thanks for the work, Dhruv,

Many snips...

> > It seems to me that the text here treats the domain sequence as a separate
> > thing rather than just some new IRO subobjects that can be included in a
> > PCReq. This shows in some of my comments below. Perhaps you need some
> > more words to explain how to interleave the normal subobjects with the new
> > ones.
> 
> I see, once the I-D was suggesting a new IRO type but that is not the case
now. I
> have added some text to clarify this.
> Please check and let me know if further changes are needed.

I skimmed the new text in 3.4 and elsewhere in the document. You seem to have
addressed my concern, but I haven't checked the details of the ordering and
interpretation of the subobjects.

> > It is fine that this is an experimental document, but I do wonder: what the
> > experiment is

[snip]

> I have added a section -
> 
> 1.1.  Scope
> 
>    The procedures described in this document are experimental.  The
>    experiment is intended to enable research for the usage of Domain-
>    Sequence at the PCEs for inter-domain paths.  For this purpose this
>    document specify new domain subobjects as well as how they
>    incorporate with existing subobjects to represent a Domain-Sequence.
> 
>    This document does not change the procedures for handling existing
>    subobjects in PCEP.
> 
>    When the result of implementation and deployment are available, this
>    document will be updated and refined, and then be moved from
>    Experimental to Standard Track.

I like this.

Maybe also...

The new subobjects introduced by this document will not be understood by legacy
implementations. If one of the subobjects is received in a PCEP object that does
not understand it, it will behave as described in Section 3.4.3. Therefore, it
is assumed that this experiment will be conducted only when both the PCE and PCC
form part of the experiment. It is possible that a PCC or PCE can operate with
peers some of which form part of the experiment and some that do not. In this
case, since no capabilities exchange is used to identify which nodes can use
these extensions, manual configuration should be used to determine which
peerings form part of the experiment.

> > I question the inclusion of the word "shortest" in the Abstract, and I don't
> > find it repeated in the Introduction where I looked to find a citation that
> > indicated that it is a "key requirement".

[snip]
 
> I hear you, but RFC5441 does use the term "shortest constrained path".
> I can either -
> - leave as it is, as there is precedence.
> - add text in Introduction, with reference to RFC5441.
> - remove "shortest" as suggested above.

I don't feel strongly enough to guide you. Any of these three will be enough for
me.

[snip]

> > In 3.4.1.2, I don't understand why you need two sub-object types. You could
> > certainly handle the encoding within the same sub-object so you are
> > presumably worried about distinguishing between an OSPF area ID and an IS-IS
> > area ID. I suppose that there is a faint chance that one AS is running two
> > IGPs at once and the administrator has decided to give the same ID to two
> > areas, one from each IGP. Is that what you're worried about?
> 
> Since the format of the area ID are different in the two routing protocols; as
well
> as we already have different TLV for OSPF and ISIS area-id in RSVP-TE in
RFC4920,
> we feel that this is a better encoding option.

OK. Leave it.

> > 3.4.1.2 gives [ISO10589] as a reference for the definition of an area ID. It
> > surprised me that we don't have an IETF reference for this. Can you check
> > with the chairs of the ISIS WG that this is the right reference.
> 
> [ISO10589] is also republished as RFC 1142 (historic). I can use that instead,
but
> even RFC5089 uses the [ISO] reference. Anyways I will shoot a mail to WG
chairs
> to get a confirmation.

Saw the email. Whatever they say will close this issue.

[snip]

> > Figure 3 is "interesting". Aren't AS interconnects always provided in Area
0,
> > or am I embarrassing myself?
> 
> It usually is, I have added text to re-iterate that the figure is for
illustrative
> purpose only and the usual convention is for AS interconnects to Area 0.
> Other option is to remove this example altogether.

Yeah, perhaps remove it, or replace it with an example of a multi-AS network?

Thanks again,
Adrian