Subject: Re: [mpls-tp] MIPs in MPLS-TP

From: 류정동 <[email-masked]>
Date: Wed, 5 Aug 2009 20:45:51 +0900

Are there any thoughts on the MIP - MEP relationship, such as the restiction that a MIP can exist only if there is a MEP defined in its server layer, or something like that.

==============================================
Jeong-dong Ryoo, Ph.D.
Principal Member of Research Staff
Network Research Department
Electronics and Telecommunications Research Institute (ETRI)
Phone: +82-42-860-5384, Fax: +82-42-860-6342
Email: [email-masked]
==============================================

-----원본 메시지-----
From: "Stewart Bryant" <[email-masked]>
From Date: 2009-08-05 오후 8:41:05
To: "Annamaria Fulignoli" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [mpls-tp] MIPs in MPLS-TP

I agree that we need to change the text to indicate
that it could be a MIP or a MEP - that was an
oversight yesterday.

I am OK with making the MIP optional, though
I am surprised that anyone would want to do
that.

What is important is that the placement of the
MIP (or MEP) be an implementation decision
since the placement has impact on how the
equipment is designed, which in turn impacts
scaling, cost etc.

- Stewart

Annamaria Fulignoli wrote:
> Hi Kam,
> I agree with you, however I think it could be possible to have
> intermediate nodes not supporting MPLS-TP OAM ; these nodes are
> transparent to OAM packet information and forward them as regular data
> packets.
> Besides, I think that an operator must be able to configure or not a
> MIP ( or more than one as proposed ) on a node for each ME. That's
> even for scalability reasons.
> Best Regards,
> Annamaria
>
> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Lam, Hing-Kam (Kam)
> *Sent:* mercoled? 5 agosto 2009 4.21
> *To:* [email-masked]; BUSI,ITALO (ITALO);
> [email-masked]; [email-masked]
> *Subject:* Re: [mpls-tp] MIPs in MPLS-TP
>
> Ben
>
> If a node doesn’t contain a MIP for a MEG, then this node will not be
> able to be involved in any Loopback or route trace for the MEG.
>
> Regards,
>
> Kam
>
> > -----Original Message-----
>
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
>
> > Of [email-masked]
>
> > Sent: Tuesday, August 04, 2009 6:54 PM
>
> > To: BUSI, ITALO (ITALO); [email-masked]; [email-masked]
>
> > Subject: Re: [mpls-tp] MIPs in MPLS-TP
>
> >
>
> > Why must a node contain a MIP? Is it not permissable to have MPLS-TP
> nodes
>
> > that do not support MIPs? BEn
>
> >
>
> > ________________________________________
>
> > From: [email-masked] [[email-masked]] On Behalf Of
>
> > BUSI ITALO [[email-masked]]
>
> > Sent: Tuesday, August 04, 2009 10:54 PM
>
> > To: [email-masked]; [email-masked]
>
> > Subject: [mpls-tp] MIPs in MPLS-TP
>
> >
>
> > There is a pending open issue regarding MIP support in MPLS-TP.
>
> >
>
> > After a discussion between myself, Stewart, Malcolm, Kam and Scott
>
> > Mansfield, we think that the following text proposal for MPLS-TP
>
> > Framework and MPLS-TP OAM Framework (to be used also as a guide for
>
> > writing G.8110.1) could solve the issue:
>
> > "
>
> > Every node MUST have at least one MIP. A node MAY support more than one
>
> > MIP.
>
> >
>
> > The possible locations for a MIP within a node are ingress port, egress
>
> > port or the node itself. The choice of which MIP location(s) to support
>
> > is an implementation decision. MEPs MUST be capable of addressing any
>
> > MIP within their MEG irrespectively of the location.
>
> >
>
> > A node MUST provide the identifier for each of the MIPs it supports
>
> > together with the location of the MIP.
>
> > "
>
> >
>
> > We would appreciate comments from the whole community regarding this
>
> > proposal.
>
> >
>
> > Thanks in advance
>
> >
>
> > Italo
>
> > _______________________________________________
>
> > mpls-tp mailing list
>
> > [email-masked]
>
> > https://www.ietf.org/mailman/listinfo/mpls-tp
>
> > _______________________________________________
>
> > mpls-tp mailing list
>
> > [email-masked]
>
> > https://www.ietf.org/mailman/listinfo/mpls-tp
>

_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 05 Aug 2009 15:27:20 +0200

A MIP or Half MIP exists within the scope of a transport entity
(connection) in a layer network; e.g. a PW connection or a LSP connection. 
An interface port card may support a number of MIP or half MIP resources.
Each such MIP/half MIP resource can be assigned to a transport entity,
which is set up over the interface card.
 
A MIP or Half MIP within an interface port assigned to a specific transport
entity will respond to the on-demand OAM from the nearest upstream MEP
source function in that transport entity. This MEP function can perform a
network connection monitoring role, a segment monitoring role, or a link
connection monitoring role. E.g. a MIP/halfMIP within a PW segment will
respond to some of the PW segment OAM inserted by the adjacent PW Segment
MEP source function. The same MIP/half MIP would respond to PW netwrok
connection OAM inserted by the adjacent PW Network Connection MEP source
function, if there is no PW Segment active.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of ???
Sent: woensdag 5 augustus 2009 13:46
To: Stewart Bryant; Annamaria Fulignoli
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] MIPs in MPLS-TP

Are there any thoughts on the MIP - MEP relationship, such as the
restiction that a MIP can exist only if there is a MEP defined in its
server layer, or something like that.

Email:  <mailto:[email-masked]> [email-masked]

-----원본 메시지-----
To: "Annamaria Fulignoli" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [mpls-tp] MIPs in MPLS-TP

- Stewart

  <http://umail.etri.re.kr/External_ReadCheck.aspx?email=mpls-
[email-masked]&name=mpls-
tp%40ietf.org&fromemail=[email-masked]&messageid=%3C2cc4a1ad-e098-476c-
[email-masked]%3E>