[L1vpn] draft-ietf-l1vpn-applicability-basic-mode-05.txt

Hi Dave,

We believe that we have made all of the appropriate changes after IESG
review.

The Comments and Discusses visible at
https://datatracker.ietf.org/idtracker/draft-ietf-l1vpn-applicability-basic-mode
are addressed as follows:

We hope that the I-D is now ready to move forward.

Thanks,
Adrian

===
Ross Callon - Comment

Note that the CCAMP working group email list was very appropriately informed
of the last call that took place on the L1VPN WG list, in order ensure that
CCAMP folks were aware of this (although there was already a large overlap
in participation).
---
No action taken
===
Tim Polk - Discuss

I consider the following issue from Catherine Meadows secdir review
blocking:

    1. The sections on data plane and control plan security need to be
     explicit about when confidentiality, integrity, authentication, or any
     combination of the above are being provided.  E.g. RSVP-TE can
     provide integrity, while IPSEC provides all three.

I believe revisions to sections 8.3 and 8.4 are needed.
---
We have reworked sections 8.3 and 8.4.
Our objective was to show which security techniques could protect against
the security vulnerabilities identified.
===
Tim Polk - Comment

The following issue was raised by Catherine Meadows in a secdir review:

  2.  The description of how RSVP-TE provides tamper protection is actually
   in RFC 2205 (on RSVP), not RFC 3209.  RFC 3209 makes no changes to
   the way tamper-protection is done in RSVP as far as I can tell.  It would
   probably be best to reference both.

I agree with her opinion, but this issue is not blocking.
---
We have sent some email to Tim to explain our thinking here. We do not
consider it is appropriate to itemise all of the nested references necessary
to provide full security with RSVP-TE. Instead, we consider it correct to
make reference to the base RSVP-TE RFC (3209) and leave the process of
chasing references to the reader.

Therefore we have made no changes.
===
Mark Townsley - Comment

In general, there seems to be a lot of overlap with rfc4847 in this
document. Is it really necessary?

Section 6.1:

"In the L1VPN Basic Mode, L1VPN connection topology is controlled by the
customer. That is, a customer can request"

Please clarify that this is the CE-CE connection topology, not the provider
network topology which in basic mode is not under direct customer control
(at least as I understand the difference between basic and enhanced l1vpn
modes).

I believe there may be some overlap in function between the CPIs/PPIs
described here, and the (TAI/SAI) constructs which we have in L2VPN
(draft-ietf-l2vpn-signaling, in RFC Ed. Q). I strongly suggest a review of
this, and when it comes time to write the solution perhaps some of this work
can be reused.
---
a. There is overlap between 4847 and this I-D. We could have limited this
  I-D to a pure applicability I-D that only shows how to achieve the
  function described in the framework RFC. We considered that it would
  be helpful to give more context in the text at the cost of some 
repetition.
b. The overview section of the I-D that introduces the Basic Mode states...
   "In the L1VPN Basic Mode, the provider network is completely under the
    control of the provider. This includes the PE-PE segment of the CE-CE
    L1VPN connection that is controlled and computed by the provider (PE-
    PE segment control)."
    We believe this addresses the comment (by confirming the point).
c. The L1VPN model is not trying to address the SVC VPN model as used
   in L2VPNs. We believe that there is no overlap in function with the L2VPN
   work. The issue of overlap between other VPN and pseudowire work was
   discussed at a special meeting of WG chairs and ADs convened at the 67th
   IETF in San Diego - no concerns were found. Nevertheless we have
   initiated discussion with the L2VPN chairs - as yet we have had no
   response.
=== 

_______________________________________________
L1vpn mailing list
L1vpn@ietf.org
https://www.ietf.org/mailman/listinfo/l1vpn