Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks
RFC 4797

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

(Mark Townsley; former steering group member) Yes

Yes ()
No email
send info

(Ross Callon; former steering group member) Yes

Yes ()
No email
send info

(Thomas Narten; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Alex Zinin; former steering group member) No Objection

No Objection (2004-10-28 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
> 4. Motivations
...
>  In this procedure, the ingress and egress PE routers themselves MUST
>   support MPLS, but that is not an issue, as those routers MUST
>   necessarily have BGP/MPLS IP VPN support, whereas the transit routers
>   arguably should be able to be "vanilla" routers with no special MPLS
>   or VPN support.

The two upper-case MUSTs above don't seem to be normative and should be
lower-cased.

(Allison Mankin; former steering group member) No Objection

No Objection (2004-11-18 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I wish Defers resulted in showing the document as returning (even one as memorious as I
can forget :)

I'm going to give a No (Further) Objection, but as TSV, my concern is with the
non-statement of the additional dilution of possible QoS interactions.  2547 is
a routing technology, but 2547 has a comment about constructing QoS or TE
based on managing the MPLS in the customer premises and linking it to TE or
QoS measures in the Service Provider.  (See below for the section from 2547bis,
which states that QoS is a key factor for VPN use, as its first sentence).  If there
is a dynamic, who-knows-what-nature, tunnel hop, that is invisible and unannounced
to the customer, then 2547bis with these tunnels has lower service potentials than
2547bis without them.  The paragraph:

   Although not the focus of this paper, Quality of Service is a key
   component of any VPN service.  In MPLS/BGP VPNs, existing L3 QoS
   capabilities can be applied to labeled packets through the use of the
   "experimental" bits in the shim header [MPLS-ENCAPS], or, where ATM
   is used as the backbone, through the use of ATM QoS capabilities.
   The traffic engineering work discussed in [MPLS-RSVP] is also
   directly applicable to MPLS/BGP VPNs.  Traffic engineering could even
   be used to establish label switched paths with particular QoS
   characteristics between particular pairs of sites, if that is
   desirable.  Where an MPLS/BGP VPN spans multiple SPs, the
   architecture described in [PASTE] may be useful.  An SP may apply
   either intserv (Integrated Services) or diffserv (Differentiated
   Services) capabilities to a particular VPN, as appropriate.

(Bert Wijnen; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Bill Fenner; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Cullen Jennings; former steering group member) No Objection

No Objection ()
No email
send info

(Dan Romascanu; former steering group member) No Objection

No Objection ()
No email
send info

(David Kessens; former steering group member) No Objection

No Objection (2004-10-27 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
From Pekka Savola, OPS directorate:

I share Steve's concerns (in the tracker).

FWIW, I tried to get some better text in
draft-ietf-mpls-in-ip-or-gre-08.txt (which is used as a building block
here) which would have somewhat mitigated the problems (so that packet
injection would have been impossible inside single-provider networks),
but in the end I was overrun.

(I think that spec needed better discussion of source/destination
address spoofing concerns, and I'd have wanted to require that the
decapsulators check that the source address of the tunnel packet is
coming from a valid peer (=source address), not just anyone at all.)

(Jon Peterson; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection ()
No email
send info

(Russ Housley; former steering group member) (was Discuss, No Objection) No Objection

No Objection ()
No email
send info

(Sam Hartman; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Scott Hollenbeck; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Steven Bellovin; former steering group member) (was Discuss) No Objection

No Objection (2004-10-28)
No email
send info
Russ has picked up the token for my DISCUSS

(Harald Alvestrand; former steering group member) Abstain

Abstain (2004-11-17 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I am abstaining because I can't figure out whether this is something with "no more danger than what people ordinarily do" or something that exposes users to a significant additional risk.

Reviewed by Mary Barnes, Gen-ART

Her review:

Overall, from an editorial perspective, this document appears ready for publication. However, although I'm not an SME in this area, I too share some of the concerns and comments raised around the security issues and the limited applicability (single SP).  I would think publishing this as Informational/BCP as to how one could do this sort of functionality if it were deemed useful in this restrictive situation would be better than publishing as Proposed Standard.

(Ted Hardie; former steering group member) Abstain

Abstain (2004-10-25 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
This text in section 6:

   The filtering described in the previous paragraph works only within a
   single SP network. It is not clear whether (and how) this filtering
   could be extended to support multiple SP networks. That makes the
   scheme described in this document fairly problematic in the multi-
   provider environment. makes me wonder at the overall utility of this. 

 causes me to abstain from this document.  I am generally concerned with
the over-dependence on tunnels and overlay networks, and this restriction
just convinces me the utlity of this is too small.