The MPLS WG Archive

[George Swallow <swallow@cisco.com>]

Scott -

It has come to my attention that the ITU is considering/planning a
new recommendation, G.mna, "MPLS layer network architecture".

As our liaison to the ITU would you please inform them that they are
out of order here?

Thank you,

George



>From: "Malcolm Betts"<betts01@nortelnetworks.com>
>To: "'Maarten Vissers'" <mvissers@lucent.com>, neil.2.harrison@bt.com
>Cc: tsg13q3@itu.int, andy.bd.reid@bt.com, q12/15 <tsg15q12@itu.int>
>Subject: RE: G.mna
>Date: Wed, 22 May 2002 08:11:26 -0400
>X-Mailer: Internet Mail Service (5.5.2653.19)
>Sender: owner-tsg15q12@itu.int
>Reply-To: "Malcolm Betts"<betts01@nortelnetworks.com>
>
>I would like to clarify the status of this work in the context of 
>Q.12/15.  The discussion that Maarten refers to was held between a small 
>group of experts who attend Q.12/15.  The results were not formally 
>discussed within Q.12 and are not captured in the meeting report.
>
>I support this effort to consolidate the results of the earlier activities 
>into a single coherent document that could be provided as a contribution 
>to the next (January 2003) meeting of SG 15 where the group can formally 
>decide to initiate (or not) work on a new draft Recommendation on MPLS 
>layer network architecture.
>
>Malcolm Betts
>
>Rapporteur Q.12/15
>Nortel Networks
>Phone: +1 613 763 7860
>FAX:   +1 613 763 6608
>email: betts01@nortelnetworks.com
>
>-----Original Message-----
>From: Maarten Vissers 
>[<mailto:mvissers@lucent.com>mailto:mvissers@lucent.com]
>Sent: Wednesday, 22 May, 2002 04:36
>To: neil.2.harrison@bt.com
>Cc: tsg13q3@itu.int; andy.bd.reid@bt.com; q12/15
>Subject: G.mna - [was: Re: AAP - Additional Review Comments from
>WorldCom on Y.1710 (C o rr . 1) & Y.1711]
>
>Neil,
>
>A few months ago MPLS network architecture has been discussed in a smaller 
>team
>of G.805 experts. During the SG15 meeting earlier this month we agreed to
>contribute the results so far via correspondence (Q.12/15) as a starter for a
>new recommendation (e.g. G.mna "MPLS layer network architecture").
>
>The intent is to do as much via correspondence as possible, so we have a 
>quite
>stable draft going in to the next SG15 meeting (in Jan 2003).
>
>To initiate this work in Q.12/15 I have created a new directory "gmna" and a
>subdirectory "cd" for the correspondence documents on G.mna.
><http://ties.itu.int/u/tsg15/sg15/wp3/q12/gmna/cd/>http://ties.itu.int/u/tsg15/sg15/wp3/q12/gmna/cd/ 
>
>
>I have also uploaded one of the documents that I developed during the mpls
>network architecture discussion mentioned above. You find it at:
><http://ties.itu.int/u/tsg15/sg15/wp3/q12/gmna/cd/mpls-model3.ppt>http://ties.itu.int/u/tsg15/sg15/wp3/q12/gmna/cd/mpls-model3.ppt 
>
>There was other material available as well, so perhaps the authors can upload
>that onto this new directory as well.
>
>Furthermore about 50 emails were exchanged. If we can summarize these 
>emails we
>could have a flying start. Main question in those emails: is there a 
>single MPLS
>layer network with a set of sublayers (for Tandem Connection Monitoring 
>and for
>Multiplexing), or are there multiple MPLS layer networks. The root cause 
>of the
>question is due to the Multiplexing capabilities that the sublayer would 
>have;
>so far we hadn't come across a sublayer with multiplexing capabilities. 
>Current
>thinking is that we have to model it in both ways; i.e. as a sublayer and 
>as an
>additional layer network.
>
>After we developed the OTN with already 8 levels of "optical channel" 
>connection
>monitoring (1x ODUk path, 6x ODUk tandem connection, 1x OTUk section), MPLS
>offers the extreme (theoretical an infinite number of connection monitoring
>levels). Despite that 8 levels of connection monitoring in the OTN is more 
>than
>we have ever had before, we could not guarantee that it is sufficient in 
>every
>network scenario (we believe it is). With the infinite number of connection
>monitoring levels in MPLS, any network scenario (carrier grade) can be 
>supported
>as soon as MPLS OAM is defined.
>
>Regards,
>
>Maarten
>
>neil.2.harrison@bt.com wrote:
> >
> > Thanks....some observations.  regards Neil
> >
> > Pathak, Yatendra wrote 21 May 2002 17:15
> > > >
> > > > Yatendra,
> > > > thanks for your response.  Having raised these comments I
> > > am sure that we
> > > > will see detailed Recommendation text proposals from
> > > Worldcom at the next
> > > > meeting.
> > > > If not, then it can only be assumed that there is no real technical
> > > > argument.
> > >
> > >
> > > Yes, as we stated earlier on this list, WorldCom plans to submit
> > > contribution(s).
> > NH=> Can I just check when...is this to the Chitose mtg?
> > >
> > > >
> > > > I would not expect to see any mention of FR in G.805 as it
> > > is technology
> > > > independent (see G.803 for SDH, G.872 for OTN, I.326 for ATM). If
> > > > you think
> > > > it is necessary to have one for FR please write one - this is a
> > > > contribution
> > > > driven process. The fact that there is not one for a
> > > technology does not
> > > > mean that the technique is not valid for that technology.
> > >
> > >
> > > We disagree. We were trying to point out a technical issues
> > > in that FR does
> > > not use a G.805 style OAM model
> > NH=> G.805 is not specifically about OAM.....G.805 merely formalises the
> > vertical (client/server) and horizonal (within single layer) 
> relationships.
> > However, such a view is an essential pre-cursor for the development of
> > appropriate fault-management behaviour.  Whether FR has appropriate OAM or
> > not is not the issue here, but that does not mean FR does not behave in
> > accordance with G.805...and it fact it does.
> >
> > , and that support for RFC
> > > 3034 invalidates
> > > the architectural assumption of the G.805 client-server
> > > layered OAM model.
> > NH=> Would you therefore argue that the SDH and OTN layer networks defined
> > under GMPLS invalidate the G.805 model too?  Clearly this is not true.  I
> > believe work will be started to provide a more rigorous functional 
> model of
> > MPLS in ITU based on G.805 very soon (Maarten/Alan....do you know 
> status of
> > this?), so I'd urge Worldcom to get involved if you have anything to 
> say on
> > this before its completed.
> > BTW - In fact it is due to a lack of being able to correctly map failure
> > behaviour between layers (ie when some layers are insufficiently 
> specified)
> > that will lead to some serious operational problems if we are not careful.
> > For example, Jeremey Brayley had a requirement in his ATMoverMPLS draft 
> that
> > was (paraphrased) 'on near-end ATM partition failure generate far-end
> > partition SDH AIS'.  This is completely unacceptable behaviour, ie asking
> > the properly defined SDH OAM mechanism to proxy for missing OAM
> > functionality elsewhere.  Jeremy has kindly now removed this from his 
> draft.
> >
> > > We will note this issue in our contribution as a requirement
> > > that support
> > > for MPLS using FR encapsulation needs to be supported via the
> > > OAM protocol.
> > NH=> But that is wholly in the province of the data-plane of the FR layer
> > network.  If FR is badly/inappropriately specified then you should look
> > there to correct it....not fudge it elsewhere, esp in other layer 
> networks.
> > >
> > >
> > > > One has
> > > > also been
> > > > recently started for ethernet (G.etna).
> > > >
> > > > I have to agree with Dave Allan's points in his email. Clearly
> > > > proposals to
> > > > run X over MPLS are an indication that the model should be
> > > independednt of
> > > > the client (notwithstanding the requirements of one
> > > particular client).
> > >
> > >
> > > See our comments to Shahram. The issue we are raising is not
> > > only the client
> > > (encapsulation, "user plane," forwarding .... we have too
> > > many names for the
> > > same thing), but instead the interaction with the control plane.
> > NH=> I agree that failures of the data-plane need communicating to the
> > control-plane (and just as importantly also to the management plane).  The
> > route calculation process needs to know of topological validity/resource,
> > and if any signalling protocol is involved this needs to know if it 
> needs to
> > clear connections (SVC-like case) or invoke prot-sw/restoration 
> (S-PVC-like
> > case).  However, wrt to initial defect detection in the data-plane one 
> does
> > not rely on control-plane protocols alone....these may even be the 
> cause of
> > the defect in the data-plane in the 1st place if they are
> > misbehaving/faulty.  So if this is what you are suggesting here then 
> this is
> > where I think there is a fundamental disagreement.  In a cnls mode relying
> > on the control-plane protocol is all you can do....and even here its
> > strictly limited to the routing protocol, as there is no signalling
> > protocol.  These arguments are no longer correct/valid for co pkt-sw
> > networks (though perhaps some will bend cnls/IGP model to now allow a
> > signalling protocol to proxy for missing data-plane fault-handling?).  But
> > I'd assume you would concede this is patently not valid for co cct-sw
> > networks like SDH and OTNs under GMPLS?
> > <snipped to end NH>

======================================================================
George Swallow          Cisco Systems                   (978) 497-8143
                        250 Apollo Drive
                        Chelmsford, Ma 01824