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

From: "Brian Branscomb" <[email-masked]>
Date: Wed, 12 Aug 2009 05:50:11 -0700

Hi Adrian

Shouldn't the transit node support TWO OR MORE MIPS - one for the
ingress and one for each egress (alolwing for P2MP LSPs)?

Regards,

Brian

> ----- Original Message -----

Date: Tue, 11 Aug 2009 15:20:37 +0100

From: "Adrian Farrel" <[email-masked]>

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

To: "Malcolm Betts" <[email-masked]>

Cc: [email-masked]

Hi Malcolm,

Good stuff.

We will need to try to rephrase this to give guidance to the
implementation. Note that the deployment requirements drive the
implementation requirements so that if we intend to say that it is
optional to deploy OAM on an LSP, the MPLS-TP nodes MUST have sufficient
mechanisms implemented to support the OAM if the operator decides to
deploy OAM on the LSP.

> The support of OAM on a MPLS-TP LSP is optional.

I think this has two consequences. The first is easy...

- It MUST be possible to configure the operation of

OAM at the ingress MPLS-TP node on a per LSP basis.

The implication of this first point is that an ingress MPLS-TP node MUST
be capable of supporting a MEP.

The second is more complicated because it relates to how transit and
egress nodes can chose to offer OAM services, and how the OAM services
operate if the nodes do not support them.

I think we have...

- An egress MPLS-TP node MUST be capable of supporting a MEP

and MUST respond correctly to received OAM messages

according to local configuration and policy.

- A transit MPLS-TP node MUST be capable of supporting a MIP

for any LSP, and SHOULD be capable of supporting two MIPs

for any LSP (one on its ingress port for the LSP, and one on its

egress port for the LSP).

- A transit MPLS-TP node MUST be capable of reporting (to a

management system or through OAM messages) the location of

any MIPs it supports on each LSP.

- The activation of a MIP at a transit MPLS-TP node for any LSP

SHOULD be subject to local configuration and policy.

- The OAM mechanisms MUST continue to operate across a transit

MPLS-TP node that supports only one MIP, or that is configured

to not have an active MIP for a given LSP.

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.

Cheers,

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 12 Aug 2009 19:31:45 +0100

Brian,

Quite right.

Adrian
----- Original Message ----- 
From: "Brian Branscomb" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, August 12, 2009 1:50 PM
Subject: Re: [mpls-tp] MIPs in MPLS-TP

Hi Adrian

Regards,

Brian

Cc: [email-masked]

Hi Malcolm,

Good stuff.

I think we have...

Cheers,

Adrian

--------------------------------------------------------------------------------

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