Re: Moving right along ...

[Zhi-Wei Lin <zwlin@lucent.com>]

Hi Sudheer,

I'm not sure if you can say choose one solution. It really depends on 
which you're more comfortable with. In IETF, we can choose a solution 
based on IP. In other groups that are more inclusive of other than IP, 
there may be other solutions that are non-IP, but also have IP.

As to your other email about private UNI (I want to combine to one 
email), I think you need to be careful. What exactly is private UNI that 
is not supported by I-NNI or E-NNI? From what I understand all these 
interfaces (ASON calls these reference points) allows varying of 
information exchange based on policy applied to them. If you're defining 
private UNI as one instance of NNI with specific info fixed, then I can 
imagine other variations that could create new interfaces. Do we want 
many interfaces?

For example, I'm assuming that private UNI will have some ER object, and 
also security? How would this be different from E-NNI? One thing that I 
think we need to do is first see what reasons are there for creating 
this instead of simply creating them because there's some slight 
differences. Of course, we'll have some fun discussions in OIF on this 
in a little while...:-)

Zhi



Sudheer Dharanikota wrote:

> Hi Neil:
> 
> Couple of comments.
> 
> neil.2.harrison@bt.com wrote:
> 
> 
>>Hi Mike.....nice to hear from you and I think you make some good points.
>>However, I want to pick-up on one aspect you bring up a few times....and
>>that is 'choice'.  Operators need choice to suit their views on what
>>is/is-not a viable business case.
>>
>>
> 
> Agreed.
> 
> 
>>For example, we have various client layer networks besides IP to
>>accommodate, and of particular importance are managed BW services directly
>>off the L1 fabric, eg VC4 or lambdas say.  However, we can't see any valid
>>business case for generalised BoD/SVCs services here.....I mean, given
>>unknown calling/holding statistics just what capacity would one need to
>>build to to offer a GoS that customers would consider acceptable and that
>>you could get past finance/products people (esp given current climate)?
>>
>>
> 
> If you are assuming GMPLS is suitable for BoD/SVC services only then it
> is an incorrect assumption. GMPLS is providing Connection control and
> RC functions from ASON model. If that is not the assumption please ignore
> this comment.
> 
> 
>>So, on assumption that S-PVC-like services are all that is commercailly
>>viable (in our opinion at least) then you can ask yourself just what
>>additional revenues and/or Opex cost reductions are available from
>>implementating a control-plane solution?  Even this is difficult to justify
>>given:
>>-       current NMS approaches (in SDH) can easily cater for current and
>>foreseeable core trail churn rates;
>>-       the big costs are in access and laying ducts and installing
>>physicals....no control-plane solution is going to impact these.
>>
> 
>>However, assuming you do decide you want to implement a control-plane
>>solution in your transport networks then you really ought to be able to
>>choose the addressing, signalling and routing components on a best-of-breed
>>basis to suit what you want to do.  They are after all, quite disjoint
>>components and there are many architectural possibilities.......and this is
>>what ASON is all about....choice.
>>
>>For example, I could very easily argue that a NSAP + Q.2931/PNNI (signalling
>>aspects only) + centralised routing approach looks the best commercially for
>>what we want to do.  Others may argue that the current GMPLS approach suits
>>them best.  ASON allows this choice.
>>
>>
> 
> Personal opinion:
> Agreed Neil. But it also depends on how well this piece fits in the eventual
> unified network control and management planes :-) We need to move one
> step ahead with our development ...  If we find no problems with GMPLS and
> people are comfortable with IP and MPLS control planes let us move ahead
> with GMPLS. It is a good idea to focus our energy on one rather than
> on multiple technologies.
> 
> Regards,
> 
> sudheer
> 
> 
>>regards, Neil
>>
>>
>>>-----Original Message-----
>>>From: mike.sexton@alcatel.co.uk [mailto:mike.sexton@alcatel.co.uk]
>>>Sent: 25 October 2001 11:49
>>>To: Maarten Vissers
>>>Cc: Sudheer Dharanikota; ccamp@ops.ietf.org
>>>Subject: Re: Moving right along ...
>>>
>>>
>>>
>>>
>>>Maarten,
>>>
>>>In the interests of reconciliation consider the following:
>>>
>>>ASON and G-MPLS are both post hoc conceptual models
>>>describing the same physical and logical network. The
>>>objectives of automation through signalling are broadly
>>>similar. Therefore it would be surprising indeed if the
>>>solutions were widely different. ASON
>>>is indeed based on the layered model of G.805 and deals with
>>>layering issues up-front. GMPLS is derived from the Internet
>>>model which regards the physical layer as flat. When real
>>>world layering is encountered it is dealt with by refinements
>>>many of which
>>>appear in draft-ietf-mpls-lsp-hierarchy-03.txt which is one
>>>of the source documents from which G-MPLS inherits. Here LSP
>>>regions are defined in 6.2 which are as near as I can tell
>>>exactly equivalent to G.805 layer networks. Further, precedence rules
>>>between layers are established with the clear implication
>>>that a higher layer cannot be configured until the
>>>appropriate resources in the lower layer have been
>>>instantiated. The manner in which this may be done is
>>>considered a "local matter". The example
>>>given indicates that a Forwarding Adjacency (equivalent to a
>>>G.805 link supported by one or more trails (LSPs) in the
>>>server layer) may be initiated in various ways including from
>>>an external manager or another (adjacent) LSR. Thus the
>>>example you gave of
>>>a VC-1x layer being set up by signalling and VC-4 layer being
>>>set up by an external planning/management is certainly a
>>>valid implementation within the scope of the G-MPLS solution.
>>>By the same token it is undesirable (and anyway will not be
>>>possible) to
>>>confine signalling to certain layers while reserving others
>>>for management through a standard. Operators will want to
>>>make such important architectural choices on the basis of
>>>optimising their own operation. Once you have agreed on a
>>>signalling protocol to
>>>create connections within a layer network it is generically
>>>applicable to any layer network. Of course making such an
>>>implementation choice (ie management for VC-4, signalling for
>>>VC-1x) is an example of the "local policies" mentioned above.
>>>Such choices
>>>frequently appear as part of some sort of application
>>>specific profile or applications framework on top of the base
>>>generic standard. Note this sort of profiling (if that is the
>>>correct term) is
>>>generally needed to ensure interworking amongst elements
>>>which implement the same generic standard.
>>>
>>>On the last occasion that we studied application of
>>>signalling for transport networks in ITU (over 10 years ago
>>>at the time G.805 was first issued) we had concluded that
>>>connection set-up within a layer was the easy part ie there
>>>were several well
>>>established candidates to choose from (B-ISUP was the
>>>favorite. Neither PNNI nor RSVP existed at that time. ISIS
>>>had already been adopted for DCN in SDH and thus provided
>>>basic neighbour discovery and xSPF computation if required).
>>>The major new problem to
>>>resolve for multi-layer transport networks was indeed
>>>considered to be the desired behaviour at inter-layer
>>>boundaries. It seems that both initiatives have sidelined
>>>this issue as out of scope for the time being.
>>>
>>>regards,
>>>
>>>Mike Sexton
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>Maarten Vissers <mvissers@lucent.com> on 25/10/2001 06:03:38
>>>
>>>
>>>
>>> To:      Sudheer Dharanikota <sudheer@nayna.com>
>>>
>>> cc:      ccamp@ops.ietf.org(bcc: Michael J
>>>          SEXTON/GB/ALCATEL)
>>>
>>>
>>>
>>> Subject: Re: Moving right along ...
>>>
>>>
>>>
>>>
>>>
>>>
>>>Sudheer,
>>>
>>>Another issue is ...
>>>
>>>     - ASON is layer network based, GMPLS is not
>>>
>>>i.e. a request for a connection within ASON is treated within
>>>the boundaries of
>>>one layer network (e.g. within the boundaries of a
>>>VT1.5/VC-11 layer network, or
>>>within the boundaries of a STS-3c/VC-4 layer network). A
>>>VT1.5/VC-11 connection
>>>request is processed within the VT1.5/VC-11 layer network,
>>>using existing
>>>VT1.5/VC-11 links (GMPLS: link bundles). If there is not
>>>enough capacity  in the
>>>VT1.5/VC-11 links to support the request, the call fails.
>>>There is no "hidden"
>>>set up of a STS-1 or VC-4 trail supporting an additional
>>>VT/LOVC link or
>>>extending an existing VT/LOVC link. The set up of an
>>>additional STS-1 or VC-4
>>>trail is supported within the scope of network planning and/or network
>>>engineering. This is separated from the connection set up.
>>>
>>>Regards,
>>>
>>>Maarten
>>>
>>>Sudheer Dharanikota wrote:
>>>
>>>>Hi Maarten:
>>>>
>>>>Maarten Vissers wrote:
>>>>
>>>>
>>>>>Sudheer,
>>>>>
>>>>>At the moment I am unable to briefly summarize the
>>>>>
>>>differences between GMPLS and
>>>
>>>>>ASON. I was working from the perception that GMPLS could
>>>>>
>>>be one of the protocols
>>>
>>>>>supporting ASON. The technical comments I made during the
>>>>>
>>>last 10 months were
>>>
>>>>>based on this perception. Also the last comment
>>>>>
>>>describing the concept of serial
>>>
>>>>>compound link had this basis. Reading Yanhe's reply I had
>>>>>
>>>the impression that
>>>
>>>>>GMPLS is able to support serial compound links, but
>>>>>
>>>reading Eric's reply I got
>>>
>>>>>the opposite impression. Furthermore being very surprised
>>>>>
>>>by Eric's reaction on
>>>
>>>>>a pure technical issue, I composed a few challenging
>>>>>
>>>words to attrack more
>>>
>>>>>people to participate in the  discussion... :-)
>>>>>
>>>>I see one of the issue here being ...
>>>>
>>>>    - Does GMPLS support serial compound links?
>>>>
>>>>Let us enumerate few more questions and move the discussion
>>>>
>>>to a technical
>>>
>>>>level again, we need participation especially from the
>>>>
>>>folks who are involved
>>>
>>>>in ASON architecture work.
>>>>
>>>>
>>>>>Being impressed by the few hundred people attending the
>>>>>
>>>last ccamp sessions in
>>>
>>>>>London, I am surprised by the low percentage of those
>>>>>
>>>people being actively
>>>
>>>>>contributing to the correspondence. It can't be the case
>>>>>
>>>that only a handful of
>>>
>>>>>people have an opinion on these matters... and I believe
>>>>>
>>>the discussions would
>>>
>>>>>stay technical if more people express their opinion...
>>>>>
>>>there would not be a
>>>
>>>>>yes/no game between just a few people.
>>>>>
>>>>>
>>>>I thought this is how most of the standards meetings work.
>>>>
>>>5 % work, 95 %
>>>
>>>>try to gather industry intelligence ( :-) ) either by
>>>>
>>>attending IETF or by following
>>>
>>>>the mailing list.
>>>>
>>>>
>>>>>With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available
>>>>>
>>>it will be possible to
>>>
>>>>>start an evaluation of GMPLS as a specific protocol for
>>>>>
>>>ASON. As indicated in a
>>>
>>>>>previous email from Steve Trowbridge, ITU-T will make
>>>>>
>>>those ASON documents
>>>
>>>>>available to IETF so we can jointly work this evaluation.
>>>>>
>>>>>
>>>>Most of these documents are available on the t1x1 site. But
>>>>
>>>what we need here is
>>>
>>>>the "delta" that is missing between ASON architecture and
>>>>
>>>the view of GMPLS
>>>
>>>>architecture. Can you help us with this? We may start with
>>>>
>>>a short list...
>>>
>>>>>The approval of the current ASON recommendations is just
>>>>>
>>>a first step within the
>>>
>>>>>larger ASON task. Work is started on other elements of
>>>>>
>>>ASON (G.rtg (routing),
>>>
>>>>>G.lm (link management) and pnni based specific protocol
>>>>>
>>>as an implementation of
>>>
>>>>>the protocol neutral specification in G.7713)),
>>>>>
>>>discussions are started
>>>
>>>>>identifying further ASON elements, and work to extend
>>>>>
>>>G.8080 is planned to start
>>>
>>>>>after this SG15 meeting.
>>>>>
>>>>>
>>>>Obviously GMPLS is a potential candidate to solve the ASON
>>>>
>>>issues. It may be
>>>
>>>>ahead of its time as far as ITU and ANSI are concerned. So
>>>>
>>>let us ammend or
>>>
>>>>modify it to the ITU view on the transport control plane.
>>>>
>>>>Regards,
>>>>
>>>>sudheer
>>>>
>>>>
>>>>>Up to so far... {time to shut down my computer and go to
>>>>>
>>>the concert hall in
>>>
>>>>>Geneva... time to relax after a week and a half of hectic
>>>>>
>>>work over here...}
>>>
>>>>>Regards,
>>>>>
>>>>>Maarten
>>>>>
>>>>>Sudheer Dharanikota wrote:
>>>>>
>>>>>>Hi Marteen:
>>>>>>
>>>>>>Can you briefly summarize the differences you see between
>>>>>>GMPLS architecture and ASON architecture? This has been
>>>>>>asked by many of the folks at IETF.
>>>>>>
>>>>>>Regards,
>>>>>>
>>>>>>sudheer
>>>>>>
>>>>>>PS: I thought these mails were about label format and suddenly
>>>>>>this is turning into an ITU versus IETF discussion :-(
>>>>>>
> 
>