Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model
draft-ietf-ccamp-gmpls-overlay-05

[Ballot comment]
Reviewed by Spencer Dawkins, Gen-ART

His review:

This document is ready for publication as a Proposed Standard.

Very minor nits (could certainly be addressed in AUTH48):

- The abstract refers to "the overlay model" without
  explanation. Could a few words be added, something like "the overlay
  model, where edge nodes are unaware of the topology of the core
  nodes"?

- Some terms are introduced without expansion on first use (I noticed
  ERO and RRO).

- I'm not sure what a "lower trust model" is, in Security
  Considerations. Is there a clearer term that could be used ("less
  trust required")?

[Ballot discuss]
Section 8 says:
  >
  > This draft imposes no new security risks over [RFC3473]. In fact it
  > represents a lower trust model between the core and edge-nodes as the
  > core is permitted to hide its topology from the edge-nodes. The core
  > is also permitted to restrict the actions of edge-nodes by filtering
  > out specific RSVP objects.
  >
  I think the notion of a "lower trust model" is inappropriate.  Lower
  from which point of view?  I suggest avoiding the whole issue:
  >
  > The trust model between the core and edge-nodes is different
  > than the one described in [RFC3473], as the core is permitted to
  > hide its topology from the edge-nodes, and the core is permitted
  > to restrict the actions of edge-nodes by filtering out specific
  > RSVP objects.

Rtg-dir review from Dimitri:

o) Technical Comments (minor):

1. Introduction mentions "However, one possible means is
    using a forwarding adjacency as described in [MPLS-HIER]."

-> but forwarding adjacencies are by definitions related to the peer
    model (also, [MPLS-HIER] does not refer to this "hierarchical TE
    link" - see end Section 4 of [MPLS-HIER])

2. Section 3.2: "If the route is not viable, then a PathErr message with
    an error code and value of 24,5 - "No route available toward
    destination" should be returned."

-> "viability" should probably be further detailed

3. Section 3.3: "In order to support explicit label control and full
    identification of the egress link an ingress edge-node may include an
    ERO that consists of only the last hop."

-> unclear why *only* the last hop can be included in such ERO (why this
    sentence does not only determine the behaviour at the last hop being
    the egress core-node)

4. Section 6.2: mapping 2 is not allowed (independently of the presence
    of the Path_State_Removed_Flag from the receiving PathErr) since
    PathErr propagation rule is disrupted as far as the proposed text
    reads

o) Editorial Comments:

1. Spell out the acronyms in the document title (GMPLS, UNI, etc.)

2. in Abstract: "Generalized Multiprotocol Label Switching (GMPLS)
    defines both routing and signaling protocols for the creation of
    Label Switched Paths (LSPs) in various transport technologies."

-> transport technologies might not be the most appropriated in the IETF
    context - suggestion replace it by "switching"

3. Introduction 1): "The four boxes around the edge marked "Overlay
    Network" represent four islands of a single network overlaid
    network"

-> not sure the last part of this sentence is not mispelled

4. Section 3) "If a core-node rejects a Path message due to the presence
    of an ERO it SHOULD return an PathErr message with an error code of
    "Unknown object class" toward the sender. This causes the path setup
    to fail."

-> should point to the RFC 3209 section: "4.3.7. Non-support of the
    Explicit Route Object" as procedures are apparently equivalent

5. Section 5) " Core-nodes may send Notification messages to edge-nodes
    which have included the NOTIFY_REQUEST object."

-> suggested: "Core-nodes MAY send Notify messages to edge-nodes which
    have included the NOTIFY_REQUEST object."

6. Section 5) "In either of the above cases, the a core-node SHOULD NOT
    send Notify messages to the edge-node.

-> edit: "the a"

7. Section 5) "In this case, when NOTIFY messages are received, they
    MAY be selectively (based on local policy) forwarded to the edge-
    node."

-> edit: NOTIFY -> Notify

8. Section 6.1) "An ingress core-node receiving a PathTear without
    having first seen an ADMIN_STATUS object informing it that the
    connection is about to be deleted MAY pause the PathTear and first
    send a Path message with an ADMIN_STATUS object to inform all
    downstream LSRs that the connection is about to be deleted."

-> first time in this document that the term "LSR" appears

9. Update the Informative Reference section with latest version of the
    referenced document

Routing directorate review: 2004-06-22
Reviewer: Loa Andersson

Comments:

Nits: see inline in the format
comment: xxx

or

comment:

xxx

end comment



General:


I'm pretty confortable with this draft and guess with the few nits I've
found ready to do.
I would like some security expert to have a look at the security
considerations it looks weak, but need not be, relying on the 3473
which is a very good security section, it need not be aproblem.

One other thing is that we might have to start write managability
considerations, built the way it is specified what are the management
issues, but this is not for this spec in particular, but rather something
to be thought about

/Loa
>
>      Overlay                                                  Overlay
>      Network      +----------------------------------+      Network
>    +---------+    |                                  |    +---------+
>    |  +----+ |    |  +-----+    +-----+    +-----+  |    | +----+  |
>    |  |    | |    |  |    |    |    |    |    |  |    | |    |  |
>    | -+ EN +-+-----+--+ CN  +----+ CN  +----+  CN +---+-----+-+ EN +- |
>    |  |    | |  +--+--|    |    |    |    |    |  |    | |    |  |
>    |  +----+ |  |  |  +--+--+    +--+--+    +--+--+  |    | +----+  |
>    |        |  |  |    |          |          |      |    |        |
>    +---------+  |  |    |          |          |      |    +---------+
>                |  |    |          |          |      |
>    +---------+  |  |    |          |          |      |    +---------+
>    |        |  |  |  +--+--+      |      +--+--+  |    |        |
>    |  +----+ |  |  |  |    |      +-------+    |  |    | +----+  |
>    |  |    +-+--+  |  | CN  +---------------+ CN  |  |    | |    |  |
>    | -+ EN +-+-----+--+    |              |    +---+-----+-+ EN +- |
>    |  |    | |    |  +-----+              +-----+  |    | |    |  |
>    |  +----+ |    |                                  |    | +----+  |
>    |        |    +----------------------------------+    |        |
>    +---------+                Core Network                  +---------+
>      Overlay                                                  Overlay
>      Network                                                  Network
>
>                                              Legend:  EN  -  Edge Node
>                                                        CN  -  Core Node
>
>                    Figure 1:  Overlay Reference Model

comment:
what is the implication of the connection of the EN at the
lower left to two separate CN's, does this represent a coordinated
UNI or two instances of the UNI?
end comment

comment: what does the overlayed network look like from the overlayed
network perspective?




    Overlay                                                  Overlay
    Network      +----------------------------------+      Network
  +---------+    |                                  |    +---------+
  |  +----+ |    |                                  |    | +----+  |
  |  |    | |    |                                  |    | |    |  |
  | -+ EN +-+-----+                                  +-----+-+ EN +- |
  |  |    | |  +--+                                  |    | |    |  |
  |  +----+ |  |  |                                  |    | +----+  |
  |        |  |  |                                  |    |        |
  +---------+  |  |                                  |    +---------+
                |  |                                  |
  +---------+  |  |                                  |    +---------+
  |        |  |  |                                  |    |        |
  |  +----+ |  |  |                                  |    | +----+  |
  |  |    +-+--+  |                                  |    | |    |  |
  | -+ EN +-+-----+                                  +-----+-+ EN +- |
  |  |    | |    |                                  |    | |    |  |
  |  +----+ |    |                                  |    | +----+  |
  |        |    +----------------------------------+    |        |
  +---------+                Core Network                  +---------+
    Overlay                                                  Overlay
    Network                                                  Network

or

    Overlay                                                 
    Network                                               
  +------------------------------------------------------------------+
  |  +----+                                                  +----+  |
  |  |    +--------------------------------------------------+    |  |
  | -+ EN +------------------------------------------+  +---+ EN +- |
  |  |    +----+    +-------------------------------0---0---+    |  |
  |  +----+    |    |                              |  |  +----+  |
  |            |    |                              |  |          |
  |            |    |                              |  |          |
  |            |    |                              |  |          |
  |            |    |                              |  |          |
  |            |    |                              |  |          |
  |  +----+    |    |                              |  |  +----+  |
  |  |    +----+    |                              |  +---+    |  |
  | -+ EN +----------+                              +-------+ EN +- |
  |  |    +--------------------------------------------------+    |  |
  |  +----+                                                  +----+  |
  |                                                                  |
  +------------------------------------------------------------------+
   
or is this just different abstraction levels, if so is the difference
between the modified models tht the first is pre-provisioning and the
second the provisioned netowrk?

end comment   

...
>    In the overlay model there may be restrictions on what may be
>    signaled between an edge-node and a core-node.  This memo addresses
>    the application of GMPLS to the overlay model.  Specifically it
>    addresses RSVP procedures between an edge-node and a core-node in the
>    overlay model.  All RSVP procedures are assumed to be identical to
>    [RFC3473] except as noted in this document.

comment:
the use of rsvp vs. rsvp-te, rfc's 2205, 3209 and 3473 has the
same protocol number (rsvp), but it is not helpful to hide those rather
distinctvie uses of the same protocol behind the same name;
would suggest that the sentence should be something like:

All signaling procedures are assumed to be identical to the GMPLS extesnions
specified in RFC34 [RFC3473] except as noted in this document.

end comment

>
>
>    This document primarily addresses interactions between an edge-node
>    and it's adjacent (at the data plane) core-node. 

comment:
what is the implications here? could singaling be between the
EN and some other node in the Core Network for connectivity through the
data plane adjacent CN? Isn't it control plane adjacency that is described.
Or are they assumed to be identical.

end comment

...

>
> 2. Addressing
>
>    Addresses for edge-nodes in the overlay model are drawn from the same
>    address space as the edge-nodes use to address their adjacent core-
>    nodes.  This may be the same address space as used by the core-nodes
>    to communicate among themselves or it may be a VPN space supported by
>    the core-nodes as an overlay.
>
>    To be more specific, an edge-node and its attached core-node must
>    share the same address space which is used by GMPLS.  A set of
>    tuples share the same address space if the
>    edge-nodes in the set could establish LSPs (through the core-nodes)
>    among themselves (note that edge-nodes in the set may be a subset of
>    all the edge-nodes).

comment:
        "a subset of all the edge nodes in the same overlay network".       
          or
        "a subset of all the edge nodes connected to the same core network".
          or
        "a subset of all the edge nodes connected to the same core node".
        (?)
        if the latter case is true is the implication that EN's belonging
        to differnt overlay network needs to have the same address space
        ... will overlapping address spaces be possible?
        ... private addresses in the overlayed network
        ... private addresses for the  tuples?
end comment

>    The address space used by the core-nodes to
>    communicate among themselves may, but need not be shared with the
>    address space used by any of the  tuples.
>
>    An edge-node is identified by either a single IP address representing
>    its Node-ID, or by one or more numbered TE links that connect the
>    edge-node to the core-nodes.  Core-nodes are assumed to be ignorant
>    of any other addresses associated with an edge-node (i.e. addresses
>    which are not used in signaling connections through the GMPLS core).
>
>    An edge-node need only know its own address, an address of the
>    adjacent core-node, and know (or be able to resolve) the address of
>    any other edge-node to which it wishes to connect.

comment:
  as well as the addresses used in the overlay network island of which
  it is a part
end comment
         
>
>    A core-node need only know (and track) the addresses on interfaces
>    between that core-node and its attached edge-nodes, as well as the
>    Node IDs of those edge-nodes.  In addition, a core-node needs to know
>    the interface addresses and Node IDs of other edge-nodes to which an
>    attached edge-node is permitted to connect.
...
> 7. VPN Connections
>
>    As stated in the addressing section above, the extensions in this
>    document are designed to be compatible with the support of VPNs.
>    Since the core network may be some technology other than GMPLS, no
>    mandatory means of mapping core connections to access connections is
>    specified.  However, when GMPLS is used for the core network, we
>    RECOMMEND the following procedure which is based on [LSP-HIER].

comment

purely a nit - RECOMMEND is not part of the RFC2119-words, it says
RECOMMENED, I'm not sure if there's a difference, but if there is it
should be esy to re-write

end comment
>
>    The VPN connection is modeled as being three hops.  One for each
>    access link and one hop across the core network.
>