Subject: [mpls-tp] MIPs receiving OAM packets

From: Loa Andersson <[email-masked]>
Date: Sat, 20 Mar 2010 10:33:07 -0700

All,

I've one concern that I don't really know if we have covered.

Consider the situation where you have an LSP with MEPs at
end point and a number of MIPs in between.

A MIP receives an OAM packet. For some reason this OAM packet
was intended for some of the other MIP along the same LSP.

Isn't it necessary that the MIP can positively determine that
the OAM packet is intended for itself?

If so which info does it use to do so? In which document did (do)
we put the requirement.

/Loa
-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: David Allan I <[email-masked]>
Date: Sat, 20 Mar 2010 13:43:37 -0400

Hi Loa:

MIP addressing being based on TTL IMO is relative... It is the MEPs problem to determine if a MIP response is from an unexpected MIP rather than targeting an absolute MIP location with the outgoing transaction. The MIPs job is simply detecting it received a message from an unexpected MEP (not in the MEG)...

The way it works, not everyone is responsible for knowing everything... 

Cheers
D

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Saturday, March 20, 2010 1:33 PM
To: [email-masked]
Subject: [mpls-tp] MIPs receiving OAM packets

All,

Consider the situation where you have an LSP with MEPs at end point and a number of MIPs in between.

A MIP receives an OAM packet. For some reason this OAM packet was intended for some of the other MIP along the same LSP.

Isn't it necessary that the MIP can positively determine that the OAM packet is intended for itself?

If so which info does it use to do so? In which document did (do) we put the requirement.

/Loa
-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13 _______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Loa Andersson <[email-masked]>
Date: Sat, 20 Mar 2010 11:14:47 -0700

Dave,

ok - so far so good.

But let us say that the message received is a loopback request,
then the wrong MIP might set the LSP in loopback mode and this
will only be detected when the MEP initiating the action receives
the response message. The MEP will have to undo the action and then
redo it for the wright MIP

Now if for the same reason that the message was delivered wrongly
the first time ...

/Loa

PS

Now the loopback draft has the receiving MIPid in the request message
so that takes care of this particular situation. But I'm really looking
for what we need to say on a generic level. Maybe it is something like
"Each individual OAM protocol specification needs determine if it is
necessary to to identify the intended receiver positively, and if that
is the case include necessary information."

--

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 20 Mar 2010 12:06:54 -0700

Dear Loa,
you wrote:

Different OAM protocols have different security implications and these shape
mandatory and optional authentication methods. I consider explicit
identification of a Sender and/or Receiver as one of such methods. Perhaps
the recommendation will be more generic if we state:
"Each individual OAM protocol specification needs to evaluate security
implications and select necessary authentication mechanisms accordingly.
Authentication mechanisms may include explicit Sender and/or Target ID,
Authentication keys, etc."

Regards,
Greg

PS. I've noticed that several OAM protocols include Sender/Target IDs as ACH
TLVs while the Loopback OAM included them into the Loopback message. Perhaps
some uniformity across MPLS-TP OAM protocols that use G-ACH may be suggested
as well.

On Sat, Mar 20, 2010 at 11:14 AM, Loa Andersson <[email-masked]> wrote:

>> MIP addressing being based on TTL IMO is relative... It is the MEPs
>> problem to determine if a MIP response is from an unexpected MIP rather than
>> targeting an absolute MIP location with the outgoing transaction. The MIPs
>> job is simply detecting it received a message from an unexpected MEP (not in
>> the MEG)...
>>
>> A MIP receives an OAM packet. For some reason this OAM packet was intended
>> for some of the other MIP along the same LSP.
>>
> _______________________________________________
> mpls-tp mailing list
> [email-masked]

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 21 Mar 2010 00:55:39 -0400

In message <[email-masked]>
> is the case include necessary information."

Loa,

That is a good point.  FRR as currently specified (or other segment
protection) could change the TTL and certainly could change the set of
nodes on the path.  This is particularly true in the case of node
disjoint protection.  A node that was placed into loopback might be
temporarily unreachable via that LSP.  Of course, if the LSP is locked
before being placed into loopback, no traffic is flowing except test
traffic.  When/if the path reverts, the link goes back into loopback.

Maybe node disjoint segment protection slightly incompatible with
loopback.  Maybe it doesn't really matter.  I'm not sure if there are
other cases.

Curtis

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 21 Mar 2010 07:57:49 +0200

Loa, and all,
IMHO this is an excellent example illustrating lack of addressing architecture in MPLS-TP.

AFAIK, the only reasonable substitute discussed so far is using IP addressing "where applicable".
E.g., see draft-ietf-mpls-tp-identifiers with its proposed usage of IP/MPLS FECs where applicable vs. brief mention of ICC-based identifiers for the rest of the cases. 

The difference in level of detail between the former and the latter is easy to see if you compare Sections 7.1.1 (ICC-based identification of OAM entities) and 7.1.2 (IP-based identification of these entities) of this draft.

BTW, it would be interesting to hear if ICC-based identification is deployed in traditional transport networks (SONET/SDH, OTN). 

My 2c,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Saturday, March 20, 2010 7:33 PM
To: [email-masked]
Subject: [mpls-tp] MIPs receiving OAM packets

All,

/Loa
--

---

From: <[email-masked]>
Date: Mon, 22 Mar 2010 09:59:45 -0000

Sasha, reading your comments leads me to make these observations:

1	One of the reasons I disliked having *DP* OAM using the same
label that signifies a logically OOB network for the CP/MP (just like we
find in all co-cs mode networks where GMPLS applies) is security.  One
wants the network that carries the sensitive internal CP/MP protocols to
be as functionally disjoint from the traffic DP it is
controlling/managing as possible. 

If one wanted to be even more technically accurate however, the DP OAM
indicate flag should be part of the normal DP traffic unit header....not
via an extra labelled header (if not clear why, this changes the layer
network characteristic information, and this is generally not a good
thing to do - see next item), and for sure not one that has been
functionally allocated to the CP/MP.

2	The architectural component that arguably defines a layer
network more than any other is the addressing of its access
points.....do this badly at the start and one is usually stuck with that
bad choice (it is not easy to change the addressing of a layer network
post deployment - see later comment on PW layer network addressing).

This was never really treated seriously in MPLS as (at the outset at
least) the behavioural model that it was sold-on was that of a hybrid
co-ps mode layer network working in concert with an IP cl-ps layer
network.  As we now know from all the GMPLS work (and more recently the
MPLS work, esp with PWs):
-	it is plain technically wrong to assume one can have a common CP
'running IP to Optics'...put simply, each layer network needs its own
instance of routing;
-	one should have consistent characteristic information in the
DP....MPLS-TP is indeed decoupling itself from an IP *DP* (this is NOT
the same as having a disjoint *IP-based CP/MP network*, just like all
the GMPLS controlled co-cs mode layer networks have).

It's still not clear to me we have even registered the need for an
agreed addressing structure for MPLS-TP LSPs...probably because folks
still think they are creating a profile (sic) of MPLS (its isn't,
MPLS-TP will repsrenet a different layer network to any other spin of
MPLS).

We have however already created an addressing structure for the PW layer
network based on AIIs....which is an amazingly bad choice if you think
about it, the PW layer network should have used IPv4 or better IPv6
addressing structures (but even better, at least wrt technical accuracy,
the PW should not even exist in MPLS-TP given we are supposed to be
creating a transport network). 

Aside=> One can use IPv6 say addressing for the access points of an SDH
VC4 co-cs mode layer network.  Addressing structure and network mode are
not coupled, they are independent choices.

regards, Neil

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
> Sent: 21 March 2010 05:58
> To: Loa Andersson
> Cc: [email-masked]
> Subject: Re: [mpls-tp] MIPs receiving OAM packets
> 
> Loa, and all,
> E.g., see draft-ietf-mpls-tp-identifiers with its proposed 
> usage of IP/MPLS FECs where applicable vs. brief mention of 
> ICC-based identifiers for the rest of the cases. 
> 
> The difference in level of detail between the former and the 
> latter is easy to see if you compare Sections 7.1.1 
> (ICC-based identification of OAM entities) and 7.1.2 
> (IP-based identification of these entities) of this draft.
> 
> BTW, it would be interesting to hear if ICC-based 
> identification is deployed in traditional transport networks 
> (SONET/SDH, OTN). 
> 
> My 2c,
>      Sasha
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Loa Andersson
>                                               +46 767 72 92 
> 13 _______________________________________________
> mpls-tp mailing list
> [email-masked]