Subject: [Pals] Shepherd’s review of draft-ietf-pals-mc-pon-03

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 9 Jun 2016 15:00:03 -0400

Authors,

This review should be treated as any other last call review. The draft can
be updated to reflect all received comments following the end of WG last
call.

In general, I found the draft to be extremely well written and easy to
follow, and only have a few comments on it. I also note that it cleanly
passes IDNits, that is appreciated.

Section 1: This section provides a good introduction to PON resilience for
people not previously familiar with it.

Reference to [SEAMLESS-MPLS].
Unfortunately, draft-ietf-mpls-seamless-mpls-07 was never published and is
now dead, so it cannot be used as a reference, even an informative one
(which is a shame, I thought it was a very good draft). A quick Google
search didn’t turn up a good replacement reference, such as a journal
article, but I’ve asked a few people if they know of one. In the absence of
a replacement, this reference will have to removed. Note that RFC 7032 was
able to get away with this reference because the seamless MPLS draft was
still alive at that time. However, the reference is just a minor one, and I
don’t really see a problem in removing it if necessary.

Reference to [TR-221]: You should include the URL in the reference,
https://www.broadband-forum.org/technical/download/TR-221.pdf .

Reference to [WT-331]: Unfortunately, the BBF doesn’t allow outside
references to working texts, as they aren’t available to non-BBF members.
So this reference needs to be removed.

Reference to [ICCP]: Throughout the document, the reference [ICCP] should
be changed to [RFC7275] for consistency with the other references.

Section 2.1, TLV definitions and Section 6, IANA Considerations

You are requesting four consecutive values from the ICC RG Parameter Types
registry, which is fine, but you seem to be requesting them from the
“Expert Review” range, rather than the “IETF Review” range, which is the
proper range for a standards-track RFC.  So I would make the following
changes:

1. Change each of the four TLV diagrams to use Type=TDB1, Type=TBD2, and so
on, rather than the current Type=0x00XX. Also update each of the TLV
descriptions to match.

2. Change section 6 to read:

6 <https://tools.ietf.org/html/draft-ietf-pals-mc-pon-03#section-6>.
IANA Considerations

   IANA maintains a top-level registry called "Pseudowire Name
   Spaces (PWE3)".  It has a sub-registry called "ICC RG Parameter
   Types”. The following values are requested from this

   sub-registry:

   TBD1         PON Connect TLV
   TBD2         PON Disconnect TLV
   TBD3         PON Configuration TLV
   TBD4         PON State TLV

   [Note to IANA, to be removed by the RFC Editor: consecutive values

   in the IETF Review range are requested.]

Section 5:

I’m curious what you mean by “compromised” with regard to a PE. Since ICCP
is meant to be deployed in "well-managed and highly monitored networks”
(that’s from RFC 7275), that would presumably apply to the PEs as well. I
suggest you go into more detail in the second paragraph, as I’m sure a
request for more detail will come up during IESG review. Also, it wouldn’t
hurt to include something along the lines of: “Similar to ICCP itself, this
ICCP application SHOULD only be used in well-managed and highly monitored
service provider PON access networks.”

Thanks,
Andy

---

From: Jiangyuanlong <[email-masked]>
Date: Wed, 15 Jun 2016 13:02:58 +0000

Hi Andy and all,

Many thanks to these good suggestions. Please see my comments inline, especially the new texts suggested by us on Section 5.
If there is no further comments, we will soon upload a new revision to reflect all these comments.

Thanks,
Yuanlong on behalf of all authors

From: Andrew G. Malis [mailto:[email-masked]]
Sent: Friday, June 10, 2016 3:00 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Shepherd’s review of draft-ietf-pals-mc-pon-03

Authors,

This review should be treated as any other last call review. The draft can be updated to reflect all received comments following the end of WG last call.

In general, I found the draft to be extremely well written and easy to follow, and only have a few comments on it. I also note that it cleanly passes IDNits, that is appreciated.

Section 1: This section provides a good introduction to PON resilience for people not previously familiar with it.

Reference to [SEAMLESS-MPLS]. Unfortunately, draft-ietf-mpls-seamless-mpls-07 was never published and is now dead, so it cannot be used as a reference, even an informative one (which is a shame, I thought it was a very good draft). A quick Google search didn’t turn up a good replacement reference, such as a journal article, but I’ve asked a few people if they know of one. In the absence of a replacement, this reference will have to removed. Note that RFC 7032 was able to get away with this reference because the seamless MPLS draft was still alive at that time. However, the reference is just a minor one, and I don’t really see a problem in removing it if necessary.
 [JY] Remove both the offending text in the introduction and the reference.

Reference to [TR-221]: You should include the URL in the reference, https://www.broadband-forum.org/technical/download/TR-221.pdf .
[JY] Added.

Reference to [WT-331]: Unfortunately, the BBF doesn’t allow outside references to working texts, as they aren’t available to non-BBF members. So this reference needs to be removed.
 [JY] Removed

Reference to [ICCP]: Throughout the document, the reference [ICCP] should be changed to [RFC7275] for consistency with the other references.
 [JY] Done

You are requesting four consecutive values from the ICC RG Parameter Types registry, which is fine, but you seem to be requesting them from the “Expert Review” range, rather than the “IETF Review” range, which is the proper range for a standards-track RFC.  So I would make the following changes:

1. Change each of the four TLV diagrams to use Type=TDB1, Type=TBD2, and so on, rather than the current Type=0x00XX. Also update each of the TLV descriptions to match.
 [JY] Good suggestion, done

6<https://tools.ietf.org/html/draft-ietf-pals-mc-pon-03#section-6>. IANA Considerations

   sub-registry:

   TBD1         PON Connect TLV

   TBD2         PON Disconnect TLV

   TBD4         PON State TLV

 [JY] Done

Section 5:

I’m curious what you mean by “compromised” with regard to a PE. Since ICCP is meant to be deployed in "well-managed and highly monitored networks” (that’s from RFC 7275), that would presumably apply to the PEs as well. I suggest you go into more detail in the second paragraph, as I’m sure a request for more detail will come up during IESG review. Also, it wouldn’t hurt to include something along the lines of: “Similar to ICCP itself, this ICCP application SHOULD only be used in well-managed and highly monitored service provider PON access networks.”
[JY] we suggest the following texts for Section 5 “Security Considerations” to address the concern, please have a review:
“Similar to ICCP itself, this ICCP application SHOULD only be used in well-managed and highly monitored service provider PON access networks, including the implementation of rogue ONT attachment detection/mitigation via device authentication, and etc. Thus many of the security considerations as described in [RFC7275] apply here as well.
Again, similar to ICCP, activity on the attachment circuits may cause security threats or be exploited to create denial-of-service attacks.  In many passive optical networks the optical path between OLT and ONTs traverses publicly accessible facilities including public attachments (e.g. telephone poles), which opens up the risk of excessive link bouncing by optical layer impairment. Other risks include the malicious ONT can lead to excessive ICCP exchanges similar to the malicious CE case as  described in [RFC7275].  Operators of such networks should take additional care to restrict unauthorized ONTs and to limit the impact of link bouncing as these could result in service impairment.”

Thanks,
Andy

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 15 Jun 2016 23:16:37 +0800

Yuanlong,

That mostly looks fine. I did just a bit of cleanup on your new security
considerations:

“Similar to ICCP itself, this ICCP application SHOULD only be used in
well-managed and highly monitored service provider PON access networks,
including the implementation of rogue ONT attachment detection and
mitigation via device authentication. Thus many of the security
considerations as described in [RFC7275] apply here as well.

Again, similar to ICCP, activity on the attachment circuits may cause
security threats or be exploited to create denial-of-service attacks.  In
many passive optical networks, the optical paths between OLT and ONTs
traverse publicly accessible facilities, including public attachments (e.g.
telephone poles), which opens up the risk of excessive link bouncing by
optical layer impairment. Other risks include a malicious ONT, which can
lead to excessive ICCP exchanges similar to the malicious CE case described
in [RFC7275].  Operators of such networks should take additional care to
restrict unauthorized ONTs and to limit the impact of link bouncing, as
these could result in service impairment.”

Thanks,
Andy

On Wed, Jun 15, 2016 at 9:02 PM, Jiangyuanlong <[email-masked]>
wrote:

> Hi Andy and all,
>
>
>
> Many thanks to these good suggestions. Please see my comments inline,
> especially the new texts suggested by us on Section 5.
>
> *From:* Andrew G. Malis [mailto:[email-masked]]
> *Sent:* Friday, June 10, 2016 3:00 AM
> *To:* [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Shepherd’s review of draft-ietf-pals-mc-pon-03
>
>
>
> Authors,
>
>
>
> 1. Change each of the four TLV diagrams to use Type=TDB1, Type=TBD2, and
> so on, rather than the current Type=0x00XX. Also update each of the TLV
> descriptions to match.
>
> 6 <https://tools.ietf.org/html/draft-ietf-pals-mc-pon-03#section-6>. IANA
> Considerations
>
>
>
>
>
> [JY] we suggest the following texts for Section 5 “Security Considerations”
> to address the concern, please have a review:
>
> “Similar to ICCP itself, this ICCP application SHOULD only be used in
> well-managed and highly monitored service provider PON access networks,
> including the implementation of rogue ONT attachment detection/mitigation
> via device authentication, and etc. Thus many of the security
> considerations as described in [RFC7275] apply here as well.
>
> Again, similar to ICCP, activity on the attachment circuits may cause
> security threats or be exploited to create denial-of-service attacks.  In
> many passive optical networks the optical path between OLT and ONTs
> traverses publicly accessible facilities including public attachments (e.g.
> telephone poles), which opens up the risk of excessive link bouncing by
> optical layer impairment. Other risks include the malicious ONT can lead to
> excessive ICCP exchanges similar to the malicious CE case as  described in
> [RFC7275].  Operators of such networks should take additional care to
> restrict unauthorized ONTs and to limit the impact of link bouncing as
> these could result in service impairment.”
>
>
>
> Thanks,
>
> Andy
>
>
>
>
>
>
>
>
>
>
>
>
>

---

From: Jiangyuanlong <[email-masked]>
Date: Thu, 16 Jun 2016 02:00:44 +0000

Andy,

It’s much better, we’ve updated  the texts.
The new version is uploaded now, please see the following link:
   https://tools.ietf.org/html/draft-ietf-pals-mc-pon-04

Thanks!
Yuanlong

From: Andrew G. Malis [mailto:[email-masked]]
Sent: Wednesday, June 15, 2016 11:17 PM
To: Jiangyuanlong
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Shepherd’s review of draft-ietf-pals-mc-pon-03

Yuanlong,

That mostly looks fine. I did just a bit of cleanup on your new security considerations:

“Similar to ICCP itself, this ICCP application SHOULD only be used in well-managed and highly monitored service provider PON access networks, including the implementation of rogue ONT attachment detection and mitigation via device authentication. Thus many of the security considerations as described in [RFC7275] apply here as well.

Again, similar to ICCP, activity on the attachment circuits may cause security threats or be exploited to create denial-of-service attacks.  In many passive optical networks, the optical paths between OLT and ONTs traverse publicly accessible facilities, including public attachments (e.g. telephone poles), which opens up the risk of excessive link bouncing by optical layer impairment. Other risks include a malicious ONT, which can lead to excessive ICCP exchanges similar to the malicious CE case described in [RFC7275].  Operators of such networks should take additional care to restrict unauthorized ONTs and to limit the impact of link bouncing, as these could result in service impairment.”

Thanks,
Andy

On Wed, Jun 15, 2016 at 9:02 PM, Jiangyuanlong <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy and all,

Thanks,

From: Andrew G. Malis [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, June 10, 2016 3:00 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Shepherd’s review of draft-ietf-pals-mc-pon-03

Authors,

   sub-registry:

   TBD1         PON Connect TLV

   TBD2         PON Disconnect TLV

   TBD4         PON State TLV

Section 5:

Thanks,
Andy