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

From: <[email-masked]>
Date: Wed, 15 Apr 2015 18:42:52 +0200

Dear PCE & TEAS WGs,

This message initiates a 2-week WG last call on 
draft-ietf-pce-pcep-domain-sequence-07. Please send your comments to the 
PCE mailing list by Wednesday April 29.

Thanks,

JP & Julien

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 16 Apr 2015 01:04:44 +0000

Support.

Best Regards,
Huaimo
-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, April 15, 2015 12:43 PM
To: [email-masked]
Subject: [Pce] PCE WG Last Call on draft-ietf-pce-pcep-domain-sequence-07

Dear PCE & TEAS WGs,

This message initiates a 2-week WG last call on draft-ietf-pce-pcep-domain-sequence-07. Please send your comments to the PCE mailing list by Wednesday April 29.

Thanks,

JP & Julien

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 16 Apr 2015 21:13:18 +0530

Support as co-author :)

Regards,
Dhruv

On Wed, Apr 15, 2015 at 10:12 PM, <[email-masked]> wrote:

> Dear PCE & TEAS WGs,
>
> This message initiates a 2-week WG last call on draft-ietf-pce-pcep-domain-sequence-07.
> Please send your comments to the PCE mailing list by Wednesday April 29.
>
> Thanks,
>
> JP & Julien
>
>
> ____________________________________________________________
> _____________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: Udayasree palle <[email-masked]>
Date: Fri, 17 Apr 2015 05:22:50 +0000

Support as a co-author

Regards,
Udaya

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 15 April 2015 22:13
To: [email-masked]
Subject: [Pce] PCE WG Last Call on draft-ietf-pce-pcep-domain-sequence-07

Dear PCE & TEAS WGs,

Thanks,

JP & Julien

---

From: Lizhenbin <[email-masked]>
Date: Mon, 20 Apr 2015 01:30:48 +0000

Support.

Regards,
Robin

-----邮件原件-----
发件人: Pce [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2015年4月16日 0:43
收件人: [email-masked]
主题: [Pce] PCE WG Last Call on draft-ietf-pce-pcep-domain-sequence-07

Dear PCE & TEAS WGs,

Thanks,

JP & Julien

---

From: Leeyoung <[email-masked]>
Date: Tue, 21 Apr 2015 04:31:03 +0000

Support.

Thanks,
Young

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, April 15, 2015 11:43 AM
To: [email-masked]
Subject: [Pce] PCE WG Last Call on draft-ietf-pce-pcep-domain-sequence-07

Dear PCE & TEAS WGs,

Thanks,

JP & Julien

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 21 Apr 2015 09:22:38 -0400

Support.

-Pavan

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 23 Apr 2015 20:41:31 +0100

Hi,

While I have frequently questioned the need for this function in an IRO, I have
done a quick review of this document. I don't guarantee to have found
all of the issues, but I do conclude that the document is not ready for
publication as an RFC.

Cheers,
Adrian

===

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.

---

It is fine that this is an experimental document, but I do wonder: what
the experiment is; how to confine the experiment so it doesn't impact
other nodes or networks (see my comments on 3.4.3 and 3.5.1.2; what I
need to do to all nodes in the experimental network; how I judge the
success 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". In fact, I
think that the term "shortest" is in some senses conflicting with the
concept of including other constraints. I would solve this by accepting
that "as short as possible given the other constraints" is itself just
a constraint. Thus...

OLD
   The ability to compute shortest constrained Traffic Engineering Label
NEW
   The ability to compute constrained Traffic Engineering Label
END

...and...

OLD
   to compute inter-domain constrained
   shortest paths across a predetermined sequence of domains .
NEW
   to compute inter-domain constrained
   paths across a predetermined sequence of domains.
END

And in 3.4.3
OLD
   A PCC builds an IRO to encode the Domain-Sequence, so that the
   cooperating PCEs should compute an inter-domain shortest constrained
   path across the specified sequence of domains.
NEW
   A PCC builds an IRO to encode the Domain-Sequence, so that the
   cooperating PCEs should compute an inter-domain constrained
   path across the specified sequence of domains.
END

---

Section 1 has some duplication. I think you can delete:

                                             A PCE determines the next
   PCE to forward the request based on the Domain-Sequence.  In a multi-
   domain path computation, a Path Computation Client (PCC) MAY indicate
   the sequence of domains to be traversed using the Include Route
   Object (IRO) defined in [RFC5440].

   When the sequence of domains is not known in advance, the
   Hierarchical PCE (H-PCE) [RFC6805] architecture and mechanisms can be
   used to determine the Domain-Sequence.

And move:

   This document defines a standard way to represent and encode a
   Domain-Sequence in various scenarios including P2P LSP, P2MP LSP, and
   use of H-PCE.

... to later in the section.

This also removes two problems with:

   In a multi-
   domain path computation, a Path Computation Client (PCC) MAY indicate
   the sequence of domains to be traversed using the Include Route
   Object (IRO) defined in [RFC5440].

1. I don't think the upper case "MAY" is necessary or appropriate.

2. I think that 5440 only gives you half of what you want, which is why
   you are writing this document! But you actually catch and explain
   this in the paragraphs that follow.

---

The 2119 language in Section 3.2 doesn't seem right. You are describing
how things are, not how things have to be. I think you can use just
normal language.

It also doesn't seem right in 3.3 where you are describing how things
work, not what implementations have to do.

---

There seems to be some duplication in section 3.3. For example,

   o  Include Route Object (IRO): As per [RFC5440], used to specify set
      of network elements that MUST be traversed.  The subobjects in IRO
      are used to specify the Domain-Sequence that MUST be traversed to
      reach the destination.

---

In 3.4.1 you are repeating some material that isn't really needed.

   The following subobject types are used in IRO.

                Type   Subobject
                 1     IPv4 prefix
                 2     IPv6 prefix
                 4     Unnumbered Interface ID
                 32    Autonomous system number (2 Byte)
                 33    Explicit Exclusion (EXRS)

---

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?

---

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.

---

In 3.4.1.2 for the IS-IS variant, you have...

   Length:  Variable.  As per [RFC3209], the total length of the
      subobject in bytes, including the L, Type and Length fields.  The
      Length MUST be at least 4, and MUST be a multiple of 4.

Wouldn't a length of 4 mean that there was no area ID included?

---

3.4.3 lists four references for IRO subobjects: [RFC3209], [RFC3473],
[RFC3477], and [RFC4874]. But RFC 3473 is not listed at
http://www.iana.org/assignments/pcep/pcep.xhtml#iro-subobject

---

In 3.4.3

   If a PCE encounters a subobject that it does not support or
   recognize, it MUST act according to the setting of the L-bit in the
   subobject.  If the L-bit is clear, the PCE MUST respond with a PCErr
   with Error-Type TBD4 "Unrecognized subobject" and set the Error-Value
   to the subobject type code.  If the L-bit is set, the PCE MAY respond
   with a PCErr as already stated or MAY ignore the subobject: this
   choice is a local policy decision.

This links to 5.2.

You are defining behavior in this I-D for a non-compliant node. But a 
non-compliant node doesn't support this I-D!

That is, an implementation of 5440 will look at the received IRO and see
the unknown subobject and act according to 5440 not according to this
document.

You have to ask yourselves:
- What does my 5440 implementation do with an unknown subobject?
- Is that behavior documented and do I simply need to point to that?
- Do we need an update to 5440 to say how to handle unknown subobjects?

---

In 3.4.3

   Note that a particular domain in the Domain-Sequence can be
   identified by :-

   o  A single IGP Area: Only the IGP (OSPF or ISIS) Area subobject is
      used to identify the next domain.  (Refer Figure 1)

   o  A single AS: Only the AS subobject is used to identify the next
      domain.  (Refer Figure 2)

   o  Both an AS and an IGP Area: AS and Area in combination are used to
      identify the next domain.  In this case the order is AS Subobject
      followed by Area.  (Refer Figure 3)

This is not clear. If I identify two domains in the sequence, the first
with an AS subobject and the second with an Area subobject, how is this
distinguished from the third case that you list?

I think you have to clarify how this works. Isn't it the case that an
area ID can only ever have context within a specific AS? Isn't it the
case that if you supply an AS followed by an area you are not
controlling the entry area to the AS? Does all that actually mean that
you need the area subobject to carry the AS number?

---

3.4.3

   The Subobjects representing an internal node, a Boundary Node or an
   Inter-AS-Link MAY also influence the selection of the path.

I guess you mean "MAY be included by a PCC to influence the selection of
the path".

---

In 3.5 you are repeating some material that isn't really needed
because it is already in other documents and the IANA registry.

   The following subobject types are defined to be used in XRO as
   defined in [RFC3209], [RFC3477], [RFC4874], and [RFC5521].

                Type   Subobject
                 1     IPv4 prefix
                 2     IPv6 prefix
                 4     Unnumbered Interface ID
                 32    Autonomous system number (2 Byte)
                 34    SRLG
                 64    IPv4 Path Key
                 65    IPv6 Path Key

But, anyway, it should be 5520 not 5521.

---

For 3.5.1.2 I have the same questions as for 3.4.1.2

---

3.5.1.2 has

   If a PCE that supports XRO and encounters a subobject that it does
   not support or recognize, it MUST act according to the setting of the
   X-bit in the subobject.  If the X-bit is clear, the PCE MUST respond
   with a PCErr with Error-Type TBD4 "Unrecognized subobject" and set
   the Error-Value to the subobject type code.  If the X-bit is set, the
   PCE MAY respond with a PCErr as already stated or MAY ignore the
   subobject: this choice is a local policy decision.

Similar to 3.4.3...

This links to 5.2.

You are defining behavior in this I-D for a non-compliant node. But a 
non-compliant node doesn't support this I-D!

That is, an implementation of 5440 will look at the received IRO and see
the unknown subobject and act according to 5440 not according to this
document.

You have to ask yourselves:
- What does my 5440 implementation do with an unknown subobject?
- Is that behavior documented and do I simply need to point to that?
- Do we need an update to 5440 to say how to handle unknown subobjects?

---

3.7 lead me to look at 5.1.

5.1 is confusing...

   The "PCEP Parameters" registry contains a subregistry "PCEP Objects"
   with an entry for the Include Route Object (IRO), Exclude Route
   Object (XRO) and Explicit Route Object (ERO).  IANA is requested to
   add further subobjects as follows:

       7  ERO
       10 IRO
       17 XRO

       Subobject Type                          Reference
       TBD1      4 byte AS number              [This I.D.]
       TBD2      OSPF Area ID                  [This I.D.]
       TBD3      IS-IS Area ID                 [This I.D.]

I think you mean to ask IANA to make the same three assignments from all
three registries. This text:
- doesn't make that clear
- doesn't identify the registries correctly
- there is no PCEP ERO registry!

You probably want...

   IANA maintains the "Path Computation Element Protocol (PCEP) Numbers"
   at http://www.iana.org/assignments/pcep/pcep.xhtml. Within this 
   registry IANA maintains two sub-registries:

   - "IRO Subobjects"
     http://www.iana.org/assignments/pcep/pcep.xhtml#iro-subobject
   - "XRO Subobjects"
     http://www.iana.org/assignments/pcep/pcep.xhtml#xro-subobject

   IANA is requested to make identical additions to these registries as
   follows:

       Subobject Type                          Reference
       TBD1      4 byte AS number              [This I.D.]
       TBD2      OSPF Area ID                  [This I.D.]
       TBD3      IS-IS Area ID                 [This I.D.]

But you will also need to change the text in 3.7 because you can't make
additions to the PCEP ERO subobject registry when it doesn't exist! And
you can't make changes to the RSVP ERO subobject registry in the PCE
working group.

---

In 3.7 you have..

   The format of the new ERO subobjects is similar to new IRO
   subobjects, refer Section 3.4.

"similar"?

---

Figure 1 has some extra pipes (|) in the ABR between area 2 and area 0.

---

4.1.1 says...

   AS is optional and it MAY be skipped.

I don't think you mean "skipped". If the AS is present it MUST be
processed because it has to be checked. 

Additionally, you have already told us that the examples are not
normative. So:

- you must not use 2119 language
- you need to check that the normative text *is* present in section 3

So in 4.2.1 I think you mean...

   AS is optional. If it is not present, the receiver will deduce that
   there is no change in the AS.

But somewhere you will need to clarify a few things (I think I asked
questions about some of this as I read section 3) about the order of 
subobjects and how they are interleaved in the three objects.

Essentially you have...
- The Area subobject is optional.
- The AS subobject is optional.
- If an Area subobject is not preceded by an AS subobject then the 
  receiver MUST act as though there is no change in AS from the 
  previous subobject.
- If an AS subobject is present then it changes the AS for all 
  subsequent subobjects that do not themselves change the AS.
- Subobjects that may change the AS are:
  - IP addresses that are present in another AS
  - Unnumbered interfaces that are present in another AS
  - AS numbers
  - Path key identifiers that expand to path segments that include
    changes to the AS
- AS and Area subobjects may be interspersed with other subobjects
  without change to the previously specified processing.

Whether this goes in section 3 (which feels natural) or in section 4
(where you have any number of other small normative items) is up to 
you, but if it is in section 4 you really need to make much clearer
that I need to read the section!

---

Figure 3 is "interesting". Aren't AS interconnects always provided in
Area 0, or am I embarrassing myself?

---

The option for encoding the inter-AS link in section 4.3 is legitimate,
but excessive. You do not need to show both link ends since it would be
impossible to use one end of the link without using the other end!

---

I think it is fine for section 4.5 to make a reference to 7334, but it
is wrong to do so in a way that suggests that 7334 is *the* way to do
inter-domain P2MP path computation since that RFC describes an
experiment.

Similarly, [PCE-P2MP-PER-DEST] is also experimental (and has expired!).

In both cases, this is notwithstanding that this document is an
experiment itself.

---

Figure 4 has the same typo in the ABR as in Figure 1.

---

In 4.6 "ERO Object" should be EROO :-)

---

In 4.6 you have:

   The ERO can contain an ordered sequence of
   subobjects such as AS and Area (OSPF/ISIS) subobjects.  In this case,
   the Domain-Sequence appear as:

     +---------+ +---------+ +---------+ +---------+
     |ERO      | |Sub      | |Sub      | |Sub      |
     |Object   | |Object   | |Object   | |Object   |
     |Header   | |Area 2   | |Area 0   | |Area 4   |
     |         | |         | |         | |         |
     |         | |         | |         | |         |
     +---------+ +---------+ +---------+ +---------+

     +---------+ +---------+ +---------+ +---------+ +---------+
     |ERO      | |Sub      | |Sub      | |Sub      | |Sub      |
     |Object   | |Object AS| |Object   | |Object   | |Object   |
     |Header   | |100      | |Area 2   | |Area 0   | |Area 4   |
     |         | |         | |         | |         | |         |
     |         | |         | |         | |         | |         |
     +---------+ +---------+ +---------+ +---------+ +---------+

This is confusing. I think you mean to indicate a choice.

However, I have no clear understanding of why this is a good example 
since:
- the Ingress PCE 'PCE(1)' would more logically be in Area 1
- the ERO could contain the identifiers of the ABRs
- Area 2 is presumably taken as read by the requesting PCE so doesn't
  need to be included
- if Area 2 needs to connect to anything out of area it has to go
  through Area 0, so including that is superfluous

---

Section 4.7 uses "SHOULD". Under what circumstances MAY the PCE-Sequence
have lower or equal precedence?

You also say:

   Note
   that Domain-Sequence IRO constraints should still be checked as per
   the rules of processing IRO.

...Why don't I have to check the XRO and EXRS?

---

4.8 has

   [DOMAIN-SUBOBJ] extends the notion of abstract nodes by adding new
   subobjects for IGP Areas and 4-byte AS numbers.  These subobjects MAY
   be included in Explicit Route Object (ERO), Exclude Route object
   (XRO) or Explicit Exclusion Route Subobject (EXRS) in RSVP-TE.

Is it right to provide normative language for RSVP-TE in this document?

---

This is a bit odd...

7.6.  Impact On Network Operations

   Mechanisms defined in this document do not have any impact on network
   operations in addition to those already listed in [RFC5440].

I thought the whole point was to impact network operations!

---

While it is OK for this document and [DOMAIN-SUBOBJ] to only have
informational references to each other, I think it would be sensible to
try to tie them together in the RFC Editor Queue so that they get
considered together, so that any issues can be synchronised, and so that
there are no surprises with code points.

I guess the chairs can talk to the TEAS chairs and the ADs to make this
happen, or you could upgrade the references to be normative.

Maybe a normative reference would be more in keeping with the revision
to 5.1 and 4.8 I think you should make because there is no PCEP ERO
subobject registry.

> Sent: 15 April 2015 17:43
> To: [email-masked]
> ______________________________________________________________
> ___________________________________________________________
> 
> If you have received this email in error, please notify the sender and delete
this
> message and its attachments.

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Fri, 24 Apr 2015 00:59:54 +0000

Just want to comment on the ERO issue in IANA section Adrian pointed out, which I think the authors probably have it in their to-update list (see the draft (https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-domain-subobjects-00) in TEAS WG). 

Regards,
Xian

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: 2015年4月24日 3:42
To: [email-masked]
Subject: Re: [Pce] PCE WG Last Call on draft-ietf-pce-pcep-domain-sequence-07

Hi,

Cheers,
Adrian

===

---

---

OLD

...and...

OLD

And in 3.4.3
OLD

---

And move:

   In a multi-

---

---

---

                Type   Subobject
                 1     IPv4 prefix
                 2     IPv6 prefix

---

---

---

---

---

In 3.4.3

This links to 5.2.

---

In 3.4.3

---

3.4.3

---

                Type   Subobject
                 1     IPv4 prefix
                 2     IPv6 prefix

---

---

3.5.1.2 has

Similar to 3.4.3...

This links to 5.2.

---

5.1 is confusing...

       7  ERO
       10 IRO
       17 XRO

       Subobject Type                          Reference

You probably want...

   - "IRO Subobjects"

       Subobject Type                          Reference

---

In 3.7 you have..

"similar"?

---

---

4.1.1 says...

Essentially you have...

---

---

---

---

---

---

In 4.6 you have:

---

You also say:

   Note

---

4.8 has

---

This is a bit odd...

---

this

---

From: Dhruv Dhody <[email-masked]>
Date: Sat, 25 Apr 2015 07:20:39 +0000

Hi Adrian, 

Thank you for a detailed set of comments as well as text suggestions. 
I have handled most of your comments, request you/WG to have a look in the diff attached.  
Some comments need confirmation, and hence open. 

Regards,
Dhruv

> Sent: 24 April 2015 01:12
> To: [email-masked]
> While I have frequently questioned the need for this function in an IRO, I
> have done a quick review of this document. I don't guarantee to have found

I hope with these changes, you would be okay with moving the document forward :)

> 
> Cheers,
> Adrian
> 
> ===
> 
> 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. 

> 
> ---
> 
> It is fine that this is an experimental document, but I do wonder: what the
> experiment is; how to confine the experiment so it doesn't impact other nodes
> or networks (see my comments on 3.4.3 and 3.5.1.2; what I need to do to all
> nodes in the experimental network; how I judge the success of the experiment.
> 

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 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". In fact, I think that the term
> "shortest" is in some senses conflicting with the concept of including other
> constraints. I would solve this by accepting that "as short as possible given
> the other constraints" is itself just a constraint. Thus...
> 
> OLD
>    The ability to compute shortest constrained Traffic Engineering Label NEW
>    The ability to compute constrained Traffic Engineering Label END
> 
> ...and...
> 
> OLD

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.

Status: Open

>    this in the paragraphs that follow.

Understood & done!  

> ---
> 
> The 2119 language in Section 3.2 doesn't seem right. You are describing how
> things are, not how things have to be. I think you can use just normal
> language.
> 
> It also doesn't seem right in 3.3 where you are describing how things work,
> not what implementations have to do.
> 

Agreed, thanks for catching this! 

>       are used to specify the Domain-Sequence that MUST be traversed to

Ack. 

>                  33    Explicit Exclusion (EXRS)

Ack. 

> ---
> 
> 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. 

Status: Open

> ---
> 
> 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. 

Status: Open

> Wouldn't a length of 4 mean that there was no area ID included?

Updated. 

> http://www.iana.org/assignments/pcep/pcep.xhtml#iro-subobject

Oops! Copy-paste error! Fixed. 

> You are defining behavior in this I-D for a non-compliant node. But a non-
> compliant node doesn't support this I-D!
> 
> That is, an implementation of 5440 will look at the received IRO and see the
> unknown subobject and act according to 5440 not according to this document.
> 

Understood. I have updated the text, taking a cue from 5521 where EXRS got added. 
The text now says - 

   If a PCE receives an IRO in a Path Computation request (PCReq)
   message that contains subobjects defined in this document, that it
   does not recognize, it will respond according to the rules for a
   malformed object as per [RFC5440].  The PCE MAY also include the IRO
   in the PCErr to indicate in which case the IRO SHOULD be terminated
   immediately after the unrecognized subobject. 

> This is not clear. If I identify two domains in the sequence, the first with
> an AS subobject and the second with an Area subobject, how is this
> I think you have to clarify how this works. Isn't it the case that an area ID
> can only ever have context within a specific AS? Isn't it the case that if
> you supply an AS followed by an area you are not controlling the entry area
> to the AS? Does all that actually mean that you need the area subobject to
> carry the AS number?
> 

I have removed this text. 
Text as per another comment which describes the relationship between subobjects is added in its place. 

> I guess you mean "MAY be included by a PCC to influence the selection of the
> path".
> 

Agreed, the sentence is removed as part of handling other comment. 

> ---
> 
> In 3.5 you are repeating some material that isn't really needed because it is
> already in other documents and the IANA registry.
> 

Ack. 

> For 3.5.1.2 I have the same questions as for 3.4.1.2

See the explanation for 3.4.1.2 above. 

> You are defining behavior in this I-D for a non-compliant node. But a non-
> compliant node doesn't support this I-D!
> 
> That is, an implementation of 5440 will look at the received IRO and see the
> unknown subobject and act according to 5440 not according to this document.
> 

Similar to 3.4.2, I have updated the text. 

> additions to the PCEP ERO subobject registry when it doesn't exist! And you
> can't make changes to the RSVP ERO subobject registry in the PCE working
> group.
> 

I was trying to follow 5520 and 5553; but I have updated the section as suggested by you. 

>    subobjects, refer Section 3.4.

Sentence is removed. 

> Figure 1 has some extra pipes (|) in the ABR between area 2 and area 0.

Thanks for catching it. Updated.  

> I don't think you mean "skipped". If the AS is present it MUST be processed
> because it has to be checked.
> 

The text is updated. 

> Additionally, you have already told us that the examples are not normative.
> So:
> 

The text is updated.

> Whether this goes in section 3 (which feels natural) or in section 4 (where
> you have any number of other small normative items) is up to you, but if it
> is in section 4 you really need to make much clearer that I need to read the
> section!
> 

Thank you for the text, I have expanded and updated in section 3. 
Note that I have added some text for area subobject but removed the PKS (as that is not an IRO subobject). 

The new text in section 3 say - 

   Following processing rules apply -

   o  The Area subobject is optional.

   o  The AS subobject is optional.

   o  If an Area subobject is present then it changes the Area for all
      subsequent subobjects that do not change the area themselves.
      Subobjects that may change the Area are:

      *  IP addresses that are present in another Area (via IPv4/IPv6
         subobject)

      *  Unnumbered interfaces that are present in another Area (via
         Unnumbered Interface ID subobject)

      *  Area ID (via OSPF/ISIS area subobjects)

      *  AS number of another AS (via AS subobjects)

   o  If an Area subobject is not preceded by an AS subobject then the
      receiver MUST act as though there is no change in AS from the
      previous subobject.

   o  If an AS subobject is present then it changes the AS for all
      subsequent subobjects that do not change the AS themselves.
      Subobjects that may change the AS are:

      *  IP addresses that are present in another AS (via IPv4/IPv6
         subobject)

      *  Unnumbered interfaces that are present in another AS (via
         Unnumbered Interface ID subobject)

      *  AS number (via AS subobjects)

   o  AS and Area subobjects may be interspersed with other subobjects
      without change to the previously specified processing of those
      subobjects in the IRO.

> ---
> 
> 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.  

Status: Open.

> ---
> 
> The option for encoding the inter-AS link in section 4.3 is legitimate, but
> excessive. You do not need to show both link ends since it would be

Updated. 

> ---
> 
> I think it is fine for section 4.5 to make a reference to 7334, but it is
> wrong to do so in a way that suggests that 7334 is *the* way to do inter-
> domain P2MP path computation since that RFC describes an experiment.
> 
> In both cases, this is notwithstanding that this document is an experiment
> itself.

Updated. 

> Figure 4 has the same typo in the ABR as in Figure 1.

Ack. 

> In 4.6 "ERO Object" should be EROO :-)

Oops! Fixed. 

>    the Domain-Sequence appear as:

I see. 
I have updated the section and describe based on the example in 6805 instead. 

> ---
> 
> Section 4.7 uses "SHOULD". Under what circumstances MAY the PCE-Sequence have
> lower or equal precedence?
> 

Hmm can't think of any, looks like "MUST" is needed in this case. 
Updated. 

> ...Why don't I have to check the XRO and EXRS?

True, removed the statement.  

> Is it right to provide normative language for RSVP-TE in this document?

Fixed. 

> I thought the whole point was to impact network operations!

I see your point. Have added text.

   The mechanisms described in this document can provide the operator
   with the ability to exert control by inclusion or exclusion of domain
   subobjects.  There may be some scaling benefit when a single domain
   subobject may substitute for many subobjects and can reduce the
   overall message size and processing.

   Backward compatibility issues associated with the new subobjects
   arise when a PCE does not recognize them, in which case PCE responds
   according to the rules for a malformed object as per [RFC5440].  For
   successful operations the PCEs in the network would need to be
   upgraded.

> informational references to each other, I think it would be sensible to try
> to tie them together in the RFC Editor Queue so that they get considered
> together, so that any issues can be synchronised, and so that there are no
> surprises with code points.
> 
> Maybe a normative reference would be more in keeping with the revision to 5.1
> and 4.8 I think you should make because there is no PCEP ERO subobject
> registry.
> 

Agreed and done. 

Thanks again for a detailed review. 

The working copy is also attached, and can be uploaded post WGLC. 

Regards,
Dhruv 

> > draft-ietf-pce-pcep-domain-sequence-07. Please send your comments to
> > the PCE mailing list by Wednesday April 29.
> >
> > Thanks,
> >
> > JP & Julien
> >
> >
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> > que les pieces jointes. Les messages electroniques etant susceptibles
> > d'alteration, Orange decline toute responsabilite si ce message a ete
> > altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not
> > be distributed, used or copied without authorisation.

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 25 Apr 2015 17:48:06 +0100

Thanks for the work, Dhruv,

Many snips...

> > 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.

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.

> > experiment is

[snip]

>    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.

> > indicated that it is a "key requirement".

[snip]
 
> - remove "shortest" as suggested above.

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

[snip]

> 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.

> [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]

> 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.

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

Thanks again,
Adrian

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Tue, 28 Apr 2015 16:50:38 +0000

Hi Druhv,

I went through both Adrian's comments and update but I still have problem with section 3.4.3 , particularly "yellow" part .

Could your kindly expand a little and clarify .

Looking at the example at the end I cannot find a similar situation that make me more clear the concept.

Thanks

Sergio

" Following processing rules apply -

         subobject)

      previous subobject.

         subobject)

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: sabato 25 aprile 2015 09:21
To: Adrian Farrel
Cc: [email-masked]
Subject: Re: [Pce] PCE WG Last Call on draft-ietf-pce-pcep-domain-sequence-07

Hi Adrian,

Regards,

Dhruv

> To: [email-masked]<mailto:[email-masked]>

> Subject: Re: [Pce] PCE WG Last Call on

> draft-ietf-pce-pcep-domain-sequence-07

> While I have frequently questioned the need for this function in an

> IRO, I have done a quick review of this document. I don't guarantee to

> have found all of the issues, but I do conclude that the document is

> not ready for publication as an RFC.

> you need some more words to explain how to interleave the normal subobjects with the new ones.

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

> what the experiment is; how to confine the experiment so it doesn't

> impact other nodes or networks (see my comments on 3.4.3 and 3.5.1.2;

> what I need to do to all nodes in the experimental network; how I judge the success of the experiment.

I have added a section -

1.1.  Scope

   subobjects in PCEP.

> concept of including other constraints. I would solve this by

> accepting that "as short as possible given the other constraints" is itself just a constraint. Thus...

I can either -

Status: Open

Understood & done!

> The 2119 language in Section 3.2 doesn't seem right. You are

> describing how things are, not how things have to be. I think you can

> use just normal language.

Ack.

Ack.

> 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?

Status: Open

> you check with the chairs of the ISIS WG that this is the right reference.

Status: Open

Updated.

> non- compliant node doesn't support this I-D!

> That is, an implementation of 5440 will look at the received IRO and

> see the unknown subobject and act according to 5440 not according to this document.

The text now says -

> This is not clear. If I identify two domains in the sequence, the

> first with an AS subobject and the second with an Area subobject, how

> is this distinguished from the third case that you list?

> I guess you mean "MAY be included by a PCC to influence the selection

> of the path".

Ack.

> non- compliant node doesn't support this I-D!

> That is, an implementation of 5440 will look at the received IRO and

> see the unknown subobject and act according to 5440 not according to this document.

> I think you mean to ask IANA to make the same three assignments from

> all three registries. This text:

> But you will also need to change the text in 3.7 because you can't

> make additions to the PCEP ERO subobject registry when it doesn't

> exist! And you can't make changes to the RSVP ERO subobject registry

> in the PCE working group.

Sentence is removed.

The text is updated.

The text is updated.

         subobject)

      previous subobject.

         subobject)

      subobjects in the IRO.

Status: Open.

> The option for encoding the inter-AS link in section 4.3 is

> legitimate, but excessive. You do not need to show both link ends

> since it would be impossible to use one end of the link without using the other end!

Updated.

> inter- domain P2MP path computation since that RFC describes an experiment.

Updated.

Ack.

Oops! Fixed.

I see.

> Section 4.7 uses "SHOULD". Under what circumstances MAY the

> PCE-Sequence have lower or equal precedence?

Updated.

Fixed.

   upgraded.

> informational references to each other, I think it would be sensible

> to try to tie them together in the RFC Editor Queue so that they get

> considered together, so that any issues can be synchronised, and so

> that there are no surprises with code points.

> I guess the chairs can talk to the TEAS chairs and the ADs to make

> this happen, or you could upgrade the references to be normative.

Agreed and done.

Regards,

Dhruv

> > From: Pce [mailto:[email-masked]] On Behalf Of

> > [email-masked]<mailto:[email-masked]>

> > To: [email-masked]<mailto:[email-masked]>

> > Subject: [Pce] PCE WG Last Call on

> > draft-ietf-pce-pcep-domain-sequence-07

> > confidentielles ou privilegiees et ne doivent donc pas etre

> > diffuses, exploites ou copies sans autorisation. Si vous avez recu

> > ce message par erreur, veuillez le signaler a l'expediteur et le

> > detruire ainsi que les pieces jointes. Les messages electroniques

> > etant susceptibles d'alteration, Orange decline toute responsabilite

> > si ce message a ete altere, deforme ou falsifie. Merci.

> > If you have received this email in error, please notify the sender

> > and delete

> > As emails may be altered, Orange is not liable for messages that

> > have been modified, changed or falsified.

> > [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 29 Apr 2015 09:01:55 +0000

Hi Sergio,

Thanks for checking the proposed text.
What Adrian suggested, and I expanded on was the fact that IRO is an ordered list of network elements (subobjects) to be traversed. These IRO subobjects can be existing - IPv4, IPv6, Unnumbered Interface  as well as domain subobjects (AS and  IGP area).

The domain subobject in IRO changes the domain information associated with the next set of subobjects; till you encounter a subobject that changes the domain too.

           AS A                AS E                AS C
      <------------->      <---------->      <------------->

               A4----------E1---E2---E3---------C4
              /           /                       \
            /            /                          \
          /            /       AS B                   \
        /            /      <---------->                \
  Ingress------A1---A2------B1---B2---B3------C1---C2------Egress
        \                                    /          /
          \                                /          /
            \                            /          /
              \                        /          /
               A3----------D1---D2---D3---------C3

                           <---------->
                               AS D

Consider IRO: (AS B, B2,B3, AS C, C1, C2)
Here on processing AS B changes the AS of the subsequent subobjects till you encounter another subobject "AS C" which changes the AS for its subsequent subobjects and so forth...

IRO (AS D, D2, D3, C3)
Here as well, on processing AS D, it changes the AS of the subsequent subobjects till you encounter another subobject "C3" which changes the AS for its subsequent subobjects and so forth...
And thus an IP address that is present in another AS also changes the AS of the subsequent subobjects

Same is true for area.

If you think there is a need for text improvement, please suggest changes.
I can also add the above example in the draft, if that adds clarity.

Thanks again!

Regards,
Dhruv

From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: 28 April 2015 22:21
To: Dhruv Dhody
Cc: [email-masked]; Adrian Farrel
Subject: RE: [Pce] PCE WG Last Call on draft-ietf-pce-pcep-domain-sequence-07

Hi Druhv,

Thanks

Sergio

         subobject)

      previous subobject.

         subobject)

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: sabato 25 aprile 2015 09:21
To: Adrian Farrel
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] PCE WG Last Call on draft-ietf-pce-pcep-domain-sequence-07

Hi Adrian,

Regards,

Dhruv

I have added a section -

1.1.  Scope

   subobjects in PCEP.

I can either -

Status: Open

Understood & done!

Ack.

Ack.

Status: Open

Status: Open

Updated.

The text now says -

Ack.

Sentence is removed.

The text is updated.

The text is updated.

         subobject)

      previous subobject.

         subobject)

      subobjects in the IRO.

Status: Open.

Updated.

Updated.

Ack.

Oops! Fixed.

I see.

Updated.

Fixed.

   upgraded.

Agreed and done.

Regards,

Dhruv

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 29 Apr 2015 09:49:53 +0000

Hi Dhruv,

thanks a lot for clarifications !
I think after that I do not see any need to change text again, surely the example you put in your reply is very helpful and could be a very good improvement of the draft.

Thanks.
Regards

Sergio

From: Dhruv Dhody [mailto:[email-masked]]
Sent: mercoledì 29 aprile 2015 11:02
To: BELOTTI, SERGIO (SERGIO)
Cc: [email-masked]; Adrian Farrel; Dhruv Dhody
Subject: RE: [Pce] PCE WG Last Call on draft-ietf-pce-pcep-domain-sequence-07

Hi Sergio,

           AS A                AS E                AS C

                           <---------->
                               AS D

IRO (AS D, D2, D3, C3)

Same is true for area.

Thanks again!

Regards,
Dhruv

From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: 28 April 2015 22:21
To: Dhruv Dhody
Cc: [email-masked]<mailto:[email-masked]>; Adrian Farrel
Subject: RE: [Pce] PCE WG Last Call on draft-ietf-pce-pcep-domain-sequence-07

Hi Druhv,

Thanks

Sergio

         subobject)

      previous subobject.

         subobject)

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: sabato 25 aprile 2015 09:21
To: Adrian Farrel
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] PCE WG Last Call on draft-ietf-pce-pcep-domain-sequence-07

Hi Adrian,

Regards,

Dhruv

I have added a section -

1.1.  Scope

   subobjects in PCEP.

I can either -

Status: Open

Understood & done!

Ack.

Ack.

Status: Open

Status: Open

Updated.

The text now says -

Ack.

Sentence is removed.

The text is updated.

The text is updated.

         subobject)

      previous subobject.

         subobject)

      subobjects in the IRO.

Status: Open.

Updated.

Updated.

Ack.

Oops! Fixed.

I see.

Updated.

Fixed.

   upgraded.

Agreed and done.

Regards,

Dhruv

---

From: <[email-masked]>
Date: Thu, 30 Apr 2015 12:13:07 +0200

Hi all.

This last call has ended. Much thanks to the reviewers who provided 
feedback.

Authors, thank you for your reactivity to received comments. Please make 
sure you have addressed every expressed concerns and then publish a 
corresponding update of the I-D (including a way to address Sergio's 
comment _in the I-D_ and not only on the list).

Regards,

JP & Julien