Re: Moving right along ...

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

Hi Mike,

I agree with most of what you said. I think the forwarding adjacency is
more similar to the serial composed link connections (or serial
compound links) than to support from a trail. There is no requirement 
for forwarding adjacencies to relate to trails (at least I don't think so).

And yes, I fully agree that the inter-layer piece is the interesting 
piece. I believe Maarten has presented this in several places as the 
network engineering function (what you called the "local matter") as 
subject to policy control (very operator business model dependent).

As for the hierarchy and the layer model, I think the hierarchical model 
of MPLS is more atuned to the sub-network partition (and sub-network 
recursion) which is within a layer. I'm not sure that the hierarchy was 
defined for layer network (although I don't see why it can't apply either).

Now in terms of the layer model itself, I think (as I said many times) 
that the problem is mainly in how people interpret the text in these 
documents. That is why (my little rambling again) I think we need to add 
text to clarify some of these concepts...people don't seem to want to 
add clarifying text though...sigh...

Zhi


mike.sexton@alcatel.co.uk wrote:

 >
 > 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 :-(
 >>>>
 >>>> Part 1.1
 >>>>
 >>>> Content-Type:
 >>>>
 >>>> text/plain
 >>>>
 >>>>
 >>>> 
------------------------------------------------------------------------
 >>>>

 >>>> mvissers.vcf
 >>>>
 >>>> Content-Type:
 >>>>
 >>>> application/octet-stream Content-Encoding:
 >>>>
 >>>> base64
 >>>>
 >>>>