The MPLS WG Archive

[Jim Boyle <jboyle@Level3.net>]

On Tue, 19 Dec 2000, Don Fedyk wrote:

> Shahram and Luca
> 
> draft-stdenis-ms-over-mpls-00.txt details how OAM cells can be handled.
> Please have a look. There is also an extensive requirements section that 
> outlines what requirements we wanted to satisfy. Among the requiremnets 
> was: no compromise to the ATM capabilities. This is one of the reasons 

Don - I don't see that requirement int your document, are you intending to
add verbiage in the draft to show how one performs the necessary service
interworking for this MPLS cloud to interwork with the ATM cloud and
maintain conformance to, for instance, TM4.0?  And what is the proper
forum for such activity?

Jim

> it was over MPLS not just any transport.
> 
> Don
> http://www.ietf.org/internet-drafts/draft-stdenis-ms-over-mpls-00.txt
> 
> 
> > -----Original Message-----
> > From: Luca Martini [mailto:luca@level3.net]
> > Sent: Monday, December 18, 2000 7:24 PM
> > To: Shahram Davari
> > Cc: 'mpls@uu.net'
> > Subject: Re: drat-martini-l2circuit-enacap/trans-mpls
> > 
> > 
> > Shahram Davari wrote:
> > > 
> > > Hi,
> > > 
> > > I have some questions from the authors of these drafts.
> > > 
> > > 1) Section 5.2.1 of the Encap draft says:
> > > 
> > >  "A router that does not support transport of OAM cells 
> > MUST discard incoming MPLS frames on an ATM VC LSP that 
> > contain an ATM cell with the high-order bit of the PTI set to 1".
> > > 
> > > Since in the MPLS network, only the ingress LSR and egress 
> > LSR are ware of the existence of OAM cells, and since the 
> > egress LSR does not need to do any thing special for the 
> > received OAM cells from the user data cells,  I assume by 
> > "router" the authors mean ingress LSR. If so then why does it 
> > says "incoming MPLS frames"?
> > > 
> > yes, this slipped in.  It's wrong . I'll fix it.
> > 
> > > 2) Section 4.2.1 of the Trans draft says:
> > > 
> > > "A router that does not support transport of ATM cells MUST 
> > discard incoming MPLS frames on an ATM VC LSP that contain a 
> > control word with the T bit set.
> > > 
> > > This section looks very similar to section 5.2.1 of the 
> > Encap draft, while this specific sentence is completely 
> > different. Is there a mistake or it is correct? If it is 
> > correct then why is this subject in the OAM section? Sine the 
> > sentence is talking about received MPLS frames, it seems that 
> > it is talking about an egress LSR, but why should an egress 
> > LSR that can't support ATM distribute the VC label in the first place?
> > > 
> > it a mistake in the text of the draft.
> > 
> > 
> > > 3) Section 5.2.1 of Encap draft and section 4.2.1 of Trans 
> > draft say:
> > > "The LSR MAY optionally be configured to periodically 
> > generate F5 end-to-end loop back OAM cells on a VC. ... If 
> > the LSR fails to receive a response to an F5 end-to-end loop 
> > back OAM cell for a pre-defined period of time it MUST 
> > withdraw the label mapping for the VC."
> > > Is this talking about ingress LSR or egress LSR?
> > Both.
> > As both ends can be configured to do end to end loopback oam cells. In
> > this model you must consider the ATM network as to separate 
> > ATM network
> > with a "strange" link in the middle ( the MPSL network ). So 
> > end to end
> > means LSR to ATM device.
> > 
> > 
> > 
> > > 4) Section 5.2.1 of Encap draft and section 4.2.1 of Trans 
> > draft say:
> > > "If an ingress LSR receives an AIS F5 OAM cell, fails to 
> > receive a pre-defined number of the End-to-End loop OAM 
> > cells, or a physical interface goes down, it MUST withdraw 
> > the label mappings for all VCs associated with the failure. 
> > When a VC label mapping is withdrawn, the egress LSR SHOULD 
> > generate AIS F5 OAM cells on the VC associated with the 
> > withdrawn label mapping. "
> > > I always thought that LDP label withdrawal is initiated 
> > from downstream (egress). Could you please explain how the 
> > ingress LSR can withdraw a label that doesn't belong to it?
> > > 
> > In order to make the LSP bi-directional , and LSR must have a 
> > label for
> > VC/GR id in both directions. If one direction is withdrawn the circuit
> > goes down. So the LSr withdraw a label that he has advertised ,
> > resulting in the upstream router generating AIS F5 OAM cells.
> > 
> > > 5) Section 5.2.1 of Encap draft says:
> > > 
> > > "A router that supports transport of OAM cells MUST follow 
> > the procedures outlined in [7] section 8 for mode 0 only"
> > > I think it needs to be mentioned that performance OAM cells 
> > can't be used with the AAL5 based transmission (due to 
> > possible displacement).
> > Yes, this has been changed in the future version of the draft.
> > 
> > Thanks.
> > Luca
> > 
> > 
> > > Regards,
> > > Shahram Davari
> > > Systems Engineer
> > > Product Research Group
> > > PMC-Sierra, Inc. (Ottawa)
> > > Phone: (613) 271-4018
> > > Fax:    (613) 271-7007
> > 
> > -- 
> > Just say no to summer. Ski all year !
> > Luca Martini Senior Network Architect, Level 3 Communications -
> > Broomfield, CO
> > luca@level3.net | VE2WKR/W0 | Phone 720-888-1225 | pager
> > page-luca@level3.net
> > 
>