Skip to main content

Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3
RFC 4817

Yes

(Ross Callon)

No Objection

Lars Eggert
(Bill Fenner)
(Brian Carpenter)
(Cullen Jennings)
(David Kessens)
(Jon Peterson)
(Magnus Westerlund)

Recuse

(Mark Townsley)

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

Lars Eggert (was Discuss) No Objection

(Ross Callon; former steering group member) Yes

Yes ()

                            

(Sam Hartman; former steering group member) Yes

Yes (2006-10-24)
I think this draft goes a long way to addressing one of my concerns
with the requirement for traffic isolation in L3VPNs and L2VPNs
configured automatically in an IP core.  In these environments traffic
isolation, rather than integrity or confidentiality is the mandatory
to implement security service (see RFC 4031).

(Bill Fenner; former steering group member) No Objection

No Objection ()

                            

(Brian Carpenter; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Cullen Jennings; former steering group member) No Objection

No Objection ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection (2006-10-25)
It would be good if the applicability discussion in Section 4 would refer to the fact that Section 3 places the method of assigning the Session ID and Cookie out of scope. Such an observation would be important to make explicitly, because in the absence of a method of assigning L2TPv3 cookies real life deploymentes would be very complex, IMO.

(David Kessens; former steering group member) No Objection

No Objection ()

                            

(Jari Arkko; former steering group member) No Objection

No Objection (2006-10-25)
> This document defines how to carry an MPLS label stack and its
> payload over L2TPv3. 

This is in fact incorrect. It defines how to carry it
over the L2TPv3 data encapsulation, not the entire
protocol.

(Jon Peterson; former steering group member) No Objection

No Objection ()

                            

(Magnus Westerlund; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection (2006-10-24)
  From the SecDir Review by Donald E. Eastlake III:

  This document uses "PE" all over the place without defining it.

  There are multiple references to "ACL" and in one case "access
  lists" without much clarity as to exactly what these are. I assume
  they are filters on packet header fields.

(Ted Hardie; former steering group member) (was Discuss) No Objection

No Objection (2006-10-24)
The document says:

       While the Session
      ID may be encoded and assigned any value (perhaps optimizing for
      local lookup capabilities, redirection in a distributed forwarding
      architecture, etc.), the Cookie MUST be selected as a
      cryptographically random value [RFC4086], with the added
      restriction that it not be the same as a recently used value for a
      given Session ID. 


Is there any guidance on what a reasonable value for retention might be,
given the "not be the same as a recently used value"?

(Mark Townsley; former steering group member) Recuse

Recuse ()