Subject: [Pce] Roman Danyliw's No Objection on draft-ietf-pce-stateful-path-protection-10: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 18 Sep 2019 14:01:22 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-pce-stateful-path-protection-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-path-protection/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Section 3.2.  It took me a bit to understand that the Path Protection
Association TLV goes in an ASSOCIATION Object per Section 6 of
[I-D.ietf-pce-association-group].  On initial reading of “[t]he Path Protection
Association TLV is an optional TLV for use with the Path Protection Association
Type” this relationship wasn’t clear.  I’d recommend an editorial update to
make it clearer.  I believe this is related Ben Kaduk’s DISCUSS #5 (which I
support).

** Section 3.2  The protection type field specifies the protection type of the
LSP.  Section 1 notes that “one working LSP [can be associated with] one or
more protection LSPs using the generic association mechanism.”  Assuming a case
were multiple protection LSPs are specified, is it valid for the protections
type to be different?

** Section 4.5.  For clarity, I would recommend being precise with the exact
code point names when discussing conflicting combinations of protection types. 
For example, s/1+1 or 1:N/1+1 (i.e., protection type=0x08 or 0x10) or 1:N
(i.e., protection type = 0x04) with N=1 per <insert IANA registry name>/

Baring these combinations, are other any other remaining combinations of
protection types legal given different protection LSPs in the same PPAG (e.g.,
0x1 + 0x2)?

** Editorial Nits:
-- Section 1.  s/effect/affect/

-- Section 1.  Per “When the working LSPs are computed and controlled by the
PCE, there is benefit in a mode of operation where protection LSPs are as
well”, I couldn’t parse the second clause.

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 24 Sep 2019 11:38:48 +0530

Hi Roman,

Thanks for your comments. Few thoughts...

> https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-path-protection/

This is updated to "The Path Protection Association TLV is an optional
TLV for use in the ASSOCIATION Object with the Path Protection
Association Type."

> were multiple protection LSPs are specified, is it valid for the protections

An explicit error text has been added to make sure LSPs within the
association group has the same Protection Type.

> (i.e., protection type = 0x04) with N=1 per <insert IANA registry name>/

Based on Barry's comment this was simplified and now we have just two
case 1+1 and 1:N. The protection type values could be added in
brackets.

> protection types legal given different protection LSPs in the same PPAG (e.g.,

As per RFC 4872, all "other" values are reserved.
As per Ben's comment, this was added - "Any type already defined or
that could be defined in the future for use in the RSVP-TE PROTECTION
object is acceptable in this TLV unless explicitly stated otherwise."

> well”, I couldn’t parse the second clause.

Thanks!
Dhruv

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 24 Sep 2019 12:21:54 +0000

Hi Dhruv!

Thanks for these proposed edits.  They address my comments.

> -----Original Message-----
> From: Dhruv Dhody [mailto:[email-masked]]
> Sent: Tuesday, September 24, 2019 2:09 AM
> To: Roman Danyliw <[email-masked]>
> Cc: The IESG <[email-masked]>; draft-ietf-pce-stateful-path-
> [email-masked]; Julien Meuric <[email-masked]>; pce-chairs
> <[email-masked]>; [email-masked]
> Subject: Re: Roman Danyliw's No Objection on draft-ietf-pce-stateful-path-
> protection-10: (with COMMENT)
> 
> Hi Roman,
> 
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > ** Section 3.2.  It took me a bit to understand that the Path
> > Protection Association TLV goes in an ASSOCIATION Object per Section 6
> > of [I-D.ietf-pce-association-group].  On initial reading of “[t]he
> > Path Protection Association TLV is an optional TLV for use with the
> > Path Protection Association Type” this relationship wasn’t clear.  I’d
> > recommend an editorial update to make it clearer.  I believe this is
> > related Ben Kaduk’s DISCUSS #5 (which I support).
> >
> 
> This is updated to "The Path Protection Association TLV is an optional TLV
> for use in the ASSOCIATION Object with the Path Protection Association
> Type."

Thanks.  That is much clearer.

> > ** Section 3.2  The protection type field specifies the protection
> > type of the LSP.  Section 1 notes that “one working LSP [can be
> > associated with] one or more protection LSPs using the generic
> > association mechanism.”  Assuming a case were multiple protection LSPs
> > are specified, is it valid for the protections type to be different?
> >
> 

> > ** Section 4.5.  For clarity, I would recommend being precise with the
> > exact code point names when discussing conflicting combinations of
> protection types.
> > For example, s/1+1 or 1:N/1+1 (i.e., protection type=0x08 or 0x10) or
> > 1:N (i.e., protection type = 0x04) with N=1 per <insert IANA registry
> > name>/
> >
> 
> case 1+1 and 1:N. The protection type values could be added in brackets.
>
> > Baring these combinations, are other any other remaining combinations
> > of protection types legal given different protection LSPs in the same
> > PPAG (e.g.,
> > 0x1 + 0x2)?
> >
> 
> As per Ben's comment, this was added - "Any type already defined or that
> could be defined in the future for use in the RSVP-TE PROTECTION object is
> acceptable in this TLV unless explicitly stated otherwise."

Thanks.  For both of the items above, the proposed approach is clearer and addresses my comment.

> > -- Section 1.  Per “When the working LSPs are computed and controlled
> > by the PCE, there is benefit in a mode of operation where protection
> > LSPs are as well”, I couldn’t parse the second clause.
> >
> >

Thanks,
Roman