[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ason-routing-reqts: issue 3 evolution



ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt

The third DT issue is on the support of GMPLS for evolution (from the draft):

In order to support operator assisted changes in the containment relationships of RAs, the GMPLS routing protocol is expected to support evolution in terms of number of hierarchical levels of RAs (adding and removing RAs at the top/bottom of the hierarchy), as well as aggregation and segmentation of RAs. These GMPLS routing capabilities are considered of lower priority as they are implementation specific and their method of support should be evaluated on per-protocol basis e.g. OSPF vs IS-IS. In addition, support of non-disruptive operations such as adding or removing a hierarchical level of RAs in or from the middle of the routing hierarchy are considered as the lowest priority requirements. Note also that the number of hierarchical levels to be supported is implementation specific, and reflects a containment relationship e.g. a RA insertion involves supporting a different routing protocol domain in a portion of the network.
Note: some members of the Design Team question if the ASON requirement for supporting architecture evolution is a requirement on the routing protocol (protocol specific capability) vs. a capability to be provided by the architecture. For example, ASON allows for supporting multiple protocols within each RA. The multiple protocols share a common routing information database (RDB), and the RDB is the component, which needs to support architecture evolution. The Design Team invites CCAMP input to understand the protocol-specific impacts. 
Deborah