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

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Tue, 11 Aug 2009 22:12:36 -0500

Jeong-dong and Qiaogang,

The first occurrence is a typo and the rest are copy & paste errors.
You are right, it should be "..., one on the ingress port and the other on the egress port."

Regards,
Kam

________________________________
From: 류정동 [mailto:[email-masked]]
Sent: Tuesday, August 11, 2009 10:52 PM
To: Lam, Hing-Kam (Kam); [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls-tp] MIPs in MPLS-TP

Question:

I keep seeing the following from the many previous emails:
 "..., one on the egress port and the other on the egress port."
Shouldn't we change it as:
 "..., one on the ingress port and the other on the egress port."
?

Regards,

Jeong-dong

==============================================
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]<mailto:[email-masked]>
==============================================

-----원본 메시지-----
From: "Lam, Hing-Kam (Kam)" <[email-masked]>
From Date: 2009-08-12 오전 11:38:21
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc:
Subject: RE: [mpls-tp] MIPs in MPLS-TP

Ben,

The first sentence in the 3rd paragraph of your rewording reads to me as "If support for MPLS-TP OAM on intermediate nodes of a transport path is required, then all the transit nodes MUST support at least one MIP."

Is that your intent? Or do you allow a mix of transit nodes, i.e. some transit nodes support while the others not. If a mix is allowed, I suggest the following wording:

"
The support of OAM on an MPLS-TP transport path is optional.

If support for MPLS-TP OAM on a transport path is required, then both the ingress and egress nodes MUST support a MEP.

If support for MPLS-TP OAM on an intermediate node of a transport path is required, then that node MUST support at least one MIP. A transit node SHOULD support two MIPs, one on the egress port and the other on the egress port.
"

Regards,
Kam

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, August 11, 2009 9:44 PM
> To: [email-masked]; Lam, Hing-Kam (Kam); [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] MIPs in MPLS-TP
>
> Colleagues,
>
> The requirements are to guide the protocol designers. The protocol MUST
> support MIP functionality. Whether a given vendor/box/operator implements
> MIP functionality on a particular LSP is down to the vendor/operator. The
> protocol MUST also be capable of operating in the absence of MIPs.
>
> With respect to Malcolm's original suggestion I am OK with it except for
> the
> following:
>
> "In order to support MPLS-TP OAM on an LSP that transits a node, that
> node MUST support at least one MIP.  A transit node SHOULD support two
> MIPs one on the egress port the other on the egress port."
>
> If I understand the intent behind the sentence then it is saying "if you
> want to be able to perform MPLS-TP OAM at a transit node then the transit
> node MUST support at least one MIP" I agree with that intent.
>
> However the sentence reads to me as "if you want to support MPLS-TP OAM on
> an LSP all transit nodes MUST contain at least one MIP" I don't agree with
> that.
>
> Assuming I have the intent of the sentence correct, how about the
> following
> rewording of Malcolm's original suggestion:
>
> "
> The support of OAM on an MPLS-TP transport path is optional.
>
> If support for MPLS-TP OAM on a transport path is required, then both the
> ingress and egress nodes MUST support a MEP.
>
> If support for MPLS-TP OAM on the intermediate nodes of a transport path
> is
> required, then those nodes MUST support at least one MIP. A transit node
> SHOULD support two MIPs one on the egress port and the other on the egress
> port.
> "
>
> Ben
>
>
> On 11/08/2009 19:59, "Shahram Davari" <[email-masked]> wrote:
>
> > Hi Kam,
> >
> > No I was asking about Mandatory vs Optional. I think IETF's job is to
> provide
> > the toolkit. It is up to the service providers to decide how and where
> they
> > want to you them.
> >
> > Regards,
> > Shahram
> >
> > -----Original Message-----
> > From: Lam, Hing-Kam (Kam) [mailto:[email-masked]]
> > Sent: Tuesday, August 11, 2009 11:53 AM
> > To: Lam, Hing-Kam (Kam); Shahram Davari; [email-masked]';
> > [email-masked]'; [email-masked]'; 'ahmpls-
> [email-masked]'
> > Subject: RE: [mpls-tp] MIPs in MPLS-TP
> >
> > Hi Shahram,
> >
> > Further thought about your question, I wonder if you are questioning MIP
> vs
> > OAM rather than mandatory vs optional. If you are questioning why MIP
> for OAM,
> > then please note that MIP is not a/the OAM solution. MIP is a MPLS-TP
> > functional component in the OAM architecture that enables a transit node
> (or a
> > component of the transit node) to respond to on-demand MPLS-TP OAM
> signals. It
> > is not dictating (forcing) any particular OAM solution.
> >
> > Regards,
> > Kam
> >
> >> -----Original Message-----
> >> From: Lam, Hing-Kam (Kam)
> >> Sent: Tuesday, August 11, 2009 1:51 PM
> >> To: Shahram Davari; [email-masked]';
> [email-masked]';
> >> [email-masked]'; [email-masked]'
> >> Subject: RE: [mpls-tp] MIPs in MPLS-TP
> >>
> >> Hi Shahram,
> >>
> >> Surely I agree that the scenario you just gave is possible.
> >> But what I said in my previous email is what I interpret from Malcolm's
> >> wording in the proposed requirements.
> >>
> >> Regards,
> >> Kam
> >>
> >>
> >>> -----Original Message-----
> >>> From: Shahram Davari [mailto:[email-masked]]
> >>> Sent: Tuesday, August 11, 2009 1:02 PM
> >>> To: Lam, Hing-Kam (Kam); [email-masked]';
> >>> [email-masked]'; [email-masked]'; 'ahmpls-
> >> [email-masked]'
> >>> Subject: RE: [mpls-tp] MIPs in MPLS-TP
> >>>
> >>> Hi Kam,
> >>>
> >>> Are you saying OAM can't be supported for an LSP if any of the LSRs
> >>> doesn't have a MIP? Why? I can easily see
> >>> Cases that a few LSRs don't have any MIP. Specially that a MIP is used
> >>> only for diagnostics, and an operator may have other tools to do
> >>> diagnostics.
> >>> I think this is an operation decision that shouldn't be forced in
> >>> The standard.
> >>>
> >>> Regards,
> >>> Shahram
> >>>
> >>> -----Original Message-----
> >>> From: Lam, Hing-Kam (Kam) [mailto:[email-masked]]
> >>> Sent: Tuesday, August 11, 2009 6:51 AM
> >>> To: Shahram Davari; [email-masked]';
> [email-masked]';
> >>> [email-masked]'; [email-masked]'
> >>> Subject: RE: [mpls-tp] MIPs in MPLS-TP
> >>>
> >>> It is mandatory under the condition that OAM is supported for that LSP.
> >>>
> >>> As said at the beginning of Malcolm's email,
> >>>>> The support of OAM on a MPLS-TP LSP is optional.
> >>>
> >>> Under the condition that OAM is supported for a LSP, it is mandatory
> to
> >>> have a MIP at the transit node. I.e. as Malcolm said:
> >>>>> In order to support MPLS-TP OAM on an LSP that transits a node, that
> >>>>> node MUST support at least one MIP.
> >>>
> >>> May be we can say this is conditional. :-)
> >>>
> >>> Regards,
> >>> Kam
> >>>
> >>>> -----Original Message-----
> >>>> From: [email-masked] [mailto:[email-masked]] On
> >>> Behalf
> >>>> Of Shahram Davari
> >>>> Sent: Tuesday, August 11, 2009 8:43 AM
> >>>> To: [email-masked]'; [email-masked]'; 'mpls-
> >>>> [email-masked]'; [email-masked]'
> >>>> Subject: Re: [mpls-tp] MIPs in MPLS-TP
> >>>>
> >>>> Why is it mandatory to have a MIP at each node?
> >>>>
> >>>> ----- Original Message -----
> >>>> From: [email-masked] <[email-masked]>
> >>>> To: [email-masked] <[email-masked]>; mpls-
> >>> [email-masked]
> >>>> <[email-masked]>; [email-masked] <[email-masked]>
> >>>> Sent: Tue Aug 11 00:34:29 2009
> >>>> Subject: Re: [mpls-tp] MIPs in MPLS-TP
> >>>>
> >>>> Thanks Malcolm for your views here.  I have a few further
> observations
> >>>> that we might like to consider, especially fellow operators...please
> >> see
> >>>> in-line:
> >>>>
> >>>> Malcolm Betts wrote 08 August 2009 13:44
> >>>>>
> >>>>> All,
> >>>>>
> >>>>> I think that we should state in the OAM requirements:
> >>>>>
> >>>>> The support of OAM on a MPLS-TP LSP is optional.
> >>>>
> >>>> NH=> Agreed.  But perhaps we should add a health-warning to
> >> this...maybe
> >>>> with 2 parts:
> >>>>
> >>>> 1 In co-ps mode technologies based on label-swapping (ie
> >>>> forwarding labels that are only link unique and also where the
> traffic
> >>>> units do not contain a network unique source label) then unless CV-
> >> like
> >>>> OAM is run on all LSPs one cannot detect cases of traffic leaking
> (via
> >>>> an unintended replication defect) from one LSP into another LSP.  A
> >>>> client of such networks could consider the non-detection of such
> >> server
> >>>> layer leaking traffic defects as compromising client information
> >>>> security.
> >>>>
> >>>> 2 It should be recommended that the same type of CV-like OAM is
> >>>> run on all LSPs in the same MPLS-TP layer network.  This is simply to
> >>>> avoid a given LSP sink trail termination point having to be able to
> >>>> understand all the different types of CV-like OAM that might exist in
> >>>> the same MPLS-TP layer network....a condition that may arise due to
> >> the
> >>>> type of leaking defect noted above in 1.
> >>>>
> >>>>>
> >>>>> In order to support MPLS-TP OAM on an LSP that transits a node, that
> >>>>> node MUST support at least one MIP.  A transit node SHOULD support
> >> two
> >>>>> MIPs one on the egress port the other on the egress port.
> >>>>
> >>>> NH=> IMO it would be useful if vendors could provide operators the
> >>>> option of being able to passively tap-off end-end CV/PM flows at
> >>>> intermediate nodes in an on-demand basis for tracing/diagnostics.
> >>>>>
> >>>>> In order to support MPLS-TP OAM on an LSP that is terminated or
> >>>>> originated that node MUST support a MEP.
> >>>>
> >>>> NH=> Agreed.
> >>>>>
> >>>>> This should address the concerns with respect to scalability i.e.
> >> the
> >>>>> MEPs and MIPs need not be activated.
> >>>>
> >>>> NH=> True.  But I would have another concern about having nested
> >>>> MEPs/MIPs that belonged to a different operating party in equipment
> >> that
> >>>> I owned.  Of course, this is related to a larger and more general
> >>>> observation that peer-partition interworking in a non top-of-stack
> >> layer
> >>>> network (as indeed MPLS-TP is) is not technically necessary.
> >>>>
> >>>> regards, Neil
> >>>>
> >>>>>
> >>>>> Much of the detail being discussed below belongs in the
> >>>>> framework draft
> >>>>> and/or the G.8121 (the ITU equipment Recommendation).
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Malcolm
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Maarten Vissers [mailto:[email-masked]]
> >>>>>> Sent: Thursday, August 06, 2009 12:38 PM
> >>>>>> To: [email-masked];
> >>>>> [email-masked]; mpls-
> >>>>>> [email-masked]; [email-masked]
> >>>>>> Subject: RE: MIPs in MPLS-TP
> >>>>>>
> >>>>>> Ben,
> >>>>>>
> >>>>>> See inline..
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: [email-masked] [mailto:benjamin.niven-
> >>>>>> [email-masked]]
> >>>>>> Sent: donderdag 6 augustus 2009 16:10
> >>>>>> To: [email-masked]; [email-masked];
> >> mpls-
> >>>>>> [email-masked]; [email-masked]
> >>>>>> Subject: Re: MIPs in MPLS-TP
> >>>>>>
> >>>>>> Maarten,
> >>>>>>
> >>>>>> I see there has been a flurry of mails on this topic since
> >>>>> yours but I
> >>>>>> wanted to clarify where I was coming from with my question.
> >>>>> I am just
> >>>>>> trying to understand the impacts of the statement in two
> >>>>> broad areas.
> >>>>>>
> >>>>>> - Relationship between MEPs and MIPs. I.e. Is a MEP a superset of
> >> a
> >>>>>> MIP and therefore stating all nodes will have a MIP really means
> >> all
> >>>>>> nodes will have a MIP or a MEP
> >>>>>>
> >>>>>> [mv] A MEP is a compound function and a MIP is a compound function.
> >>>>>> - A MEP contains a pro-active moniotirng termination
> >>>>> function (XXX_TT)
> >>>>>> and an on-demand endpoint monitoring termination function
> >>>>> (XXXDe_TT).
> >>>>>> - A MIP contains two back to back on-demand intermediate point
> >>>>>> termination functions (2x XXXDi_TT).
> >>>>>> - A Half MIP contains one on-demand intermediate point termination
> >>>>>> function (XXXDi_TT).
> >>>>>> A Half MIP is used when a port supports MIP functionality on its
> >>>>>> ingress only.
> >>>>>> A MIP is used when a port supports MIP functionality on its
> >>>>> "ingress"
> >>>>>> and "egress".
> >>>>>>
> >>>>>> [mv] See for details the attached MEP and MIP compound function
> >>>>>> specifications from G.8010 and G.8110.1.
> >>>>>>
> >>>>>> [mv] As you will notice, the MEP and MIP are different
> >>>>> functions. The
> >>>>>> support for MIP functions is independent of the support for MEP
> >>>>>> functions.
> >>>>>>
> >>>>>>
> >>>>>> - What is the impact to protocol design if we can (a)
> >>>>> assume all nodes
> >>>>>> have MIP functionality (even if it isn't enabled on a
> >>>>> transport path)
> >>>>>> as suggested by the proposed text or (b) if we can't assume
> >>>>> all nodes
> >>>>>> have a MIP functionality. Impact may be that there is no
> >>>>> difference to
> >>>>>> protocol design for the two cases.
> >>>>>>
> >>>>>> [mv] The protocol is to be designed under the assumption that
> >> there
> >>>>>> may be MIPs in a connection. If such MIPs are not active on
> >>>>> a port, or
> >>>>>> if such MIPs are not present on a port does not impact the OAM
> >>>>>> protocol itself. It only impacts the ability to perform fault
> >>>>>> localization in the network....
> >>>>>> - No MIPs in the port cards, or none of such MIPs on port cards
> >>>>>> activated will result in no means to locate the fault by
> >>>>> means of the
> >>>>>> loopback tool.
> >>>>>> - When MIPs are present on ports and are activated within a
> >>>>>> connection, then the LOC alarm will normally trigger a fault
> >>>>>> localization process that uses the loopback OAM tool to identify
> >> the
> >>>>>> node or link with the fault.
> >>>>>>
> >>>>>> [mv] Fault localization without MIPs will require that port
> >>>>> cards are
> >>>>>> equipped with non-intrusive monitoring MEP_Sink functions; NMS can
> >>>>>> then temporarily activate on each port card within the
> >>>>> connection such
> >>>>>> MEP_Sink function and check which MEP_Sink reports LOC and
> >>>>> which don't
> >>>>>> detect/report LOC. The fault is located between the  last
> >>>>> MEP_Sink not
> >>>>>> reporting LOC and the first reporting LOC. I hope that it is clear
> >>>>>> that the use of non-intrusive monitoring MEP_Sink functions as
> >> fault
> >>>>>> location tool is more complex then use of loopback OAM tool.
> >>>>>>
> >>>>>>
> >>>>>> To respond to your point - lack of MIP will restrict the
> >>>>> OAM functions
> >>>>>> that can be supported. In some cases that may not be an
> >>>>> issue. However
> >>>>>> the primary case I was thinking about is nodes that only ever act
> >> as
> >>>>>> transport path end points and therefore may contain a MEP but
> >> might
> >>>>>> not contain a MIP.
> >>>>>>
> >>>>>> [mv] If you look at my PE NNI port models (that were attached to
> >> my
> >>>>>> email yesterday, see slides 2 and 3), you will notice that the
> >>>>>> transport path/tunnel layer endpoints (i.e. the LSP or EVP
> >>>>> endpoints)
> >>>>>> are supported by just a LSP MEP or EVP MEP (i.e. a Down
> >>>>> MEP). Those PE
> >>>>>> NNI ports do not contain a LSP MIP or EVP MIP.
> >>>>>> When you look at the P NNI port model (slide 4), then you
> >>>>> will notice
> >>>>>> that there are only LSP MIP or EVP MIP functions.
> >>>>>>
> >>>>>> [mv] If you look at the service/channel layer transport
> >>>>>> entities/connections, then you will notice in the UNI-N
> >>>>> port card (see
> >>>>>> slide
> >>>>>> 1) that there are only PW MEP and EVC MEP functions (no MIP
> >>>>>> functions). And on the PE NNI port cards, you will notice that
> >> there
> >>>>>> are PW MIP and EVC MIP functions plus PW MEP and EVC MEP functions.
> >>>>>>
> >>>>>> [mv] My recommendation is that new PE UNI-N, PE NNI and P NNI port
> >>>>>> cards should support the set of MEP and MIP functions presented in
> >>>>>> those slides.
> >>>>>>
> >>>>>> [mv] Existing port card designs may be upgraded with some of this
> >>>>>> recommended MEP and/or MIP functionality, but typically can not
> >>>>>> support it all. As a subset may be good enough to start
> >>>>> with, existing
> >>>>>> designs will present a subset of the recommended MEP/MIP
> >>>>> functions to
> >>>>>> their network management systems after the (software/firmware)
> >>>>>> upgrade.
> >>>>>>
> >>>>>> [mv] From a MEP/MIP perspective, you recognize that the
> >> tunnel/path
> >>>>>> layer is a "thin" layer with just 1 MEG level and thus only
> >>>>> one set of
> >>>>>> MEPs that monitor the network connection. The
> >>>>> service/channel layer is
> >>>>>> a "thick" layer with multiple MEG levels and thus multiple sets of
> >>>>>> MEPs, which support monitoring of the network connection and one
> >> or
> >>>>>> more tandem connections/segments. There is always only one
> >>>>> set of MIPs
> >>>>>> in the service/channel layer (and in the tunnel/path layer), as
> >> MIPs
> >>>>>> operate on the lowest MEG level that is passing through the MIP.
> >>>>>>
> >>>>>> Regards,
> >>>>>> Maarten
> >>>>>>
> >>>>>>
> >>>>>> Ben
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 05/08/2009 04:35, "Maarten Vissers"
> >> <[email-masked]>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Ben,
> >>>>>>>
> >>>>>>> The functional model of a node will specify which functions are
> >>>>>>> supported and in which order/combinations those functions are
> >>>>>>> supported. A node with zero MIPs can be specified as such. As
> >> Kam
> >>>>>> has
> >>>>>>> indicated, such node will not be able to respond to e.g.
> >> loopback
> >>>>>>> messages. But if your network doesn't need the support of e.g.
> >>>>>>> loopback, then a node with zero MIPs is sufficient for
> >>>>> your network.
> >>>>>>> From a vendor's perspective I expect that nodes will contain
> >> MIPs,
> >>>>>>> initially perhaps just on the node level or on ingress ports, in
> >>>>>>> future
> >>>>>> most likely on ingress and egress ports.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Maarten
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: [email-masked]
> >>>>>>> [mailto:[email-masked]]
> >>>>>>> Sent: woensdag 5 augustus 2009 0:54
> >>>>>>> To: [email-masked]; [email-masked];
> >>>>>>> [email-masked]
> >>>>>>> Subject: RE: 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
> >>>>
> >>>> _______________________________________________
> >>>> 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

[http://umail.etri.re.kr/External_ReadCheck.aspx?email=[email-masked]&name=Lam%2c+Hing-Kam+(Kam)&fromemail=[email-masked]&messageid=[email-masked]%3E]

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 12 Aug 2009 16:42:47 +0200

Just to check if it is understood that in a bidirectional connection the
ingress port for the direction A-to-Z is the egress port for the direction
Z-to-A, and vice versa. 
 
MIPs are present in bidirectional connections, and this implies that the
two ports X and Y in a bidirectional connection both contain either 
- a half-MIP, or 
- a MIP (= two half MIPs back-to-back).
 
When both ports contain a half-MIP, then this represents the case of a "MIP
on ingress port X" and "MIP on ingress port Y".
 
When both ports contain a MIP, then this represents the case of a "MIP on
the ingress port X", a "MIP on the egress port X", a "MIP on the ingress
port Y" and a "MIP on the egress port Y".
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Lam, Hing-Kam (Kam)
Sent: woensdag 12 augustus 2009 5:13
To: 류정동; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; ahmpls-
[email-masked]
Subject: Re: [mpls-tp] MIPs in MPLS-TP

Jeong-dong and Qiaogang,

You are right, it should be "..., one on the ingress port and the other on
the egress port."

Regards,

Kam

  _____  

From: 류정동 [mailto:[email-masked]] 
Sent: Tuesday, August 11, 2009 10:52 PM
To: Lam, Hing-Kam (Kam); [email-masked];
[email-masked]; [email-masked]; [email-masked]; mpls-
[email-masked]; [email-masked]
Subject: RE: [mpls-tp] MIPs in MPLS-TP

Question:

Regards,

Jeong-dong

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

-----원본 메시지-----
>From Date: 2009-08-12 오전 11:38:21
To: "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>, "[email-masked]" <neil.
[email-masked]>, "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>, "[email-masked]" <ahmpls-
[email-masked]>
Cc: 
Subject: RE: [mpls-tp] MIPs in MPLS-TP

Ben,

The first sentence in the 3rd paragraph of your rewording reads to me as
"If support for MPLS-TP OAM on intermediate nodes of a transport path is
required, then all the transit nodes MUST support at least one MIP."

Is that your intent? Or do you allow a mix of transit nodes, i.e. some
transit nodes support while the others not. If a mix is allowed, I suggest
the following wording:

"

If support for MPLS-TP OAM on an intermediate node of a transport path is
required, then that node MUST support at least one MIP. A transit node
SHOULD support two MIPs, one on the egress port and the other on the egress
port.
"

Regards,
Kam

> >>>>>>> We would appreciate comments from the whole community

  <http://umail.etri.re.kr/External_ReadCheck.aspx?email=hklam@alcatel-
lucent.com&name=Lam%2c+Hing-
Kam+(Kam)&fromemail=[email-masked]&messageid=%3C1196cfd3-6ea3-4530-b716-
[email-masked]%3E>

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Thu, 13 Aug 2009 12:05:37 -0500

Dear all,

Attached is an enhancement to Maarten’s original figure, with the intention to improve the understanding of the concept of half MIP and full MIP. If it does, then the wording in the MIP requirements (in Malcolm is original wording or its subsequent revisions) may need to be further enhanced.

Regards,
Kam

________________________________
From: Maarten Vissers [mailto:[email-masked]]
Sent: Wednesday, August 12, 2009 10:43 AM
To: Lam, Hing-Kam (Kam); '???'; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls-tp] MIPs in MPLS-TP

Just to check if it is understood that in a bidirectional connection the ingress port for the direction A-to-Z is the egress port for the direction Z-to-A, and vice versa.

MIPs are present in bidirectional connections, and this implies that the two ports X and Y in a bidirectional connection both contain either
- a half-MIP, or
- a MIP (= two half MIPs back-to-back).

When both ports contain a half-MIP, then this represents the case of a "MIP on ingress port X" and "MIP on ingress port Y".

When both ports contain a MIP, then this represents the case of a "MIP on the ingress port X", a "MIP on the egress port X", a "MIP on the ingress port Y" and a "MIP on the egress port Y".

Regards,
Maarten

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lam, Hing-Kam (Kam)
Sent: woensdag 12 augustus 2009 5:13
To: 류정동; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] MIPs in MPLS-TP
Jeong-dong and Qiaogang,

Regards,
Kam

Question:

Regards,

Jeong-dong

-----원본 메시지-----
From: "Lam, Hing-Kam (Kam)" <[email-masked]>
From Date: 2009-08-12 오전 11:38:21
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc:
Subject: RE: [mpls-tp] MIPs in MPLS-TP

Ben,

"

Regards,
Kam