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

Re: MS-SPring [Was: Moving forward with the CCAMP charter]

diego

given the high number of MS-SPRing protected transport network
already deployed seems reasonable to me, from a Network Operator point of
view, to use at the same time MS-SPRing protection with GMPLS
restoration.


there are already two questions here 1. is there an operational need to
control such rings using GMPLS (? for instance is it effective knowing
that ring based protection is mainly data plane driven ?)
[dc] I prefer to hear something from the Operator here even if my
experience tell me that the answer is yes.

i don't have the full answer either - the question is to address such considerations and tradeoffs

and 2. how to position the ring protection wrt to the LSP recovery
segment/end-to-end
recovery
[dc] I'm sure I've got the point here sorry, what exatly do you mean with
position?


some examples (not exhaustive):

will it be seen as link protection for some links used by the end-to-end LSP or LSP segment protection of end-to-end LSP or both ?

otoh would it be possible to assume SDH ring protection on top of nodes interconnected by recoverable Lambdas ?

Let's say the first failure is recovered via MS-SPRing in less than 50 ms
while subsequent failures can be recovered via GMPLS restoration with
lower performance.
is it because it is a "local" protection (i.e. wouldn't a segment
recovery provide the same time efficiency) or because it is ring based
[dc] It is because is performed at the SDH layer, all the SDH protection
scheme I know have the same performance (e.g. SNCP, MSP) 

so it is the former i.e. "local-(data-plane driven) protection"

by the way if you plan to start such document a terminology section inserted w/i an informative appendix would help the IETF reader

Basically that is the rationale behind my initial question.

What is your view on that? 

my view is that a problem statement should cover such base questions - i
am in agreement with adrian stand here -
[dc] I'm trying to put togheter a requirement doc that briefly illustrates
how MS-SPRing works and what are the information that it needs in order to
work corretly.

i don't think there is a need to step into the details of "how it works" in the first phase (an 1-page summary would be enough here, at the end good references are available) but "why/where it makes sense" and "what does it imply" the above discussion is a sample of considerations that such document should address as i wouldn't step in without having an overall picture of the landscape

Regards

Diego



dimitri papadimitriou <dpapadimitriou@psg.com> on 17/08/2005 14.43.17

Please respond to dpapadimitriou@psg.com; Please respond to
      dimitri.papadimitriou@alcatel.be

To:    richard.spencer@bt.com
cc:    dimitri.papadimitriou@alcatel.be, Diego.Caviglia@marconi.com,
      adrian@olddog.co.uk, ccamp@ops.ietf.org

Subject:    Re: MS-SPring [Was: Moving forward with the CCAMP charter]



richard,



Dimitri,

"why (and where) ring topologies are suitable" ?

Transport networks (e.g. SONET/SDH, WDM, RPR) have been, and will
continue to be, widely deployed based on (dual) ring topologies in
the access/metro because they provide fast protection and reliability
whilst making efficient use of fibre.

I do not think this can be disputed so I don't understand where you
are coming from with this question?



while i do not see why this can't be discussed (e.g. there are dozens of
studies available on this topic) and i can just point out that one can
deliver fast (time efficient), resource efficient and reliable
protection without using rings

therefore, it would worth having some operational feedback and state
what are the real drivers and rationales if such topic is getting
started i.e. what is the real appealing rationale behind this mechanism

note: these are just questions that i think where missing from most
documents produced on this topic since so far and that are important to
be addressed

last point you are mentioning RPR so what would be the interaction with
the IPORPR WG ?



Regards, Richard




.












.











.