date:20170831

Re: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-rfc6006bis-03: (with DISCUSS)

2017-08-31 Thread Dhruv Dhody

Hi Eric, 

Let me take one more stab at it - 

5.  Security Considerations

   As described in [RFC5862], P2MP path computation requests are more
   CPU-intensive and also utilize more link bandwidth.  In the event of
   an unauthorized P2MP path computation request, or a denial of service
   attack, the subsequent PCEP requests and processing may be disruptive
   to the network.  Consequently, it is important that implementations
   conform to the relevant security requirements that specifically help
   to minimize or negate unauthorized P2MP path computation requests and
   denial of service attacks.  These mechanisms include:

   o  Securing the PCEP session requests and responses is RECOMMENDED
  using TCP security techniques such as TCP Authentication Option
  (TCP-AO) [RFC5925] or using Transport Layer Security (TLS) [I-
  D.ietf-pce-pceps], as per the recommendations and best current
  practices in [RFC7525].

   o  Authenticating the PCEP requests and responses to ensure the
  message is intact and sent from an authorized node using TCP-AO or
  TLS is RECOMMENDED.

   o  Providing policy control by explicitly defining which PCCs, via IP
  access-lists, are allowed to send P2MP path requests to the PCE.

   PCEP operates over TCP, so it is also important to secure the PCE and
   PCC against TCP denial of service attacks. 

   As stated in [RFC6952], PCEP implementations should support TCP-AO
   [RFC5925] and not use TCP-MD5 because of the known vulnerabilities
   and weakness.  

What do you think? 

Regards,
Dhruv

From: Eric Rescorla [mailto:e...@rtfm.com] 
Sent: 31 August 2017 18:17
To: Dhruv Dhody 
Cc: The IESG ; draft-ietf-pce-rfc6006...@ietf.org; pce@ietf.org; 
pce-cha...@ietf.org
Subject: Re: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-rfc6006bis-03: 
(with DISCUSS)

No, not really. You're still citing to 5440 which has the TCP-MD5 stuff, and 
there's no requirement to use AO. I think what's needed here is a normative 
requirement for something strong than TCP-MD5. I defer to the WG on what that 
should be, but it's really not OK to keep using TCP-MD5 as our basic security 
measure for TCP connections for routing protocols

-Ekr

On Thu, Aug 31, 2017 at 12:36 AM, Dhruv Dhody  wrote:
Hi Eric,

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Eric Rescorla
> Sent: 31 August 2017 05:12
> To: The IESG 
> Cc: draft-ietf-pce-rfc6006...@ietf.org; pce@ietf.org; pce-cha...@ietf.org
> Subject: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-rfc6006bis-03:
> (with DISCUSS)
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-pce-rfc6006bis-03: Discuss
>
> 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-rfc6006bis/
>
>
>
> --
> DISCUSS:
> --
>
> The Security Considerations is worrisome, as it points to RFC 5440;
> Section 10.2, which basically recommends TCP-MD5:
>
>    At the time of writing, TCP-MD5 [RFC2385] is the only available
>    security mechanism for securing the TCP connections that underly PCEP
>    sessions.
>
>    As explained in [RFC2385], the use of MD5 faces some limitations and
>    does not provide as high a level of security as was once believed.  A
>    PCEP implementation supporting TCP-MD5 SHOULD be designed so that
>    stronger security keying techniques or algorithms that may be
>    specified for TCP can be easily integrated in future releases.
>
>    The TCP Authentication Option [TCP-AUTH] (TCP-AO) specifies new
>    security procedures for TCP, but is not yet complete.  Since it is
>    believed that [TCP-AUTH] will offer significantly improved security
>    for applications using TCP, implementers should expect to update
>    their implementation as soon as the TCP Authentication Option is
>    published as an RFC.
>
>    Implementations MUST support TCP-MD5 and should make the security
>    function available as a configuration option.
>
> TCP-AO has now been published as an RFC for quite some time, so it's
> probably not really appropriate to just point to a document which
> recommends TCP-MD5.
>
[[Dhruv Dhody]] Let me know if this change is okay -

OLD:
5.  Security Considerations

   As described in [RFC5862], P2MP path computation requests are more
   CPU-intensive and also utilize more link bandwidth.  In the event of
   an unauthorized P2MP path

Re: [Pce] Adam Roach's No Objection on draft-ietf-pce-rfc6006bis-03: (with COMMENT)

2017-08-31 Thread Adam Roach

On 8/31/17 01:34, Dhruv Dhody wrote:

Hi Adam,

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adam Roach
Sent: 30 August 2017 08:20
To: The IESG 
Cc: draft-ietf-pce-rfc6006...@ietf.org; pce@ietf.org; pce-cha...@ietf.org
Subject: [Pce] Adam Roach's No Objection on draft-ietf-pce-rfc6006bis-03:
(with COMMENT)

Adam Roach has entered the following ballot position for
draft-ietf-pce-rfc6006bis-03: 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-rfc6006bis/

--
COMMENT:
--

I have only reviewed the diffs from RFC6006 (Perhaps we should request
tools support for bis document diffs):

The instructions in section 6.5 only indicate that IANA should update the
document reference. The changes indicated in this section additionally
reserve new values (specifically, the object type of "0" for object
classes 28-31). As these changes are not called out, they run the risk of
being overlooked. Please update the instructions to IANA to indicate that
the registered values have changed, not just the document references.

[[Dhruv Dhody]] The Object-Type 0 is already marked in the PCEP IANA registry [1] as 
"reserved", as part of an earlier Errata [2].
But you are correct, that the text should be updated to reflect this.

I have made this change -

Also, for the following four PCEP objects, the code-point 0 for the
Object-Type field are marked "Reserved" with reference to Errata ID
4956. IANA is requested to update the reference to point to this
document.

Is that okay?

Yes. Thanks!

/a

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

Re: [Pce] Ben Campbell's No Objection on draft-ietf-pce-rfc6006bis-03: (with COMMENT)

2017-08-31 Thread Ben Campbell


> On Aug 31, 2017, at 1:32 AM, Dhruv Dhody  wrote:
> 
> Hi Ben, 
> 
>> -Original Message-
>> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Ben Campbell
>> Sent: 29 August 2017 08:18
>> To: The IESG 
>> Cc: draft-ietf-pce-rfc6006...@ietf.org; pce@ietf.org; pce-cha...@ietf.org
>> Subject: [Pce] Ben Campbell's No Objection on draft-ietf-pce-rfc6006bis-03:
>> (with COMMENT)
>> 
>> Ben Campbell has entered the following ballot position for
>> draft-ietf-pce-rfc6006bis-03: 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-rfc6006bis/
>> 
>> 
>> 
>> --
>> COMMENT:
>> --
>> 
>> Is section 2 expected to be of more than background interest to an
>> implementer?
>> If not, I suggest moving it to an appendix, or at least towards the back
>> of the document.
>> 
> [[Dhruv Dhody]] This is as per the earlier published RFC. This section has 
> not changed in the bis document. 
> Including a requirement section was quite usual in the PCEP RFCs published 
> earlier, I know that in the recent times this is discouraged. 
> 
> In the case of bis document, there is some value in keeping the spirit and 
> order of the original RFC, so that a clear comparison with the 
> to-be-obsolute-RFC is possible. 
> Do you agree, if not I can move as suggested. 

I agree, it makes since to leave it as it was in the original.

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

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

Re: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-rfc6006bis-03: (with DISCUSS)

2017-08-31 Thread Eric Rescorla

No, not really. You're still citing to 5440 which has the TCP-MD5 stuff,
and there's no requirement to use AO. I think what's needed here is a
normative requirement for something strong than TCP-MD5. I defer to the WG
on what that should be, but it's really not OK to keep using TCP-MD5 as our
basic security measure for TCP connections for routing protocols

-Ekr


On Thu, Aug 31, 2017 at 12:36 AM, Dhruv Dhody 
wrote:

> Hi Eric,
>
> > -Original Message-
> > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Eric Rescorla
> > Sent: 31 August 2017 05:12
> > To: The IESG 
> > Cc: draft-ietf-pce-rfc6006...@ietf.org; pce@ietf.org;
> pce-cha...@ietf.org
> > Subject: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-rfc6006bis-03:
> > (with DISCUSS)
> >
> > Eric Rescorla has entered the following ballot position for
> > draft-ietf-pce-rfc6006bis-03: Discuss
> >
> > 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-rfc6006bis/
> >
> >
> >
> > --
> > DISCUSS:
> > --
> >
> > The Security Considerations is worrisome, as it points to RFC 5440;
> > Section 10.2, which basically recommends TCP-MD5:
> >
> >At the time of writing, TCP-MD5 [RFC2385] is the only available
> >security mechanism for securing the TCP connections that underly PCEP
> >sessions.
> >
> >As explained in [RFC2385], the use of MD5 faces some limitations and
> >does not provide as high a level of security as was once believed.  A
> >PCEP implementation supporting TCP-MD5 SHOULD be designed so that
> >stronger security keying techniques or algorithms that may be
> >specified for TCP can be easily integrated in future releases.
> >
> >The TCP Authentication Option [TCP-AUTH] (TCP-AO) specifies new
> >security procedures for TCP, but is not yet complete.  Since it is
> >believed that [TCP-AUTH] will offer significantly improved security
> >for applications using TCP, implementers should expect to update
> >their implementation as soon as the TCP Authentication Option is
> >published as an RFC.
> >
> >Implementations MUST support TCP-MD5 and should make the security
> >function available as a configuration option.
> >
> > TCP-AO has now been published as an RFC for quite some time, so it's
> > probably not really appropriate to just point to a document which
> > recommends TCP-MD5.
> >
> [[Dhruv Dhody]] Let me know if this change is okay -
>
> OLD:
> 5.  Security Considerations
>
>As described in [RFC5862], P2MP path computation requests are more
>CPU-intensive and also utilize more link bandwidth.  In the event of
>an unauthorized P2MP path computation request, or a denial of service
>attack, the subsequent PCEP requests and processing may be disruptive
>to the network.  Consequently, it is important that implementations
>conform to the relevant security requirements of [RFC5440] that
>specifically help to minimize or negate unauthorized P2MP path
>computation requests and denial of service attacks.  These mechanisms
>include:
>
>o  Securing the PCEP session requests and responses using TCP
>   security techniques (Section 10.2 of [RFC5440]).
>
>o  Authenticating the PCEP requests and responses to ensure the
>   message is intact and sent from an authorized node (Section 10.3
>   of [RFC5440]).
>
>o  Providing policy control by explicitly defining which PCCs, via IP
>   access-lists, are allowed to send P2MP path requests to the PCE
>   (Section 10.6 of [RFC5440]).
>
>PCEP operates over TCP, so it is also important to secure the PCE and
>PCC against TCP denial of service attacks.  Section 10.7.1 of
>[RFC5440] outlines a number of mechanisms for minimizing the risk of
>TCP based denial of service attacks against PCEs and PCCs.
>
>PCEP implementations SHOULD consider the additional security provided
>by Transport Layer Security (TLS) [I-D.ietf-pce-pceps].
> NEW:
> 5.  Security Considerations
>
>As described in [RFC5862], P2MP path computation requests are more
>CPU-intensive and also utilize more link bandwidth.  In the event of
>an unauthorized P2MP path computation request, or a denial of service
>attack, the subsequent PCEP requests and processing may be disruptive
>to the network.  Consequently, it is important that implementations
>conform to the relevant security requirements

Re: [Pce] Benoit Claise's No Objection on draft-ietf-pce-rfc6006bis-03: (with COMMENT)

2017-08-31 Thread Benoit Claise


Thanks.

Make sure it appears in the ToC.

Regards, B.

Hi Benoit, Adrian,

I have updated Appendix A to include all changes from RFC6006 and made the RBNF 
changes as a sub-section.

See working copy at -
https://github.com/dhruvdhody-huawei/ietf/blob/master/draft-ietf-pce-rfc6006bis-04.txt
Diff: 
https://www.ietf.org/rfcdiff?url1=draft-ietf-pce-rfc6006bis-03=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-rfc6006bis-04.txt

Thanks!
Dhruv


-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: 30 August 2017 17:39
To: 'Benoit Claise' ; 'The IESG' 
Cc: draft-ietf-pce-rfc6006...@ietf.org; pce@ietf.org; pce-cha...@ietf.org;
'Fred Baker' 
Subject: Re: [Pce] Benoit Claise's No Objection on draft-ietf-pce-
rfc6006bis-03: (with COMMENT)

Morning Komrade Claise,

Did you spot Appendix A?

A



-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Benoit Claise
Sent: 30 August 2017 10:32
To: The IESG
Cc: draft-ietf-pce-rfc6006...@ietf.org; pce@ietf.org;
pce-cha...@ietf.org;

Fred

Baker
Subject: [Pce] Benoit Claise's No Objection on draft-ietf-pce-

rfc6006bis-03:
(with

COMMENT)

Benoit Claise has entered the following ballot position for
draft-ietf-pce-rfc6006bis-03: 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-rfc6006bis/



--
COMMENT:
--

- Where is the "diff from RFC6006" section?
The following is not useful:

This document obsoletes RFC 6006 and incorporates all outstanding
Errata:

o Erratum with IDs: 3819, 3830, 3836, 4867, and 4868.

I found "Appendix A. Summary of the RBNF Changes from RFC 6006", as a
good start, but it doesn't even appear in the table of content. Why?

- I've not been following the IPR situation (as described by Alvaro),
but

would

like to understand and it should be discussed during the telechat. Is
it the case that https://datatracker.ietf.org/ipr/1686/ (related to
RFC6006) is updated by https://datatracker.ietf.org/ipr/2983/ (related
to RFC6006 and RFC6006bis)?


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

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

.



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

Re: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-rfc6006bis-03: (with DISCUSS)

2017-08-31 Thread Dhruv Dhody

Hi Eric, 

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Eric Rescorla
> Sent: 31 August 2017 05:12
> To: The IESG 
> Cc: draft-ietf-pce-rfc6006...@ietf.org; pce@ietf.org; pce-cha...@ietf.org
> Subject: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-rfc6006bis-03:
> (with DISCUSS)
> 
> Eric Rescorla has entered the following ballot position for
> draft-ietf-pce-rfc6006bis-03: Discuss
> 
> 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-rfc6006bis/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> The Security Considerations is worrisome, as it points to RFC 5440;
> Section 10.2, which basically recommends TCP-MD5:
> 
>At the time of writing, TCP-MD5 [RFC2385] is the only available
>security mechanism for securing the TCP connections that underly PCEP
>sessions.
> 
>As explained in [RFC2385], the use of MD5 faces some limitations and
>does not provide as high a level of security as was once believed.  A
>PCEP implementation supporting TCP-MD5 SHOULD be designed so that
>stronger security keying techniques or algorithms that may be
>specified for TCP can be easily integrated in future releases.
> 
>The TCP Authentication Option [TCP-AUTH] (TCP-AO) specifies new
>security procedures for TCP, but is not yet complete.  Since it is
>believed that [TCP-AUTH] will offer significantly improved security
>for applications using TCP, implementers should expect to update
>their implementation as soon as the TCP Authentication Option is
>published as an RFC.
> 
>Implementations MUST support TCP-MD5 and should make the security
>function available as a configuration option.
> 
> TCP-AO has now been published as an RFC for quite some time, so it's
> probably not really appropriate to just point to a document which
> recommends TCP-MD5.
> 
[[Dhruv Dhody]] Let me know if this change is okay - 

OLD: 
5.  Security Considerations

   As described in [RFC5862], P2MP path computation requests are more
   CPU-intensive and also utilize more link bandwidth.  In the event of
   an unauthorized P2MP path computation request, or a denial of service
   attack, the subsequent PCEP requests and processing may be disruptive
   to the network.  Consequently, it is important that implementations
   conform to the relevant security requirements of [RFC5440] that
   specifically help to minimize or negate unauthorized P2MP path
   computation requests and denial of service attacks.  These mechanisms
   include:

   o  Securing the PCEP session requests and responses using TCP
  security techniques (Section 10.2 of [RFC5440]).

   o  Authenticating the PCEP requests and responses to ensure the
  message is intact and sent from an authorized node (Section 10.3
  of [RFC5440]).

   o  Providing policy control by explicitly defining which PCCs, via IP
  access-lists, are allowed to send P2MP path requests to the PCE
  (Section 10.6 of [RFC5440]).

   PCEP operates over TCP, so it is also important to secure the PCE and
   PCC against TCP denial of service attacks.  Section 10.7.1 of
   [RFC5440] outlines a number of mechanisms for minimizing the risk of
   TCP based denial of service attacks against PCEs and PCCs.

   PCEP implementations SHOULD consider the additional security provided
   by Transport Layer Security (TLS) [I-D.ietf-pce-pceps].
NEW: 
5.  Security Considerations

   As described in [RFC5862], P2MP path computation requests are more
   CPU-intensive and also utilize more link bandwidth.  In the event of
   an unauthorized P2MP path computation request, or a denial of service
   attack, the subsequent PCEP requests and processing may be disruptive
   to the network.  Consequently, it is important that implementations
   conform to the relevant security requirements that specifically help
   to minimize or negate unauthorized P2MP path computation requests and
   denial of service attacks.  These mechanisms include:

   o  Securing the PCEP session requests and responses using TCP
  security techniques such as TCP Authentication Option (TCP-AO)
  [RFC5925] or using Transport Layer Security (TLS) [I-D.ietf-pce-
  pceps], as per the recommendations and best current practices in
  [RFC7525].

   o  Authenticating the PCEP requests and responses to ensure the
  message is intact and sent from an authorized node using TCP-AO or
  TLS.

   o  Providing policy

Re: [Pce] Benoit Claise's No Objection on draft-ietf-pce-rfc6006bis-03: (with COMMENT)

2017-08-31 Thread Dhruv Dhody

Hi Benoit, Adrian, 

I have updated Appendix A to include all changes from RFC6006 and made the RBNF 
changes as a sub-section. 

See working copy at - 
https://github.com/dhruvdhody-huawei/ietf/blob/master/draft-ietf-pce-rfc6006bis-04.txt
Diff: 
https://www.ietf.org/rfcdiff?url1=draft-ietf-pce-rfc6006bis-03=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-rfc6006bis-04.txt

Thanks! 
Dhruv

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel
> Sent: 30 August 2017 17:39
> To: 'Benoit Claise' ; 'The IESG' 
> Cc: draft-ietf-pce-rfc6006...@ietf.org; pce@ietf.org; pce-cha...@ietf.org;
> 'Fred Baker' 
> Subject: Re: [Pce] Benoit Claise's No Objection on draft-ietf-pce-
> rfc6006bis-03: (with COMMENT)
> 
> Morning Komrade Claise,
> 
> Did you spot Appendix A?
> 
> A
> 
> 
> > -Original Message-
> > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Benoit Claise
> > Sent: 30 August 2017 10:32
> > To: The IESG
> > Cc: draft-ietf-pce-rfc6006...@ietf.org; pce@ietf.org;
> > pce-cha...@ietf.org;
> Fred
> > Baker
> > Subject: [Pce] Benoit Claise's No Objection on draft-ietf-pce-
> rfc6006bis-03:
> (with
> > COMMENT)
> >
> > Benoit Claise has entered the following ballot position for
> > draft-ietf-pce-rfc6006bis-03: 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-rfc6006bis/
> >
> >
> >
> > --
> > COMMENT:
> > --
> >
> > - Where is the "diff from RFC6006" section?
> > The following is not useful:
> >
> >This document obsoletes RFC 6006 and incorporates all outstanding
> >Errata:
> >
> >o Erratum with IDs: 3819, 3830, 3836, 4867, and 4868.
> >
> > I found "Appendix A. Summary of the RBNF Changes from RFC 6006", as a
> > good start, but it doesn't even appear in the table of content. Why?
> >
> > - I've not been following the IPR situation (as described by Alvaro),
> > but
> would
> > like to understand and it should be discussed during the telechat. Is
> > it the case that https://datatracker.ietf.org/ipr/1686/ (related to
> > RFC6006) is updated by https://datatracker.ietf.org/ipr/2983/ (related
> > to RFC6006 and RFC6006bis)?
> >
> >
> > ___
> > Pce mailing list
> > Pce@ietf.org
> > https://www.ietf.org/mailman/listinfo/pce
> 
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce

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

Re: [Pce] Adam Roach's No Objection on draft-ietf-pce-rfc6006bis-03: (with COMMENT)

2017-08-31 Thread Dhruv Dhody

Hi Adam, 

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adam Roach
> Sent: 30 August 2017 08:20
> To: The IESG 
> Cc: draft-ietf-pce-rfc6006...@ietf.org; pce@ietf.org; pce-cha...@ietf.org
> Subject: [Pce] Adam Roach's No Objection on draft-ietf-pce-rfc6006bis-03:
> (with COMMENT)
> 
> Adam Roach has entered the following ballot position for
> draft-ietf-pce-rfc6006bis-03: 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-rfc6006bis/
> 
> 
> 
> --
> COMMENT:
> --
> 
> I have only reviewed the diffs from RFC6006 (Perhaps we should request
> tools support for bis document diffs):
>  editor.org/rfc/rfc6006.txt=draft-ietf-pce-rfc6006bis-03>
> 
> The instructions in section 6.5 only indicate that IANA should update the
> document reference. The changes indicated in this section additionally
> reserve new values (specifically, the object type of "0" for object
> classes 28-31). As these changes are not called out, they run the risk of
> being overlooked. Please update the instructions to IANA to indicate that
> the registered values have changed, not just the document references.
> 
[[Dhruv Dhody]] The Object-Type 0 is already marked in the PCEP IANA registry 
[1] as "reserved", as part of an earlier Errata [2]. 
But you are correct, that the text should be updated to reflect this. 

I have made this change - 

   Also, for the following four PCEP objects, the code-point 0 for the
   Object-Type field are marked "Reserved" with reference to Errata ID
   4956. IANA is requested to update the reference to point to this
   document.

Is that okay?

[1] https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects
[2] https://www.rfc-editor.org/errata_search.php?eid=4956

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

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

Re: [Pce] Ben Campbell's No Objection on draft-ietf-pce-rfc6006bis-03: (with COMMENT)

2017-08-31 Thread Dhruv Dhody

Hi Ben, 

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Ben Campbell
> Sent: 29 August 2017 08:18
> To: The IESG 
> Cc: draft-ietf-pce-rfc6006...@ietf.org; pce@ietf.org; pce-cha...@ietf.org
> Subject: [Pce] Ben Campbell's No Objection on draft-ietf-pce-rfc6006bis-03:
> (with COMMENT)
> 
> Ben Campbell has entered the following ballot position for
> draft-ietf-pce-rfc6006bis-03: 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-rfc6006bis/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Is section 2 expected to be of more than background interest to an
> implementer?
> If not, I suggest moving it to an appendix, or at least towards the back
> of the document.
> 
[[Dhruv Dhody]] This is as per the earlier published RFC. This section has not 
changed in the bis document. 
Including a requirement section was quite usual in the PCEP RFCs published 
earlier, I know that in the recent times this is discouraged. 

In the case of bis document, there is some value in keeping the spirit and 
order of the original RFC, so that a clear comparison with the 
to-be-obsolute-RFC is possible. 
Do you agree, if not I can move as suggested. 

Thanks! 
Dhruv

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

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

Re: [Pce] Mirja Kühlewind's No Objection on draft-ietf-pce-rfc6006bis-03: (with COMMENT)

2017-08-31 Thread Dhruv Dhody

Hi Mirja, 

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Mirja Kühlewind
> Sent: 25 August 2017 19:19
> To: The IESG 
> Cc: draft-ietf-pce-rfc6006...@ietf.org; pce@ietf.org; pce-cha...@ietf.org
> Subject: [Pce] Mirja Kühlewind's No Objection on draft-ietf-pce-
> rfc6006bis-03: (with COMMENT)
> 
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-pce-rfc6006bis-03: 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-rfc6006bis/
> 
> 
> 
> --
> COMMENT:
> --
> 
> I could be helpful, also for implementors to update their code, to more
> explicitly spell out what the changes are (in the intro) instead of just
> listing the errata numbers.
> 
> 
[[Dhruv Dhody]] I have updated the Appendix, and added a reference in the 
Introduction. 

Appendix A. Summary of the all Changes from RFC 6006

   o Updated the text to use the term "PCC" instead of "user" while
   describing the encoding rules in section 3.10. 

   o Updated the example in figure 7 to explicitly include the RP
   object.

   o Corrected the description of F-bit in the RP object in section
   3.13, as per the errata ID 3836.

   o Corrected the description of fragmentation procedure for the
   response in section 3.13.2, as per the errata ID 3819.  

   o Corrected the Error-Type in section 3.15 for fragmentation, as per
   the errata ID 3830. 

   o Updated the references for OSPF Router Information Link State
   Advertisement (LSA) [RFC7770] and PCEP-MIB [RFC7420]. 

   o Add updated information and references for PCEP YANG [I-D.ietf-pce-
   pcep-yang] and PCEPS [I-D.ietf-pce-pceps].

   o Updated IANA considerations to mark code-point 0 as reserved for
   the object type defined in this document, as per the errata ID 4956.
   IANA references are also updated to point to this document. 

Appendix A.1 RBNF Changes from RFC 6006

   o Update to RBNF for Request message format: 

  * Update to the request message to allow for the bundling of
  multiple path computation requests within a single Path
  Computation Request (PCReq) message.

  * Addition of  in PCReq message. This object was missed
  in [RFC6006].

  * Addition of BNC object in PCReq message. This object is required
  to support P2MP. It shares the same format as Include Route Object
  (IRO) but it is a different object. 

  * Update to the  format, to also allow Secondary Record
  Route object (SRRO). This object was missed in [RFC6006].

  * Removed the BANDWIDTH Object followed by Record Route Object
  (RRO) from . As BANDWIDTH object doesn't need to follow
  for each RRO in the , there already exist BANDWIDTH
  object follow  and is backward compatible with
  [RFC5440].

  * Update to the , to allow optional
  BANDWIDTH object only if  is included. 

  * Errata ID: 4867

   o Update the RBNF for Reply message format:

  * Update to the reply message to allow for bundling of multiple
  path computation replies within a single Path Computation Reply
  (PCRep) message.

  * Addition of the UNREACH-DESTINATION in PCRep message. This
  object was missed in [RFC6006].

  * Errata ID: 4868

Hope this works? 

Thanks for your review. 

Regards,
Dhruv

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

Re: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-rfc6006bis-03: (with DISCUSS)

Re: [Pce] Adam Roach's No Objection on draft-ietf-pce-rfc6006bis-03: (with COMMENT)

Re: [Pce] Ben Campbell's No Objection on draft-ietf-pce-rfc6006bis-03: (with COMMENT)

Re: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-rfc6006bis-03: (with DISCUSS)

Re: [Pce] Benoit Claise's No Objection on draft-ietf-pce-rfc6006bis-03: (with COMMENT)

Re: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-rfc6006bis-03: (with DISCUSS)

Re: [Pce] Benoit Claise's No Objection on draft-ietf-pce-rfc6006bis-03: (with COMMENT)

Re: [Pce] Adam Roach's No Objection on draft-ietf-pce-rfc6006bis-03: (with COMMENT)

Re: [Pce] Ben Campbell's No Objection on draft-ietf-pce-rfc6006bis-03: (with COMMENT)

Re: [Pce] Mirja Kühlewind's No Objection on draft-ietf-pce-rfc6006bis-03: (with COMMENT)

10 matches

Site Navigation

Mail list logo

Footer information