[Gen-art] Re: Genart last call review of draft-ietf-teas-pcecc-use-cases-15

[Dhruv Dhody]

Hi Sue,

Thanks for your review.


On Fri, May 24, 2024 at 12:32 AM Susan Hares via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Susan Hares
> Review result: Ready with Issues
>
> GEN-ART review
>
> Status: Ready with Issues
> Type of issues: Technical issues + Editorial issues
>
> General Comment: The authors should be commended for undertaking the
> massive challenge of collecing the use cases for a PCE as a Central
> Controller.
> This work will help guide future PCE work and interactions with other
> protocols.
>
>



> Summary of technical issues:
>
> 1. BGP interactions are skipped in this document except for section 3.5
>Section 3.5 does not clearly indicate the BGP Peer relationships with
> the RR.
>Interactions of the PCE with the BGP Flow specification should be
> consider in
>the PCE discussion for IP Native, SFC, SR, and Best Effor tPaths.
>
>
Dhruv: I have added some text. Also added a disclaimer - "It is interesting
to note that some of the use cases listed can also be supported via BGP
instead of PCEP. However, within the scope of this document, the focus is
on the use of PCEP."



> 2.  SRPM calculations to calculate Active Policy from a set of Candidate SR
> Policy is not clearly mentioned
>
>
Dhruv: Added "Note that an SR Policy can be associated with multiple
candidate paths. A candidate path is selected when it is valid and it is
determined to be the best path of the SR Policy as described in ."



> 3.  Clear delination of which forwarding is being used IP native, IP native
> over MPLS, SR-MPLS, or SRv6
> is critical at each section.  See editorial issues for the issues I
> found.
>
>
Dhruv: The text has been updated, thanks for pointing out.



> 4.  The inclusion of individual drafts in the informative text is
> beneficial,
> but
> care must be taken to indicate whether the PCE WG is going to adopt any
> particular solution.
>
>
Dhruv: Some of them are in the adoption queue but that does not guarantee
they would gain consensus. I have made updates and made sure that those
references remain informative-useful-pointers without claiming to be
definitive extensions.



>
> Editorial
> 1. Abstract, general comment
>
> The abstract is 3 paragraphs which is 1 paragraph longer than normal.
> The authors might look at shortening this abstract.
>
>
Dhruv: It borrows the structure from the related RFCs 8283 and 9050. I
prefer keeping it in the same framing if that's okay.



> 2. Abstract, paragraph 2,
>
> Issue:  English Grammar, clarity
> Old text: /
>SDN has much broader applicability than signal MPLS traffic-
>engineered (TE) paths and the PCE may be used to determine paths in a
>range of use cases including static Label Switched Paths (LSPs),
>Segment Routing (SR), Service Function Chaining (SFC), and most forms
>of a routed or switched network.  /
>
> New text: /
>SDN has much broader applicability than just signaling MPLS traffic-
>engineered (TE) paths.  The PCE functions may be used to determine paths
>in a range of use cases including static Label Switched Paths (LSPs),
>Segment Routing (SR), Service Function Chaining (SFC), and most forms
>of a routed or switched network.  /
>
>
Dhruv: I aligned it to RFC8283.



> 3. introduction, paragraph 1
> Issue: Grammar, clarity.
>
> Old text: / The role and function of PCE have grown to cover several
>other uses (such as GMPLS [RFC7025], Multicast), and to allow
>delegated stateful control [RFC8231] and PCE-initiated use of network
>resources [RFC8281]./
>
> Old text: / The role and function of PCE have grown to cover several
>other uses (such as GMPLS [RFC7025] or Multicast), and to allow
>delegated stateful control [RFC8231] and PCE-initiated use of network
>resources [RFC8281]./
>
>
Ack



> 4. Terminology:
>
> I suggest you add the following definitions to aid readability.
>
> Centralized Controller, BGP-LS [RFC9952], SR, Failure recovery, node-SID,
> Adj-SID, LSP PST, SRGB, SRLB, failure recovery,
>
>
Dhruv: I have added a few of these.



> 5. Title in 3.1
>
> old title:/ PCEEC for Label Management/
> New title:/ PCE for MPLS Label Management/
>
>
Ack



> 6. section 3.1, paragraph 3,
> Why: Need reference for BGP-LS
> old text:/
>  The full SRGB/SRLB of a node could be learned via existing
>IGP or BGP-LS mechanisms too./
>
>  New text:/
>   The full SRGB/SRLB of a node could also be learned via existing
>IGP or BGP-LS [RFC9552] mechanisms./
>
>
Ack



> 7. section 3.2, paragraph 1.
>
> Why: provide reference to Segment routing the first time used.
>
> old text:/Segment Routing (SR) leverages the source routing paradigm./
> New text:/Segment Routing (SR) [RFC8402] leverages the source routing
> paradigm.
> /
>
>
Ack



> 8. section 3.2 paragraph 2,
>
> issue: Missing reference to inter-domain.  SR and the rest of the document
> mentions inter-domain.  It should be added here for clarity.
>
> Old text:/
>A database of segments can 

Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-pce-pceps-tls13-02

[Dhruv Dhody]

Hi Christer,

On Tue, Dec 12, 2023 at 1:05 AM Russ Housley  wrote:

> Hi Christer.
>
> >> Section 2.3 of RFC 8446 explains that the security provided to early
> data is
> >> weaker than
> >> the security provided to other kinds of TLS data.  This is the reason
> that
> >> PCEPS MUST NOT
> >> make use of early data.  Will a note with a pointer to this text (or a
> >> pointer to the same part
> >> of draft-ietf-tls-rfc8446bis) resolve this minor issue?
> >
> > The second Note already points to the text in Section 2.3 of 8446. My
> issue is
> > not the fact that early data security is weaker, but why that is an
> issues for
> > PCEPS. Is there some specific property of requirement for PCEPS behind
> the
> > MUST NOT?
>
> We are simply saying that PCEPS MUST NOT use early data.  We could not
> find a case where it is needed today, and we are concerned that sone future
> evolution of PCEPS might use it without understanding the associated
> security risk.
>
>
Dhruv: And the same guidance has been issued in RFC9190
and draft-ietf-netconf-over-tls13 (past IETF LC).

Thanks!
Dhruv



> Russ
>
>
> >> On Dec 8, 2023, at 6:51 AM, Christer Holmberg via Datatracker
> >>  wrote:
> >>
> >> Reviewer: Christer Holmberg
> >> Review result: Almost Ready
> >>
> >> 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
> >>
> >> .
> >>
> >> Document: draft-ietf-pce-pceps-tls13-02
> >> Reviewer: Christer Holmberg
> >> Review Date: 2023-12-08
> >> IETF LC End Date: 2023-12-19
> >> IESG Telechat date: Not scheduled for a telechat
> >>
> >> Summary: The document is well written, and easy to understand. I do
> >> have one Minor issue/question and a few Editorial issues/questions
> >> that I would like the authors to address.
> >>
> >> Major issues: N/A
> >>
> >> Minor issues:
> >>
> >> Q1:Section 3 adds text saying that PCEPS implementations MUST NOT use
> >> early data, and there are a couple of notes about what early data is.
> >> However, I cannot find text which explains the "MUST NOT use". If the
> >> case where early media is permitted does not apply to PCEPS it would
> >> be good to add text which explains it. It would also be good to
> >> explain the reason in the Introduction of this document.
> >>
> >> Nits/editorial comments:
> >>
> >> Q2:In a few places the text says "TLS protocol", and in other places
> "TLS".
> >> Would it be possible to use "TLS" everywhere?
> >>
> >> Q3: Section 6 indicates that there are no known implementations when
> >> version
> >> -02 of the draft was posted. If that is still the case when the RFC is
> >> published, could the whole section be removed?
> >>
> >> Q4: Related to Q3, if the section remains (e.g., because there are
> >> known implementations), I suggest to say "time of publishing this
> >> document" instead of "time of posting of this Internet-Draft".
> >>
> >>
> >> --
> >> last-call mailing list
> >> last-c...@ietf.org
> >> https://www.ietf.org/mailman/listinfo/last-call
> > --
> > last-call mailing list
> > last-c...@ietf.org
> > https://www.ietf.org/mailman/listinfo/last-call
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-pce-association-diversity-10

[Dhruv Dhody]

Hi Alissa,

An update has been posted that makes changes based on the genart
review by the authors -
https://www.ietf.org/rfcdiff?url1=draft-ietf-pce-association-diversity-10=draft-ietf-pce-association-diversity-12

A response to the Dale's email discussing these changes is pending.

Dhruv


On Wed, Oct 30, 2019 at 9:09 PM Alissa Cooper  wrote:
>
> Thanks Dale. I entered a DISCUSS ballot to chat about a couple of your major 
> points below and requested a response to the rest of your review.
>
> Alissa
>
>
> > On Oct 12, 2019, at 8:04 PM, Dale Worley via Datatracker  
> > wrote:
> >
> > Reviewer: Dale Worley
> > Review result: Ready with Issues
> >
> > 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
> >
> > .
> >
> > Document:  draft-ietf-pce-association-diversity-10
> > Reviewer:  Dale R. Worley
> > Review Date:  2019-10-12
> > IETF LC End Date:  2019-10-18
> > IESG Telechat date:  not known
> >
> > Summary:
> >
> >   This draft is on the right track but has open issues, described
> >   in the review.
> >
> > There are various exposition issues, as detailed below.
> >
> > There are some minor technical issues about reporting of error
> > conditions, the significance of the P bit in DISJOINTNESS-STATUS-TLV,
> > the detailed definition of the new objective functions, etc. as
> > detailed below.
> >
> > But it seems like a number of complex cases haven't been clearly
> > specified:  (1) the effect of the P bit if multiple LSPs have P=1, (2)
> > the interaction of SVEC and disjoint-groups, and (3) the interaction
> > of partially overlapping disjoint-groups and/or SVEC sets.
> >
> > Major issues:
> >
> > The relationship of this mechanism with SVEC seems to be important but
> > is not clearly stated.  The relevant sections of the text seem to be:
> > section 4 para 2, section 5.3, and section 5.4 from "[RFC5440] uses
> > SVEC diversity flag" on.  I think that they need to be pulled into one
> > section.  Then it will be possible to have a good description of the
> > interaction with SVEC.
> >
> > At the end of section 5.6 is the revelation that (1) the
> > DISJOINTNESS-CONFIGURATION-TLV is not attached to a group (in some
> > sense), but instead a separate copy of it is attached to every LSP in
> > the group, (2) these copies must match in the group IDs they carry and
> > also the T, S, N, and L flags in them must agree, (3) (I suspect) any
> > OF-code must agree, and (4) the P flags in them may differ.  This
> > information is needed as background for a number of parts of the text
> > to make sense, particularly the description of the P bit in section
> > 5.2 and section 5.5.  I recommend that the last para of section 5.5 be
> > moved to section 5.1 or the beginning of section 5.2, so the reader is
> > aware that the descriptions of each LSP carry separate, and not
> > necessarily identical, DISJOINTNESS-CONFIGURATION-TLVs.
> >
> > The path computation effects of the P bit are described in the "P"
> > item in section 5.2 and section 5.5.  But the descriptions are
> > unclear, or perhaps they presume that there are only two LSPs in the
> > group.  I think the intended meaning is that all of the LSPs in the
> > group with P=1 are computed first, and then with those LSPs fixed, the
> > LSPs in the group with P=0 are computed.  This will cause
> > shortest-path constraints (and other objective functions) to be
> > optimized on the P=1 LSPs, and those paths will not be de-optimized by
> > competition from the other paths.  This should probably be pulled out
> > of the description of the "P" in its TLV and put into a separate
> > paragraph.
> >
> > Minor issues:
> >
> > Nits/editorial comments:
> >
> > In general, check the uses of "could" and "would".  I think "would" is
> > sometimes used to mean "... in that situation, the XXX MUST ...", and
> > "could" is sometimes used where "MAY" would be clearer.
> >
> > The running title is given as "ASSOC-DISJOINT".  I think "PCEP
> > Diversity Constraint Signaling" would be clearer.
> >
> > Abstract
> >
> >   The proposed extension allows a Path Computation Client (PCC) to
> >   advertise to a PCE that a particular LSP belongs to a
> >   disjoint-group, thus the PCE knows that ...
> >
> > It would be clearer if "a disjoint-group" was amplified to "a
> > particular disjoint-group".
> >
> > Table of Contents
> >
> > There are a few section titles in which important words aren't
> > capitalized ("functions" in section 5.4), or unimportant words are
> > capitalized ("On" in sections 8.5 and 8.6).
> >
> > The title of section 8.4 is a verb phrase, compared to the titles of
> > the other subsections of section 8.  I suggest "Verification of
> > Correct Operations" or maybe 

Re: [Gen-art] Genart last call review of draft-ietf-pce-lsp-control-request-08

[Dhruv Dhody]

Hi Francesca,

Thanks for your review. Few thoughts...

On Mon, Aug 26, 2019 at 5:44 PM Francesca Palombini via Datatracker
 wrote:
>
> Reviewer: Francesca Palombini
> Review result: Ready with Issues
>
> 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
>
> .
>
> Document: draft-ietf-pce-lsp-control-request-08
> Reviewer: Francesca Palombini
> Review Date: 2019-08-26
> IETF LC End Date: 2019-08-28
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: This draft is almost ready for publication, but has minor issues/open
> points that should be fixed before publication.
>
> Major issues: N/A
>
> Minor issues / questions:
>
> * Section 3: At the end of season 3, you indicate that this new flag has no
> meaning in PCRpt and PCInitiate messages. RFC8231 defines that the SRP Object
> MAY be carried in PCErr as well, shouldn't there be such requirements (MUST be
> set to 0, MUST be ignored on reception) for PCErr?
>

I agree. I suggest to make this generic, something like - "The C Flag
has no meaning in other PCEP messages that carry SRP object and the
flag MUST be set to 0 on transmission and MUST be ignored on receipt."

> * In the following text (Section 4): "The PCE SHOULD NOT
>send control request for LSP which is already delegated to the PCE,
>i.e. if the D Flag is set in the PCUpd message, then C Flag SHOULD
>NOT be set." Why is there a SHOULD NOT instead of MUST NOT? In which
>situation could it be acceptable or useful to request control for a
>delegated LSP?
>

It wont be useful, but if received it would be silently ignored. It
does not rise up to a high level of error and I suspect that is why
authors used SHOULD.

> Nits/editorial comments:
>

Thanks for these, just one comment ...

> * Terminology should also include a sentence about the reader being familiar
> with at least RFC8231.
>
> * Terminology could also include what SRP stand for.
>
> * Section 3. When introducing SRP, it would have been helpful to the reader to
> reference section 7.2 of RFC8231.
>
> * Section 3. "PCE sets the C Flag to 1 to indicate that, it wishes" -- remove
> ","
>
> * Section 3. "MUST be ignored on receipt" -- "MUST be ignored on reception"
>

I have noticed 'on receipt' in many of our documents. We should leave
this one for the RFC-EDITOR maybe...

> * Section 4. When introducing the D flag, it would have been helpful to the
> reader to reference section 7.3 of RFC8231.
>
> * Section 4. "Note that, the PCUpd message with C Flag set is received" --
> "Note that, if the PCUpd message with C Flag set is received"
>
> (Please keep my address in the To: field if you want to make sure I see any
> response to this thread)
>
> Thanks,
> Francesca
>

Thanks again for your review.

Regards,
Dhruv

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-pce-stateful-path-protection-08

[Dhruv Dhody]

Hi Pete,

Thanks for your review and nits. Just snipping to two points...

> OLD
>  |   PT  | Path Protection Association Flags |S|P|
> NEW
>  |   PT  |Unassigned |S|P|
>

I feel it is important to keep the name "flags" in the figure to match
with the text following the figure. Also this seems to be our usual
practice in past documents as well. We can change to just "flags" if
you would prefer that?

For context ->

   The format of the Path Protection Association TLV (Figure 1) is as
   follows:

 0   1   2   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type = TBD2 |  Length |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   PT  | Path Protection Association Flags |S|P|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Figure 1: Path Protection Association TLV format

   Path Protection Association Flags (32 bits) - The following flags are
   currently defined -

  Protecting (P): 1 bit - This bit is as defined in Section 14.1 of
  [RFC4872] to indicate if the LSP is working or protection LSP.

  Secondary (S): 1 bit - This bit is as defined in Section 14.1 of
  [RFC4872] to indicate if the LSP is primary or secondary LSP.  The
  S flag is ignored if the P flag is not set.

  Protection Type (PT): 6 bits - This field is as defined in
  Section 14.1 of [RFC4872] to indicate the LSP protection type in
  use.

  Unassigned bits are considered reserved.  They MUST be set to 0 on
  transmission and MUST be ignored on receipt.


> Section 6:
>
> At the top of the section, I suggest putting in the following:
>
> [Note to RFC Editor and IANA: Sections 3.1, 3.2, and 4.5 contain "TBD1" 
> through
> "TBD5" those should be replaced by the values that IANA assigns. Also, Section
> 4.5 includes several occurrences of the phrase "(Early allocation by IANA)";
> please confirm that the value mentioned there is correct and delete that 
> phrase
> from the document before publication.]
>

I would suggest the authors to remove the phrase "(Early allocation by
IANA)" in the document now as the referenced draft is in RFC-EDITOR
queue and the early allocation tag is removed in the IANA page -
https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects

Thanks!
Dhruv

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-pce-stateful-pce-auto-bandwidth-10

[Dhruv Dhody]

Hi Erik,

Thank you for your review and suggestions. We will update in the next revision.

Thanks!
Dhruv

On Wed, Aug 28, 2019 at 7:28 AM Erik Kline via Datatracker
 wrote:
>
> Reviewer: Erik Kline
> Review result: Ready with Nits
>
> 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
>
> .
>
> Document: draft-ietf-pce-stateful-pce-auto-bandwidth-10
> Reviewer: Erik Kline
> Review Date: 2019-08-27
> IETF LC End Date: 2019-08-28
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
>
> Gentle reminder for the authors to double-check all the lower case "should"s,
> "required"s, and "must not"s (etc) to make sure it's not important that they 
> be
> capitalized (since the case-sensitive requirements text is referenced).
>
> Major issues:
>
> Minor issues:
>
> Nits/editorial comments:
>
> There are some periodic grammatical changes that I think would be nice, but I
> assume that can get sorted out with the RFC editor.
>
> Two random things I'll note:
>
> Section 1> I can't find "Path Control Element" in RFC 5440. Should this be
> "Path Computation Element"?
>
> Section 5.2>
> .  s/speaker wish to disable/speaker wishes to disable/
> .  s/of same type/of the same type/
>

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-pce-stateful-hpce-11

[Dhruv Dhody]

Hi Paul,

Thanks for your review, please see inline...

On Tue, Aug 20, 2019 at 9:58 PM Paul Kyzivat  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
>
> .
>
> Document: draft-ietf-pce-stateful-hpce-11
> Reviewer: Paul Kyzivat
> Review Date: 2019-08-20
> IETF LC End Date: 2019-08-28
> IESG Telechat date: ?
>
> Summary:
>
> This draft is basically ready for publication, but has nits that should
> be fixed before publication.
>
> Issues:
>
> Major: 0
> Minor: 0
> Nits:  7
>
> 1) NIT: No glossary
>
> Since I am not familiar with the subject domain, when I started reading
> this document I felt I was lost among the acronyms. While you are good
> at defining these at first use, I couldn't keep them all in mind as I
> read. I had to create my own glossary to support me while reading. I
> would really appreciate having a glossary in the document.
>

Added.

> 2) NIT: Inconsistent terminology
>
> In section 3 two pairs of terms are introduced: (C-E / E-C) and (EC-EP /
> EP-EC). IIUC in the first pair "E" stands for "PCE" while in the second
> pair "E" seems to stand for "Extended", while "P" stands for PCE. I
> found this very confusing. I think it would be better to allow "E" to
> mean the same thing in both pairs. Perhaps you could use "X" to stand
> for "eXtended". Then there would be clear parallels:
>
> C -> XC
> E -> XE
>
> Please consider doing something relieve the confusion.
>

The use of notation C-E and E-C is as per RFC 8231
https://tools.ietf.org/html/rfc8231#section-4 where PCC to PCE is
(C-E) and PCE to PCC is (E-C). In this document we wanted to represent
messages between C-PCE (child PCE) to P-PCE (parent PCE) and we used
EC-EP for it and the reverse EP-EC for P-PCE to C-PCE communication.

This was discussed during shepherd review as well (as we were using CE
and PE before but that was causing confusion because of the well known
meaning of those terms in routing).

I would like to keep the existing notations that has WG support.

> 3) NIT: Badly formed sentence
>
> I can't parse this sentence in section 3.1:
>
> Procedures as described in [RFC6805] are applied and where the
> ingress C-PCE (Child PCE), triggers a path computation request for
> the LER in the domain where the LSP originates, sends a request to
> the P-PCE.
>
> Can you rephrase it?
>

Updated.

> 4) NIT: Unclear text
>
> In section 3.1 are steps A/B/C/D to be added at the *end*, after step
> 11? It would help to be explicit.
>
> In step (C) of section 3.2, can you please be explicit about which node
> is to execute these elements? I think it is PCE5, but I'm not certain.
>

Updated.

> 5) NIT: Unlinked references
>
> Some RFC references (e.g. [RFC8051] and [RFC8231] in section 1.1, and
> [RFC8232] in section 3.1) are not linked in the HTML version. I suggest
> a global search for all such unlinked references in the source.
>

The HTML version of the draft is automatically generated from the text
version. The `rfcmarkup` is used to render the HTML of the I-D/sRFCs.
Specifically, rfcmarkup produces the final HTML using heuristics from
the source TXT and this is beyond the control of the authors.

> 6) NIT: Bad reference link
>
> In the following from section 3.1:
>
> Steps 1 to 11 are exactly as described in section 4.6.2 (Hierarchical
> PCE End-to-End Path Computation Procedure) of [RFC6805], the
>
> the "section 4.6.2" is linked to the non-existent section 4.6.2 of
> *this* document rather than RFC6805.
>
> A similar link to the same spot in section 3.2 is ok.
>

I arranged the words so that rfcmarkup works.

> 7) NIT: Outdated references:
>
> IdNits reports outdated references. I trust these will be updated in due
> course.
>

Updated.

Working Copy: 
https://github.com/dhruvdhody/ietf/blob/master/draft-ietf-pce-stateful-hpce-12.txt
Diff: 
https://tools.ietf.org/rfcdiff?url1=draft-ietf-pce-stateful-hpce-11=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-stateful-hpce-12.txt

Thanks!
Dhruv

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-pce-association-group-09

[Dhruv Dhody]

Hi Meral,

Thanks for your review.

> Nits/editorial comments:
>
> It could help to clarify if this proposal brings any new requirements on 
> existing LSP OAM/path protection techniques, or brings the need for 
> extensions.

Associating LSPs together to form a association group in the context
of PCEP does not have any impact on the OAM. This association is in
the context of LSP path computation and does not impact the data
plane.

Regarding the impact on path protection, it is best to discuss that in
the context of draft-ietf-pce-stateful-path-protection, where the
association-type for path protection is defined. That document is
under shepherd review and it would be wise to add some text there. I
have added the draft authors in cc to consider this.

Regards,
Dhruv

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [Pce] Genart last call review of draft-ietf-pce-rfc6006bis-03

[Dhruv Dhody]

Hi Roni, 

I would like to keep the text, thus I have added more description regarding 
yang. 

   The PCEP YANG model "ietf-pcep" is specified in [I-D.ietf-pce-pcep-
   yang]. The P2MP capability of a PCEP entity or a configured peer, can
   be set using this YANG model. Also the support for P2MP path
   computation can be learned using this model. The statistics are
   maintained in the model "ietf-pcep-stats" as specified in [I-D.ietf-
   pce-pcep-yang]. This YANG model will be required to be augmented to
   also include the P2MP related statistics.

Hope this works? 

Regards,
Dhruv

Working copy: 
https://github.com/dhruvdhody-huawei/ietf/blob/master/draft-ietf-pce-rfc6006bis-04.txt


> -Original Message-
> From: Roni Even
> Sent: 19 August 2017 19:51
> To: Dhruv Dhody <dhruv.dh...@huawei.com>; Roni Even
> <ron.even@gmail.com>; gen-art@ietf.org
> Cc: draft-ietf-pce-rfc6006bis@ietf.org; p...@ietf.org; i...@ietf.org
> Subject: RE: [Pce] Genart last call review of draft-ietf-pce-rfc6006bis-03
> 
> Hi,
> I did not see the text in RFC6006bis but this current text does not say
> much. If there is some work to reference in PCE  like pce-pcep-yang then
> add it otherwise I suggest to delete this sentence Roni
> 
> > -Original Message-
> > From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Dhruv
> > Dhody
> > Sent: יום ה 17 אוגוסט 2017 12:06
> > To: Roni Even; gen-art@ietf.org
> > Cc: draft-ietf-pce-rfc6006bis@ietf.org; p...@ietf.org;
> > i...@ietf.org
> > Subject: Re: [Gen-art] [Pce] Genart last call review of
> > draft-ietf-pce-
> > rfc6006bis-03
> >
> > Hi Roni,
> >
> > Thanks for your comments. See inline...
> >
> > > -Original Message-
> > > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Roni Even
> > > Sent: 13 August 2017 19:18
> > > To: gen-art@ietf.org
> > > Cc: draft-ietf-pce-rfc6006bis@ietf.org; p...@ietf.org;
> > > i...@ietf.org
> > > Subject: [Pce] Genart last call review of
> > > draft-ietf-pce-rfc6006bis-03
> > >
> > > Reviewer: Roni Even
> > > Review result: Ready with Nits
> > >
> > > 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
> > >
> > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> > >
> > > Document: draft-ietf-pce-rfc6006bis-??
> > > Reviewer: Roni Even
> > > Review Date: 2017-08-13
> > > IETF LC End Date: 2017-08-24
> > > IESG Telechat date: 2017-08-31
> > >
> > > Summary: The document is ready for publication as standard track RFC
> > >
> > > I read all the document and also did a compare with RFC6006 to look
> > > at the changes.
> > >
> > > Major issues:
> > >
> > > Minor issues:
> > >
> > > Nits/editorial comments:
> > >
> > > 1. In section 4.2 I am not sure why is this sentence there, is it
> > > for the current yang document or for a future one. Why have it at
> > > all?-"The PCEP YANG module [I-D.ietf-pce-pcep-yang] can be extended
> > > to also include the P2MP related parameters."
> > >
> > [[Dhruv Dhody]] The text around MIB existed from RFC6006. Since then
> > the focus has shifted to Yang.
> > We wanted to keep this text about Yang to reflect that.
> >
> > How about we reword to -
> >
> >The PCEP YANG model is specified in [I-D.ietf-pce-pcep-yang]. The
> >YANG models can be augmented to also include the P2MP related
> >parameters.
> >
> > Thanks again for your review.
> >
> > Regards,
> > Dhruv
> >
> > Working Copy - https://github.com/dhruvdhody-
> > huawei/ietf/blob/master/draft-ietf-pce-rfc6006bis-04.txt
> >
> >
> >
> > >
> > > ___
> > > Pce mailing list
> > > p...@ietf.org
> > > https://www.ietf.org/mailman/listinfo/pce
> >
> > ___
> > Gen-art mailing list
> > Gen-art@ietf.org
> > https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [Pce] Genart last call review of draft-ietf-pce-rfc6006bis-03

[Dhruv Dhody]

Hi Roni, 

Thanks for your comments. See inline...

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Roni Even
> Sent: 13 August 2017 19:18
> To: gen-art@ietf.org
> Cc: draft-ietf-pce-rfc6006bis@ietf.org; p...@ietf.org; i...@ietf.org
> Subject: [Pce] Genart last call review of draft-ietf-pce-rfc6006bis-03
> 
> Reviewer: Roni Even
> Review result: Ready with Nits
> 
> 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
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-pce-rfc6006bis-??
> Reviewer: Roni Even
> Review Date: 2017-08-13
> IETF LC End Date: 2017-08-24
> IESG Telechat date: 2017-08-31
> 
> Summary: The document is ready for publication as standard track RFC
> 
> I read all the document and also did a compare with RFC6006 to look at the
> changes.
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> 1. In section 4.2 I am not sure why is this sentence there, is it for the
> current yang document or for a future one. Why have it at all?-"The PCEP
> YANG module [I-D.ietf-pce-pcep-yang] can be extended to also include the
> P2MP related parameters."
> 
[[Dhruv Dhody]] The text around MIB existed from RFC6006. Since then the focus 
has shifted to Yang. 
We wanted to keep this text about Yang to reflect that.  

How about we reword to - 

   The PCEP YANG model is specified in [I-D.ietf-pce-pcep-yang]. The
   YANG models can be augmented to also include the P2MP related
   parameters.

Thanks again for your review. 

Regards,
Dhruv

Working Copy - 
https://github.com/dhruvdhody-huawei/ietf/blob/master/draft-ietf-pce-rfc6006bis-04.txt



> 
> ___
> Pce mailing list
> p...@ietf.org
> https://www.ietf.org/mailman/listinfo/pce

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [Pce] Genart last call review of draft-ietf-pce-pceps-14

[Dhruv Dhody]

Hi Dale, 

> -Original Message-
> From: Dale R. Worley [mailto:wor...@ariadne.com]
> Sent: 02 August 2017 08:10
> To: Dhruv Dhody <dhruv.dh...@huawei.com>
> Cc: gen-art@ietf.org; draft-ietf-pce-pceps@ietf.org; p...@ietf.org;
> i...@ietf.org; dhruv.i...@gmail.com
> Subject: Re: [Pce] Genart last call review of draft-ietf-pce-pceps-14
> 
> Dhruv Dhody <dhruv.dh...@huawei.com> writes:
> >> It's more complicated than that:  If a PCE does not like the first
> >> message it receives, if it implements PCEPS, it replies TBA2/2.  But
> >> if it does not implement PCEPS, it replies 1/1.  Similarly, a PCC may
> >> reject an initial message with either of these error codes, depending
> >> on the situation.  If the other endpoint does not implement PCEPS, it
> >> might be surprised by receiving TBA2/2, which it has no way of
> >> understanding in detail (although it will probably simply disconnect,
> >> which is what it would do in reaction to a 1/1).
> >>
> > [[Dhruv Dhody]] You are right about this case, which I have clarified
> > now -
> >
> >If the PCEP speaker that only supports PCEPS connection (as a local
> >policy), receives an Open message, it MUST treat it as an unexpected
> >message and reply with a PCErr message with Error-Type set to 1 (PCEP
> >session establishment failure) and Error-value set to 1 (reception of
> >an invalid Open message or a non Open message).
> >
> > In your description you mentioned the error TBA2/2, but the
> > description of TBA2/2 is  -
> >
> >A PCEP
> >speaker receiving any other message apart from StartTLS, Open, or
> >PCErr as the first message, MUST treat it as an unexpected message
> >and reply with a PCErr message with Error-Type set to [TBA2 by IANA]
> >(PCEP StartTLS failure) and Error-value set to 2 (reception of any
> >other message apart from StartTLS, Open, or PCErr message), and MUST
> >close the TCP connection.
> >
> > So receiving of open message would not trigger this error. The new
> > text above would take care of that.
> 
> I don't know if the case I'm thinking of is important enough to change
> anything for, but I think it should at least be thought about.
> 
> I'm considering the situation where the TCP connection is started, and one
> endpoint receives a message that it does not understand.  Not the case
> where a non-implementing endpoint receives a StartTLS, but where the
> message is entirely incorrect, and is neither Open nor StartTLS, or at
> least, is sufficiently malformed that the receiver cannot parse it as one
> of those message types.
> 
> Of course, this situation should never happen, but I expect that it is
> occasionally seen, and it would be useful if it was handled in a way that
> would make it easier for the humans involved to diagnose the problem.
> 
> If the receiver of the message does not implementing PCEPS, it will send
> error 1/1.  The receiver of the error (the sender of the message) will
> receive 1/1, and will "understand" it and log it as something requiring
> human intervention -- whether or not it implements PCEPS.
> 
> OTOH, if the receiver of the message implements PCEPS, it will send error
> TBA2/2.  If the receiver of the error (the sender of the message)
> implements PCEPS, it will understand it and log it as something requiring
> human intervention.  However, if the receiver does not implement PCEPS, it
> won't understand the error message, and will have to log it as "I received
> an unknown error message".  Of course, human inquiry will reveal that the
> error message was a PCEPS error message, and its meaning is "unknown
> initial message", getting us back to the previous situation.  But it seems
> to me that this is adding a step of human processing where it could be
> avoided, and that better performance (of the humans and the system as a
> whole) would be achieved in practice if a PCEPS implementation, when it
> received an initial message that was not Open or StartTLS, sent a 1/1
> error in the same way as a non-PCEPS implementation.
> 
> Dale
[[Dhruv Dhody]] I have added this in the backward compatibility session to note 
this concern - 

   Note that, a PCEP implementation that support PCEPS would respond
   with PCErr message with Error-Type set to [TBA2 by IANA] (PCEP
   StartTLS failure) and Error-value set to 2 if any other message is
   sent before StartTLS or Open.  If the sender of the invalid message
   is a PCEP implementation that does not support PCEPS, it will not be
   able to understand this error.  A PCEPS implementation could also
   send the PCErr message as per [RFC5440] with Error-Type "PCEP session
   establishment failure" and Error-value "reception of an invalid Open
   message or a non Open message" before closing the session.

Regards,
Dhruv

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [Pce] Review of draft-ietf-pce-stateful-pce-18

[Dhruv Dhody]

Hi Joel, 

In my opinion the motivation behind section 5.8.2 is to make sure that, if a 
PCC needs to request a path to be computed by PCE immediately, PCC should use 
the existing PCReq message to achieve that. 
 
Can the PCC delegate an unsignalled LSP to PCE via PCRpt message? In my 
interpretation it can, in some cases[1]. I would let the authors confirm on 
this. 

Thanks,
Dhruv

[1] https://mailarchive.ietf.org/arch/msg/pce/bexK_Nc2wHgQzV-XUC8lqMec8zY

> -Original Message-
> From: Joel M. Halpern [mailto:j...@joelhalpern.com]
> Sent: 17 February 2017 10:13
> To: Dhruv Dhody <dhruv.dh...@huawei.com>; gen-art@ietf.org
> Cc: draft-ietf-pce-stateful-pce@ietf.org; p...@ietf.org; i...@ietf.org
> Subject: Re: [Pce] Review of draft-ietf-pce-stateful-pce-18
> 
> So it is intentional that this draft prohibits that behavior (PCE driven
> establishment)?
> 
> Yours,
> Joel
> 
> On 2/16/17 11:35 PM, Dhruv Dhody wrote:
> > Hi Joel,
> >
> > Regarding your comment -
> >
> >> Is the intention to prohibit the driving of LSP creation from the
> >> PCE?
> >
> > This capability is described in -
> > https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-07
> > (document expired recently, authors should refresh it)
> >
> > Thanks,
> > Dhruv
> >
> >> -Original Message-
> >> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Joel Halpern
> >> Sent: 17 February 2017 09:08
> >> To: gen-art@ietf.org
> >> Cc: draft-ietf-pce-stateful-pce@ietf.org; p...@ietf.org;
> >> i...@ietf.org
> >> Subject: [Pce] Review of draft-ietf-pce-stateful-pce-18
> >>
> >> Reviewer: Joel Halpern
> >> Review result: Ready with Issues
> >>
> >> 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
> >>
> >> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> >>
> >> Document: draft-ietf-pce-stateful-pce-??
> >> Reviewer: Joel Halpern
> >> Review Date: 2017-02-16
> >> IETF LC End Date: 2017-02-28
> >> IESG Telechat date: 2017-03-16
> >>
> >> Summary:
> >>
> >> Major issues:
> >>
> >> Minor issues:
> >>At the end of section 5.4, the text talks about a PCE accepting
> >> status updates even if the  stateful capability has not been
> >> negotiated.  Which is fine.  But as written, the text seems to say
> >> that doing so means that the PCE will be able to "build and maintain
> >> an up to date view of the state of the PCC's LSPs".  However, if the
> >> capability has not been negotiated, I do not see how the PCE can
> >> count on getting full and timely state reports.  Trying to infer why
> >> a PCC is sending such a report in the absence of the agreement seems
> problematic.
> >>
> >> This comment may be a misunderstanding or mis-expectation on my part.
> >> I would have expected one of the ways o using an active PCE is to
> >> have the PCE decide (under suitable circumstances) that an LSP is
> >> needed between two PCCs.  As far as I can tell, the text in section
> >> 5.8.2 and 5.8.3 prohibits that.  A PCE is only allowed to send an LSP
> >> Update Request (in a PCUpd message) for an LSP that has been
> >> delegated to it.  At that point I thought that a PCC could delegate a
> >> block of unsetup LSPs to the PCE.  But then looking at 5.8.2, the
> >> text states that for each delegation, the PCC must request an initial
> >> path.  That seems to prohibit delegating a block of LSPs for future
> >> updates.  Is the intention to prohibit the driving of LSP creation from
> the PCE?
> >>
> >> I have looked but I can not find the text explaining the
> >> significance and use of the Symbolic path name.  It is mandated by
> >> the draft.  There seems to be an implicit assumption taht it is
> >> needed by the PCE.  If the explanation of how or why it is needed is not
> present, it should be.
> >>
> >> Nits/editorial comments:
> >> Should the text on the S bit in section 7.3 (the LSP Object
> >> definition) note that it should be set to 0 on all messages sent by the
> PCE?
> >> Should that also be stated for the R bit?  And the O bits?
> >>
> >>   Section 9.2 seems very odd.  It states that the IETF "SHOULD" do
> >> some additional work.  I understand why teh work is needed.  But this
> >> does not seem to match the RFC 2119 meaning of SHOULD as it does not
> >> apply to eitehr the implementor or the implementation.
> >>
> >>
> >> ___
> >> Pce mailing list
> >> p...@ietf.org
> >> https://www.ietf.org/mailman/listinfo/pce

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [Pce] Review of draft-ietf-pce-stateful-pce-18

[Dhruv Dhody]

Hi Joel, 

Regarding your comment - 

> Is the intention to prohibit the driving
> of LSP creation from the PCE?

This capability is described in - 
https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-07 (document 
expired recently, authors should refresh it)

Thanks,
Dhruv 

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Joel Halpern
> Sent: 17 February 2017 09:08
> To: gen-art@ietf.org
> Cc: draft-ietf-pce-stateful-pce@ietf.org; p...@ietf.org; i...@ietf.org
> Subject: [Pce] Review of draft-ietf-pce-stateful-pce-18
> 
> Reviewer: Joel Halpern
> Review result: Ready with Issues
> 
> 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
> 
> .
> 
> Document: draft-ietf-pce-stateful-pce-??
> Reviewer: Joel Halpern
> Review Date: 2017-02-16
> IETF LC End Date: 2017-02-28
> IESG Telechat date: 2017-03-16
> 
> Summary:
> 
> Major issues:
> 
> Minor issues:
>At the end of section 5.4, the text talks about a PCE accepting status
> updates even if the  stateful capability has not been negotiated.  Which is
> fine.  But as written, the text seems to say that doing so means that the
> PCE will be able to "build and maintain an up to date view of the state of
> the PCC's LSPs".  However, if the capability has not been negotiated, I do
> not see how the PCE can count on getting full and timely state reports.  
> Trying
> to infer why a PCC is sending such a report in the absence of the agreement
> seems problematic.
> 
> This comment may be a misunderstanding or mis-expectation on my part.
> I would have expected one of the ways o using an active PCE is to have the
> PCE decide (under suitable circumstances) that an LSP is needed between two
> PCCs.  As far as I can tell, the text in section
> 5.8.2 and 5.8.3 prohibits that.  A PCE is only allowed to send an LSP Update
> Request (in a PCUpd message) for an LSP that has been delegated to it.  At
> that point I thought that a PCC could delegate a block of unsetup LSPs to
> the PCE.  But then looking at 5.8.2, the text states that for each delegation,
> the PCC must request an initial path.  That seems to prohibit delegating a
> block of LSPs for future updates.  Is the intention to prohibit the driving
> of LSP creation from the PCE?
> 
> I have looked but I can not find the text explaining the significance
> and use of the Symbolic path name.  It is mandated by the draft.  There seems
> to be an implicit assumption taht it is needed by the PCE.  If the explanation
> of how or why it is needed is not present, it should be.
> 
> Nits/editorial comments:
> Should the text on the S bit in section 7.3 (the LSP Object
> definition) note that it should be set to 0 on all messages sent by the PCE?
> Should that also be stated for the R bit?  And the O bits?
> 
>   Section 9.2 seems very odd.  It states that the IETF "SHOULD" do some
> additional work.  I understand why teh work is needed.  But this does not
> seem to match the RFC 2119 meaning of SHOULD as it does not apply to eitehr
> the implementor or the implementation.
> 
> 
> ___
> Pce mailing list
> p...@ietf.org
> https://www.ietf.org/mailman/listinfo/pce

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC/Telechat review of draft-ietf-pce-iro-update-06

[Dhruv Dhody]

Hi Peter,

Thanks for the diligent review! See Inline...

On Mon, Apr 18, 2016 at 1:40 AM, Peter Yee  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 wait for direction from your document shepherd or
> AD before posting a new version of the draft.
>
> For more information, please see the FAQ at
> .
>
> Document: draft-ietf-pce-iro-update-06
> Reviewer: Peter Yee
> Review Date: Apr-17-2016
> IETF LC End Date: Mar-29-2016
> IESG Telechat date: Apr-21-2016
>
> Summary: This draft is basically ready for publication as a Standards
> Track RFC, but has some nits that should be fixed before publication.
> [Ready with nits]
>
> This specification documents the results of a survey regarding
> implementation of the Include Route Object for PCEP and uses those results
> to clarify the meaning of section 7.12 of RFC 5440 with updated text.
>
> Major issues: None
>
> Minor issues: None really
>
> Page 5, Section 4, 1st paragraph, 2nd sentence: Are you sure that
> confusing interpretation of the IRO ordering or the L bit doesn’t cause
> any security issues?  I’m not PCEP savvy enough to know if mistakenly
> sending information that should have gone strictly through a loose node
> would disclose anything that the originator didn’t really wish any nodes
> outside of the strict list to see.
>
>
​[Dhruv]: My first instinct is to say that this isn't an issue, as PCEP
speaker are expected to know about the nodes (via TED) irrespective of
strict and loose interpretation of that node. I will discuss this again
with the our shepherd.
​


>
> Nits:
>
> Page 3, first full paragraph: insert “an” before “IRO”.
>
> Page 3, Section 2 title: insert “the” before “IRO”.
>
> Page 3, Section 2, 3rd paragraph, 2nd sentence: insert “them” before the
> second “as”.
>
> Page 4, Section 2, 1st paragraph: append a colon to the end of the
> paragraph.
>
> Page 4, Section 2, indented bullet item: remove the hyphen and put the
> remainder between double quotes, not single quotes.
>
> Page 4, Section 2, 1st major bullet item, 1st sentence: insert “an” before
> “IRO”.
>
> Page 4, Section 2, 1st major bullet item, 2nd sentence: change
> “comprising” to “comprised”.  Insert “to” before “section”.
>
> Page 4, Section 2, 2nd major bullet item, 1st sentence: insert “an” before
> “IRO”.  Change the comma to a semicolon.
>
> Page 4, Section 2, 2nd major bullet item, 3rd sentence: insert “the”
> before “Loose”.
>
> Page 4, Section 3, 2nd paragraph, 1st sentence: delete comma.
>
> Page 4, Section 3, 2nd paragraph, 2nd sentence: change trailing space and
> hyphen to a colon.
>
> Page 4, Section 3, 1st bullet item: delete comma after “IRO”.  Insert
> “the” before the last “IRO”.
>
> Page 5, Section 3, 1st paragraph: insert “the” before “IRO”.
>
> Page 5, Section 4, 1st paragraph, 1st sentence: insert “the” before “IRO”.
>
>
>
> ​[Dhruv]: Thanks! Will Update!

Regards,
Dhruv​
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART telechat review of draft-ietf-teas-rsvp-te-domain-subobjects-03

[Dhruv Dhody]

Thanks Brian!
Thanks Pavan!

Happy Diwali :)



On Fri, Nov 13, 2015 at 11:16 AM, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:

> Hi,
> On 13/11/2015 18:25, Vishnu Pavan Beeram wrote:
> > Brian, Hi!
> >
> > Please see inline (prefixed [VPB])
> >
> > Regards,
> > -Pavan (as the Document Shepherd)
> >
> > Subject: Re: Gen-ART telechat review of
> draft-ietf-teas-rsvp-te-domain-subobjects-03
> >
> > ​
> > Hi Brian,
> >
> > Thanks for your review and sorry for the delay in the reply [ Diwali
> festivities in these neck of woods :) ]
>
> Ah, finally a valid excuse :-). Actually the public Diwali celebration in
> Auckland, where I
> live, was a couple of weeks ago so I didn't think of this.
>
> > Please see inline...
> >
> > On Fri, Nov 13, 2015 at 9:12 AM, Brian E Carpenter <
> brian.e.carpen...@gmail.com> 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 wait for direction from your
> > document shepherd or AD before posting a new version of the draft.
> >
> > For more information, please see the FAQ at
> > .
> >
> > Document: draft-ietf-teas-rsvp-te-domain-subobjects-03.txt
> > Reviewer:
> > ​​
> > Brian Carpenter
> > Review Date: 2015-11-13
> > IETF LC End Date: 2015-11-09
> > IESG Telechat date: 2015-11-19
> >
> > Summary: Ready with issues
> > 
> >
> > Comment:
> > 
> >
> > I haven't seen a response to my Last Call review, so this is the same.
> >
> > Needs to be approved along with draft-ietf-pce-pcep-domain-sequence.
> >
> > ​​[Dhruv]: Agreed​
> >
> >
> > Major Issues:
> > -
> >
> >> 3.2.1.  Autonomous system
> >>
> >>   [RFC3209] already defines 2-Byte AS number.
> >>
> >>   To support 4-Byte AS numbers as per [RFC6793], the following
> >>   subobject is defined:
> >>
> >>  0   1   2   3
> >>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> |L|Type | Length| Reserved  |
> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> |  AS-ID (4 bytes)  |
> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > I don't understand why that is considered Experimental. It seems like
> > a major defect in RFC 3209 that needs to be fixed on the standards
> > track as soon as possible, independently of the present draft.
> >
> > ​
> > [Dhruv]: This was suggested in the TEAS mailing list and it was decided
> that WG can revisit if/when usage warrants​ ​to move this to standards
> track.
> > https://mailarchive.ietf.org/arch/msg/teas/TV3X9BVc9mGW4lXWr-C0-sziCQE
> >
> > There were no objections to this approach.
> >
> > [VPB] As Dhruv pointed out, the WG did consider (link above) having the
> AS-ID specific extension discussed under standards track. But there wasn’t
> any interest shown by the WG for doing it at this point. This lack of
> interest could be perceived as an indication that there are currently no
> RSVP-TE deployments that use an AS-ID in the ERO. The decision by the WG
> was to revisit this discussion-point if/when there is some interest from
> the community to use the AS-ID in the ERO.
>
> OK, that is a good explanation. So let's leave that in the hands of the
> IESG.
>
> > Minor Issues:
> > -
> >
> > It would be nice to see a suggested timescale for the experiment in
> section 1.1.
> > How many years before this document should be evaluated?
> >
> >
> > [Dhruv]:​ ​We can add -
> >
> > The experiment will end two years after the RFC is published.
> > At that point, the RFC authors will attempt to determine how
> > widely this has been implemented and​ deployed.
>
> That would be fine, in my opinion.
>
> Thanks
> Brian
>
> >
> > Thanks for your reviews!
> >
> > Regards,
> > Dhruv
> >
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-teas-rsvp-te-domain-subobjects-03

[Dhruv Dhody]

Hi Brian,

Let me apologies again for keeping you waiting for a reply.

The reply to this would be the same as "Gen-ART telechat review of
draft-ietf-teas-rsvp-te-domain-subobjects-03" sent today.

We can continue the discussion on that thread?

Regards,
Dhruv

On Sat, Nov 7, 2015 at 3:55 AM, Brian E Carpenter <
brian.e.carpen...@gmail.com> 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
> .
>
> Document: draft-ietf-teas-rsvp-te-domain-subobjects-03.txt
> Reviewer: Brian Carpenter
> Review Date: 2015-11-07
> IETF LC End Date: 2015-11-09
> IESG Telechat date:
>
> Summary: Ready with issues
> 
>
> Comment:
> 
>
> Needs to be approved along with draft-ietf-pce-pcep-domain-sequence.
>
> Major Issues:
> -
>
> > 3.2.1.  Autonomous system
> >
> >   [RFC3209] already defines 2-Byte AS number.
> >
> >   To support 4-Byte AS numbers as per [RFC6793], the following
> >   subobject is defined:
> >
> >  0   1   2   3
> >  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |L|Type | Length| Reserved  |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |  AS-ID (4 bytes)  |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> I don't understand why that is considered Experimental. It seems like
> a major defect in RFC 3209 that needs to be fixed on the standards
> track as soon as possible, independently of the present draft.
>
> Minor Issues:
> -
>
> It would be nice to see a suggested timescale for the experiment in
> section 1.1.
> How many years before this document should be evaluated?
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART telechat review of draft-ietf-teas-rsvp-te-domain-subobjects-03

[Dhruv Dhody]

​
Hi Brian,

Thanks for your review and sorry for the delay in the reply [ Diwali
festivities in these neck of woods :) ]
Please see inline...

On Fri, Nov 13, 2015 at 9:12 AM, Brian E Carpenter <
brian.e.carpen...@gmail.com> 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 wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>
> For more information, please see the FAQ at
> .
>
> Document: draft-ietf-teas-rsvp-te-domain-subobjects-03.txt
> Reviewer:
> ​​
> Brian Carpenter
> Review Date: 2015-11-13
> IETF LC End Date: 2015-11-09
> IESG Telechat date: 2015-11-19
>
> Summary: Ready with issues
> 
>
> Comment:
> 
>
> I haven't seen a response to my Last Call review, so this is the same.
>
> Needs to be approved along with draft-ietf-pce-pcep-domain-sequence.
>

​​[Dhruv]: Agreed​


>
> Major Issues:
> -
>
> > 3.2.1.  Autonomous system
> >
> >   [RFC3209] already defines 2-Byte AS number.
> >
> >   To support 4-Byte AS numbers as per [RFC6793], the following
> >   subobject is defined:
> >
> >  0   1   2   3
> >  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |L|Type | Length| Reserved  |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |  AS-ID (4 bytes)  |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> I don't understand why that is considered Experimental. It seems like
> a major defect in RFC 3209 that needs to be fixed on the standards
> track as soon as possible, independently of the present draft.
>

​
[Dhruv]: This was suggested in the TEAS mailing list and it was decided
that WG can revisit if/when usage warrants​ ​to move this to standards
track.
https://mailarchive.ietf.org/arch/msg/teas/TV3X9BVc9mGW4lXWr-C0-sziCQE

There were no objections to this approach.



> Minor Issues:
> -
>
> It would be nice to see a suggested timescale for the experiment in
> section 1.1.
> How many years before this document should be evaluated?
>
>
[Dhruv]:​ ​We can add -

The experiment will end two years after the RFC is published.
At that point, the RFC authors will attempt to determine how
widely this has been implemented and​ deployed.

Thanks for your reviews!

Regards,
Dhruv
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-art] Review: draft-ietf-pce-pcep-domain-sequence

[Dhruv Dhody]

Hi All, 

How is this - 

   IGP Area subobjects in the XRO are local to the current AS.  In case
   of multi-AS path computation to exclude an IGP area in a different
   AS, IGP Area subobject should be part of Explicit Exclusion Route
   Subobject (EXRS) in the IRO to specify the AS in which the IGP area
   is to be excluded.

I have attached the working copy diff for easy reference.  

Regards,
Dhruv

> -Original Message-
> From: Dhruv Dhody
> Sent: 02 November 2015 00:33
> To: 'Julien Meuric'; Joel Halpern Direct; Dhruv Dhody
> Cc: A. Jean Mahoney; General Area Review Team; draft-ietf-pce-pcep-
> domain-sequence@ietf.org
> Subject: RE: Gen-art] Review: draft-ietf-pce-pcep-domain-sequence
> 
> Hi All,
> 
> Sorry for delay in replying, let me try to send you proposed text
> tomorrow as per Julien's suggestion!
> 
> Regards,
> Dhruv
> 
> > -Original Message-
> > From: Julien Meuric [mailto:julien.meu...@orange.com]
> > Sent: 31 October 2015 00:35
> > To: Joel Halpern Direct; Dhruv Dhody
> > Cc: A. Jean Mahoney; General Area Review Team; draft-ietf-pce-pcep-
> > domain-sequence@ietf.org; Dhruv Dhody
> > Subject: Re: Gen-art] Review: draft-ietf-pce-pcep-domain-sequence
> >
> > 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
> >
> >
> > Oct. 30, 2015 - jmh.dir...@joelhalpern.com:
> > >>  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.
Title: Diff: draft-ietf-pce-pcep-domain-sequence-09.txt - draft-ietf-pce-pcep-domain-sequence-10.txt


Content-Type: text/html


 
 

 
 
 
 
 
 
   
   
   
   
 
 
   
  < draft-ietf-pce-pcep-domain-sequence-09.txt   draft-ietf-pce-pcep-domain-sequence-10.txt > 
   
  PCE Working Group   D. Dhody PCE Working Group   D. Dhody
  Internet-Draft  U. Palle Internet-Draft  U. Palle
  Intended status: ExperimentalHuawei Technologies Intended status: ExperimentalHuawei Technologies
  
  Expires: March 23, 2016  R. Casellas Expires: May 5, 2016 R. Casellas
  CTTC CTTC
  
September 20, 2015 

Re: [Gen-art] Gen-art] Review: draft-ietf-pce-pcep-domain-sequence

[Dhruv Dhody]

Hi Julien, All,

So now we have - (and thanks for bearing with me, as we get there...)

   IGP Area subobjects in the XRO are local to the current AS.  In case
   of multi-AS path computation to exclude an IGP area in a different
   AS, IGP Area subobject should be part of Explicit Exclusion Route
   Subobject (EXRS) in the IRO to specify the AS in which the IGP area
   is to be excluded.  Further policy may be applied to prune/ignore
   Area subobjects in XRO after "current AS" change during path
   computation.

I have also attached the diff of the working copy to show the GenArt and IANA 
review changes so far. 

Regards,
Dhruv

> -Original Message-
> From: Julien Meuric [mailto:julien.meu...@orange.com]
> Sent: 03 November 2015 00:57
> To: Dhruv Dhody; Joel Halpern Direct; Dhruv Dhody
> Cc: A. Jean Mahoney; General Area Review Team; draft-ietf-pce-pcep-
> domain-sequence@ietf.org
> Subject: Re: Gen-art] Review: draft-ietf-pce-pcep-domain-sequence
> 
> Hi,
> 
> How about adding a sentence reminding that "A" stands for "Autonomous"?
> E.g., "policies may apply at AS boundaries and Area IDs after AS change
> may be pruned/ignored."
> 
> Regard,
> 
> Julien
> 
> 
> Nov. 02, 2015 - dhruv.dh...@huawei.com:
> > Hi All,
> >
> > How is this -
> >
> > IGP Area subobjects in the XRO are local to the current AS.  In
> case
> > of multi-AS path computation to exclude an IGP area in a
> different
> > AS, IGP Area subobject should be part of Explicit Exclusion Route
> > Subobject (EXRS) in the IRO to specify the AS in which the IGP
> area
> > is to be excluded.
> >
> > I have attached the working copy diff for easy reference.
> >
> > Regards,
> > Dhruv
> >
> >> -Original Message-
> >> From: Dhruv Dhody
> >> Sent: 02 November 2015 00:33
> >>
> >> Hi All,
> >>
> >> Sorry for delay in replying, let me try to send you proposed text
> >> tomorrow as per Julien's suggestion!
> >>
> >> Regards,
> >> Dhruv
> >>
> >>> -Original Message-
> >>> From: Julien Meuric [mailto:julien.meu...@orange.com]
> >>> Sent: 31 October 2015 00:35
> >>>
> >>> 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
> >>>
> >>>
> >>> Oct. 30, 2015 - jmh.dir...@joelhalpern.com:
> >>>>>   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 whi

Re: [Gen-art] Gen-art] Review: draft-ietf-pce-pcep-domain-sequence

[Dhruv Dhody]

Hi All, 

Sorry for delay in replying, let me try to send you proposed text tomorrow as 
per Julien's suggestion! 

Regards,
Dhruv 

> -Original Message-
> From: Julien Meuric [mailto:julien.meu...@orange.com]
> Sent: 31 October 2015 00:35
> To: Joel Halpern Direct; Dhruv Dhody
> Cc: A. Jean Mahoney; General Area Review Team; draft-ietf-pce-pcep-
> domain-sequence....@ietf.org; Dhruv Dhody
> Subject: Re: Gen-art] Review: draft-ietf-pce-pcep-domain-sequence
> 
> 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
> 
> 
> Oct. 30, 2015 - jmh.dir...@joelhalpern.com:
> >>  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.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-art] Review: draft-ietf-pce-pcep-domain-sequence

[Dhruv Dhody]

Hi Joel,

Thanks for a review. See inline...


On Fri, Oct 30, 2015 at 2:42 AM, Joel M. Halpern 
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
>
> .
>
> 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. 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.


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


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

Regards,
Dhruv


>
> Nits/editorial comments:
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art