Skip to main content

Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode
draft-ietf-l1vpn-applicability-basic-mode-05

Yes

(David Ward)

No Objection

(Chris Newman)
(Cullen Jennings)
(Jari Arkko)
(Magnus Westerlund)
(Ron Bonica)
(Russ Housley)

Note: This ballot was opened for revision 05 and is now closed.

(David Ward; former steering group member) Yes

Yes ()

                            

(Ross Callon; former steering group member) Yes

Yes (2008-03-26)
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).

(Chris Newman; former steering group member) No Objection

No Objection ()

                            

(Cullen Jennings; former steering group member) No Objection

No Objection ()

                            

(Jari Arkko; former steering group member) No Objection

No Objection ()

                            

(Magnus Westerlund; former steering group member) No Objection

No Objection ()

                            

(Mark Townsley; former steering group member) (was Discuss, No Objection) No Objection

No Objection (2008-03-27)
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.

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Tim Polk; former steering group member) (was No Record, Discuss) No Objection

No Objection (2008-03-26)
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.