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

From: "Shahram Davari" <[email-masked]>
Date: Tue, 11 Aug 2009 05:42:30 -0700

Why is it mandatory to have a MIP at each node?

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>; [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

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Tue, 11 Aug 2009 08:51:10 -0500

It is mandatory under the condition that OAM is supported for that LSP. 

As said at the beginning of Malcolm's email, 

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:
> > node MUST support at least one MIP.  

May be we can say this is conditional. :-)

Regards,
Kam

> 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]'
> To: [email-masked] <[email-masked]>; [email-masked]
> <[email-masked]>; [email-masked] <[email-masked]>

---

From: Malcolm Betts <[email-masked]>
Date: Tue, 11 Aug 2009 09:59:13 -0400

Shahram,

The MIP is only "mandatory" if the operator wants the (transit) node to participate in the OAM of the LSP.

Regards,

Malcolm

> From: Shahram Davari [mailto:[email-masked]]
> To: [email-masked] <[email-masked]>; mpls-
> [email-masked] <[email-masked]>; [email-masked] <ahmpls-
> [email-masked]>

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 11 Aug 2009 10:02:19 -0700

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

Regards,
Kam

---

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

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

> Sent: Tuesday, August 11, 2009 1:02 PM
> To: Lam, Hing-Kam (Kam); [email-masked]';
> [email-masked]'; [email-masked]'; [email-masked]'
> 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.
> To: Shahram Davari; [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]'
> 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:
> [email-masked]

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Tue, 11 Aug 2009 13:53:09 -0500

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

> From: Lam, Hing-Kam (Kam)
> Sent: Tuesday, August 11, 2009 1:51 PM

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 11 Aug 2009 11:59:32 -0700

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]'; [email-masked]'
Subject: RE: [mpls-tp] MIPs in MPLS-TP

Hi Shahram,

Regards,
Kam

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Tue, 11 Aug 2009 14:09:00 -0500

Hi Shahram,

Thank you for the clarification.

Regarding Mandatory vs Optional, Malcolm answered in a separate email 'The MIP is only "mandatory" if the operator wants the (transit) node to participate in the OAM of the LSP.' We could call this is 'conditional' too.
I don't think this is in contradiction to the spirit of the IETF's job.

Aren't there a lot of occurrences of "MUST" in the RFCs and I-Ds? :-)

Regards,
Kam

> Sent: Tuesday, August 11, 2009 3:00 PM
> 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
>
> To: Lam, Hing-Kam (Kam); Shahram Davari; [email-masked]';
> 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
>
> > > > > > - Relationship between MEPs and MIPs. I.e. Is a MEP a superset
> of
> > a
> > > > > > the primary case I was thinking about is nodes that only ever
> act
> > as

---

From: <[email-masked]>
Date: Wed, 12 Aug 2009 02:43:53 +0100

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
>
> 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
>

---

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

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 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

> 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]
> provide
> vs

---

From: <[email-masked]>
Date: Wed, 12 Aug 2009 07:45:54 +0100

Thanks Ben,

I understand what you are saying, but I wonder if there is sufficient
clarity wrt S bit sublayer nesting here?  Indeed, I was pleased to see
Adrian pick up this very point in his last mail...when he said:

"But I wonder if we are also missing a discussion of MEPs at transit
nodes? 
Of course, the way we have decided to solve this is by pushing a label
at a 
new MEP, so we have created a new LSP. But it is still important to note

that the node that supports the MEP in this case MUST also support a MIP
for 
the next label up the stack." 

The key point is a MIP is associated with a with a given MPLS sublayer,
whereas MEPs are associated with different MPLS sublayers.

Aside=> I am not convinced that S bit sublayering is a good idea in a
transport network.  However, (i) I recognise this is a basic concept in
'classic MPLS' and (ii) it does allow the sentiment of TCM to be
addressed by an existing MPLS technique.  

So, with that in mind, what do folks think of this slight tweak to the
text Ben proposed based on Malcolm's orginal text (Note - I've added
some clarification comments in here enclosed by {} that would be removed
in the final agreed text.  There are also some typos in the last
sentence which I have corrected, including the covering the case of an
intermediate node on a p2mp LSP):

"The support of OAM on an MPLS-TP transport path is optional. {NH=> This
is fine, but there should be a health-warning somewhere, eg base
requirement draft, that unless CV-like OAM is run on all LSPs then one
cannot be sure of detecting leaking traffic; which could be considered a
client security compromise.}

If support for MPLS-TP OAM on a transport path (either p2p or p2mp) is
required, then the trail termination points of ingress and egress nodes
MUST support a MEP. In the case of a p2mp transport path then a MEP is
required at all the egress nodes.

If support for MPLS-TP OAM on the intermediate nodes of a given
transport path is required, then those nodes MUST support at least one
MIP. A transit node SHOULD ideally support two MIPs one on the ingress
port and the other on the egress port(s)."

regards, Neil

> From: Niven-jenkins,B,Ben,DMF R 
> Sent: 12 August 2009 02:44
> To: Shahram Davari; Lam, Hing-Kam (Kam); Harrison,N,Neil,DEY2 
> R; [email-masked]; [email-masked]; [email-masked]
> >> But what I said in my previous email is what I interpret 
> from Malcolm's
> >> wording in the proposed requirements.
> >> 
> >> Regards,
> >> Kam
> >> 
> >> 
> >>>> From: [email-masked] 
> [mailto:[email-masked]] On
> >>> Behalf
> >>>> Of Shahram Davari
> >>>> that we might like to consider, especially fellow 
> operators...please
> >> see
> >>>> in-line:
> >>>> 
> >>>> units do not contain a network unique source label) then 
> unless CV-
> >> like
> >>>> the same MPLS-TP layer network....a condition that may 
> arise due to
> >> the
> >>>>> node MUST support at least one MIP.  A transit node 
> SHOULD support
> >> two
> >>>>> This should address the concerns with respect to 
> scalability i.e.
> >> the
> >>>> MEPs/MIPs that belonged to a different operating party 
> in equipment
> >> that
> >>>> observation that peer-partition interworking in a non 
> top-of-stack
> >> layer
> >>>>>> - 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
> >>>>>> localization process that uses the loopback OAM tool 
> to identify
> >> the
> >>>>>> the primary case I was thinking about is nodes that 
> only ever act
> >> as
> >>>>>> [mv] If you look at my PE NNI port models (that were 
> attached to
> >> my
> >>>>>> MEPs, which support monitoring of the network 
> connection and one
> >> or

---

From: Malcolm Betts <[email-masked]>
Date: Wed, 12 Aug 2009 11:19:57 -0400

Ben,

My intention was your first interpretation - if you want to support OAM
on a transit node then you MUST support a MIP, and a LSP MUST be able to
transit a node without an active MIP.

To close on a point from Kam;  The MEP and MIP are logical functions if
a node can generate or terminate OAM frames then (by definition) it
supports a MEP function.  If a transit node can respond to OAM messages
then in supports a MIP function.  As Kam stated this does not dictate an
implementation.

Regards,

Malcolm

> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> >> But what I said in my previous email is what I interpret from
> Malcolm's
> >>>> From: [email-masked] [mailto:[email-masked]]
> On
> >>> Behalf
> >>>> Of Shahram Davari
> >>>> units do not contain a network unique source label) then unless
> CV-
> >> like
> >>>> the same MPLS-TP layer network....a condition that may arise due
> to
> >> the
> >>>>> node MUST support at least one MIP.  A transit node SHOULD
> support
> >> two
> >>>>> This should address the concerns with respect to scalability
> i.e.
> >> the
> >>>> MEPs/MIPs that belonged to a different operating party in
> equipment
> >> that
> >>>> observation that peer-partition interworking in a non top-of-
> stack
> >> layer
> >>>>>> MIP and therefore stating all nodes will have a MIP really
> means
> >> all
> >>>>>> localization process that uses the loopback OAM tool to
> identify
> >> the
> >>>>>> [mv] If you look at my PE NNI port models (that were attached
> to
> >> my
> >>>>>> MEPs, which support monitoring of the network connection and
> one
> >> or

---

From: <[email-masked]>
Date: Fri, 14 Aug 2009 01:51:19 +0100

Kam,

A mix of transit nodes supporting MIP and those not supporting MIP must be
allowed IMO.

I like your wording. These are the high level requirements and then I also
like Adrian's decomposition of these (decomposition Malcolm's original
wording actually) into more specific behavioural requirements.

Ben

On 12/08/2009 03:38, "Lam, Hing-Kam (Kam)" <[email-masked]> wrote:

> 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
>