[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Ready to send MLN liaison?
Hi Adrian,
Considering several items are questions related to multilayer and
multidomain, may want to add that the mln-reqs authors have updated the
scope to include Section 3.3's discussion and reference to RFC4726.
Another reference which may be of interest to Q14 is RFC4655 which
discusses PCE multilayer-multidomain. Suggest on item 1 to add:
"Note, this document references RFC4726 for interconnection of MRN/MLN
TE domains (refer to updated Section 1 and Section 3.3). Another RFC of
possible interest on multilayer-multidomain discusion is RFC4655 (PCE)."
Deborah
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Adrian Farrel
Sent: Wednesday, August 15, 2007 9:50 AM
To: ccamp@ops.ietf.org
Subject: Ready to send MLN liaison?
Hi,
We now have both I-Ds (reqs and eval) ready to share with the ITU.
We also have a draft liaison that has been discussed a bit on the list
and
in private.
I want to make sure that you are all happy with the text before I go
ahead.
I think I have incorporated the thrust of Igor's comments, but I may not
have got the balance quite right. The main point seems to hinge on the
interpretation of the word "potential". While I agree with Igor that the
virtual TE-link is advertised in the client layer *exactly* like a real
TE-link, it is nevertheless not really there - it is only potenially
there,
and an attempt to use it may fail because the server layer LSPs may fail
to
be set up. At the same time, the server layer LSPs (trails) that would
support the virtual TE-link are only potential, so we can also say that
the
connectivity in the server layer is potential. I have changed the
wording to
reflect potential connectivity in both layers.
The finer distinction that Igor makes between "potential connectivity"
in
the client layer and a "potential connection" in the server layer is
useful,
and I have tried to incorporate it.
The changes are in the answers to:
- point 5
- Q1-a
- Q1-b
- Q1-c
Cheers,
Adrian
===
From : IETF CCAMP Working Group
To : ITU-T Study Group 15 Question 14
For : Action
Deadline : 20 September 2007
Subject : Multi-Region and Multi-Layer Networking
The CCAMP working group of the IETF thanks you for your
liaison titled "Follow up Liaison Statement to IETF CCAMP on
Multi-Layer Networking" generated from your May 2007 interim
meeting.
This communication provides answers and explanations in
response to the comments and questions that your liaison
raised.
As previously indicated, the CCAMP working group is ready to
hold a working group last call on these two Internet-Drafts.
However, in view of your comments and interest in this work we
are delaying this last call to allow you to consider our
responses and to provide further comments during your
September interim meeting. Any additional comments that you
supply will be treated as working group last call comments and
handled accordingly.
Working Group last call will complete on 21 September 2007 at
12 noon GMT. Please ensure that any comments are received by
the IETF before that time.
The latest copies of the drafts concerned can be found at
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-reqs-05.t
xt
and
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-eval-03.t
xt
draft-ietf-ccamp-gmpls-mln-reqs
"1. General - Does this draft apply only to single service
provider or do you envision it applying when there are
multiple service providers? The ASON model (G.8080) allows
for many different configurations of multilayer networks
ranging from a single provider administering all layers
and regions to a different provider per layer or region to
several providers per layer or region. If two layers are
under different administrative domains because they belong
to two different providers, the amount of information that
can be shared between the two domains is more limited than
in the case where a single provider network provides
resources at all layers."
A customer network may be provided on top of the GMPLS-based
multi-region/multi-layer network. It is indeed a strong
motivator for the deployment of multi-region/multi-layer
networks as described in Section 3.2 of the draft. This draft
is, however, scoped to the assumption that the control plane
and the data plane are under the responsibility of a single
service provider and so constitute a single administrative
domain. The MRN/MLN suite of documents makes no assumptions
concerning the interfaces with other domains (e.g. UNI,
E-NNI). In particular, the specific problem examined within
the CCAMP MRN/MLN work is the integration of multiple network
layers (that may be from different regions) within the same
administrative domain. Requirements for multiple network
layers under different administrative domains are out of
scope of this document.
It should be noted that the term region used in the MRN/MLN
suite of documents is as per IETF definition (see RFC4206).
The statement will be added to Section 1 to articulate that
this draft is scoped to the requirements for multi-layer
networks under a single control plane and that the
requirements for multi-layer networks under different
administrative domains are out of scope of this document.
"2. Section 3 - There is an example of several layers of a
TDM region. The addition of a VCAT layer example would be
more complete. For example, VC-4-7v."
Thank you for this suggestion. We have integrated this example
into the I-D.
"3. Section 3.1 - The last paragraph mentions discontinuity
when crossing a region boundary. We would like to point
out that the ASON model does not have control plane
discontinuity when crossing a region boundary as there
are call controllers at each layer. Call controllers at
both ends of adaptation into a server (lower) layer
communicate with each other."
There may be some misunderstanding of the term
"discontinuity". In the context of this section of the draft,
"discontinuity" indicates that it may not be possible to
simply forward the signaling message (i.e. RSVP-TE Path
message) from a node in one layer to a node in the next layer
(even when stitching or 1:1 multiplexing is used) because
there is a necessary change in some of the signaling objects
(for example, the representation of bandwidth) at region
boundaries. We may solve the discontinuity issue in a method
similar to that of ASON by using triggered signaling or any
of the other mechanisms described in this document.
To help clear up the misunderstanding, the last paragraph of
Section 3.1 will be rephrased.
"4. Section 5.3 - Scalability problems can be minimized by
the use of TED per region in case they are under separate
administration or for scalability reason."
It is correct to note that the use of a separate TED per
region can improve the scalability. However, part of the
objective of the MRN/MLN work is to allow full visibility
from each network node into all participating layers/regions.
Splitting the TED will not reduce the amount of information
stored or flooded within the network. Indeed, as multiple
switching capabilities can be advertised in a single TE-link
advertisement, the total number of entries in a TED should
not differ much from a single layer network (although each
entry may be a little larger). Furthermore, the number of
TE-link advertisements should not differ much from a single
layer network (although each advertisement may be slightly
larger), thus not putting additional strain on the routing
protocol flooding process. No scalability problems have been
identified.
Section 5.3 will be further clarified.
"5. Section 5.8.2 - Virtual TE-links - We can think of two
different models and are not sure which one is implied in
this document. The first one is that a virtual TE-link
represents server (lower) layer potential connectivity.
The second one is that a virtual TE-link represents
client (upper) layer potential connectivity. The first
one requires knowledge of the adaptation capabilities by
the client (upper) layer. The second does not require any
knowledge of the adaptation capabilities or even the
existence of the server (lower) layer and should also be
a valid configuration. The second option may be required,
for example, when the different layers are administered
by different entities."
The virtual TE-link represents potential client layer
connectivity that may be achieved through potential server
layer connections. The client layer connectivity is potential
because the TE-link does not actually exist (event though it
is treated in the client layer exactly as though it does
exist). The server layer connections are potential because the
LSPs necessary to support the TE-link have not been set up.
It may be helpful to recap some terminology.
A TE-link is (as discussed in the GMPLS/ASON lexicography set
out in RFC 4397) a logical routing element that allows path
selection to be decoupled from resource assignment. Thus a
TE-link is associated with one or more data links. This is
equivalent to an SNPP link.
A TE-link in one layer may, of course, be achieved by one or
more LSPs in a lower layer. That is, an LSP in one layer may
form a data link in an upper layer.
A virtual TE-link (again referencing RFC 4397) is a TE-link
associated with zero data links. It is the potential for a TE-
link, that may be used in path computation on the assumption
that, if it is used, an attempt will be made dynamically to
create the necessary data link(s). That is, to signal an LSP
in a lower layer, to designate the LSP as a data link in the
upper layer, and to assign the data link to the TE-link.
Thus, the virtual TE-link is dynamically converted into an
actual TE-link.
Advertisement of the virtual TE-link is dependent (just as
with a real TE-link) on the adaptation capabilities at the
end points. As far as client layer network is concerned,
there is no difference between virtual and real TE-links.
In both cases the TE-link is connectivity in the client layer,
but (clearly) with a virtual TE-link, although the
connectivity is advertised as if it is real, it is only
potential.
The principal difference between a real TE-link and a virtual
TE-link is that the server layer network resources are not
tied up when the virtual TE-link is not in use, and that the
signaling process of the client layer LSP might fail if the
virtual TE-link cannot be realized (i.e., if the server layer
LSPs cannot be set up).
"6. Section 4.2 - The last paragraph mentions that TE-link
advertisements may need to provide information about the
node's internal adaptation capabilities in order to
perform layer border node functions. It might be worth
clarifying the instances where this is required versus
not required. For example, if virtual TE-links are used
to represent the client (upper) layer connectivity, it is
not necessary to advertise internal adaptation
capabilities."
There is no difference with respect to real or virtual TE-
links in this regard, and all TE-links (virtual or otherwise)
must be considered with regard to their switching types and
the adaptation capabilities of their end points.
The adaptation capability, enables a node to discriminate the
remote nodes (and thus allows their selection during a multi-
region path computation) with respect to their adaptation
capability. i.e., their capability to terminate LSPs at a
given region.
Please see also RFC4397 for adaptation capability definitions.
draft-ietf-ccamp-gmpls-mln-eval
"1. Section 4.1.1.2 - Setting up virtual TE-links. We would
like to understand why the virtual TE-links need to be
created as opposed to discovered, manually or dynamically.
In terms of scalability, could a virtual TE-link (assuming
it represents server (lower) layer resources) be assigned
a virtual link identifier that may be locally associated
to one or more link identifiers? It is not clear from the
draft whether this is allowed or not but we think it is
essential in developing a scalable solution. In case the
virtual TE-link could represent client (upper) layer
potential connectivity, the identifier would have to be
virtual as it would represent potential adaptation
capability into a server (lower) layer."
First of all, please note again that the requirements for
multi-layer networks under different administrative domains
are out of scope of this document. Advertising the virtual
TE-link into the "client" network, which is under different
administrative domain, is out of scope of this document.
The above question may be separated into three sub-questions
as follows;
Q1-a) Why do the virtual TE-links need to be created as
opposed to discovered, manually or dynamically?
A1-a) It would be possible to automatically discover all
potential connections across the lower layer network
and to advertise a full mesh of virtual TE-links.
However, we believe that this scenario is unlikely to
meet with the requirements of service providers who
will want to apply their own operational policies.
Such operational policies effectively install a
management function (e.g., VNT Manager) between the
analysis of the lower layer potential connections, and
the advertisement of virtual TE-links. However,
nothing precludes from a policy of discovering and
advertising such a full mesh.
Q1-b) Could a virtual TE-link be assigned a virtual link
identifier that may be locally associated to one or
more link identifiers?
A1-b) In general, data link identifiers can be autogenerated
and "discovered" through information exchange between
adjacent nodes. TE-link identifiers can similarly be
autogenerated, and exchanged and associated with data
links. This, however, presupposes the existence of the
data links when the TE-links are created.
The virtual TE-link represents potential connectivity
(as discussed for point 5, above), but does not have a
server layer trail (i.e., a client layer data link)
committed. The virtual TE-links must still be advertised
so that they can be use in path computation. Virtual TE-
link identifiers are assigned at both end points. They
are logical identifiers and are not necessarily
identical to any identifiers associated with the real
physical interfaces. They may be picked from a local
pool of identifiers at both end points and exchanged
between the the end points. On the other hand, assigning
the identifier associated with a real physical interface
to the virtual TE-link is not precluded. Clearly
configuration (manual or through an automated process
such as the Virtual Network Topology Manager) may
provide this information in this case. The use of LMP
for exchange of information for virtual TE-links is for
future study.
Q1-c) In case the virtual TE-link could represent client
(upper) layer potential connectivity, would the
identifier have to be virtual as it would represent
potential adaptation capability into a server (lower)
layer?
A1-c) As described in A1-b), the identifier of the virtual
TE-link could be associated with a real physical
interface. Note, however, that many virtual TE-links
could exist where there is the physical capacity for
only one server layer tail at any time. It may be
convenient to assign each virtual TE-link a different
identifier.
"2. Section 4.1.1.3 - Traffic disruption minimization during
FA release. In case disruption is required in the server
(lower) layer, we think there is also an option to signal
to the adaptation points and let them re-establish the
server (lower) layer as opposed to rely on the head-end
LSRs in the client (upper) layer."
Section 4.1.1.3 does not specify nor preclude any mechanism
to deal with traffic disruption. In the context of the
MRN/MLN, upper layer LSPs may be routed over FAs. For
reasons outside the scope of these documents, an FA may need
to be released or rerouted. This may have a disruptive effect
on the LSPs using this FA in the sense that this would induce
a route change of these upper layer LSPs.
Only the head-end LSR of an (FA-)LSP is responsible for
re-routing or releasing FA-LSPs. As such head-end LSRs
("adaptation points" as stated in the question) are
responsible for rerouting/releasing FA-LSPs and head-end
LSRs of the upper layer LSPs are responsible for rerouting
the LSPs they control. The adaptation points can NOT take
responsibility for rerouting upper layers LSPs over other
(newly established or not) FAs if they are not head-end LSRs
of the upper-layer LSPs but only intermediate LSRs for these
LSPs
The data link created in an upper layer by an FA LSP may be a
protected data link (in the meaning of link level protection
- see RFC 3471). This link level protection may be achieved
by end-to-end protection of the FA LSP, or through any other
LSP protection scheme including LSP restoration. This case
seems to match what you have described, but note that the
process of switching traffic (i.e. the nested LSP) from one
FA LSP to another is likely to cause a small traffic hit in
all but packet/frame technologies.
We would like to thank you for your detailed enquiry into
this topic, and hope that you feel that the discussion has
been fruitful.
Best regards,
Deborah Brungard and Adrian Farrel
IETF CCAMP Co-chairs