Subject: Re: [Mpls-interop] Overview v10 and meeting notes uploaded

From: Stewart Bryant <[email-masked]>
Date: Mon, 07 Apr 2008 15:59:09 +0100

Nurit Sprecher wrote:
> Hi Stewart,
> LSP Path merge is problematic for OAM in connection-oriented/transport
> techniques since the traffic source becomes ambiguous and unknown. 
> Best regards,
> Nurit
>
>   
I am not sure that is the case, specifically I am not sure preventing 
merge solves the problem.

To know who sent you a packet you really need a real ID inside the 
packet, rather that implying a source from a path via a destination label.

If your primary source of ID is the destination label, that is subject 
to a fairly simple, possibly systematic misconfiguration an LSR. On the 
other hand an identifier in the OAM packet is something that you can 
trust at whatever level of trust you wish to impose.

Stewart

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

---

From: "LASSERRE, Marc \(Marc\)" <[email-masked]>
Date: Mon, 7 Apr 2008 17:13:52 +0200

Stewart, Nurit,

Without merging, there is a 1:1 mapping between a destination and a
source.

It remains true that mis-configuration could lead to using the incorrect
destination label from an unexpected source. As you said, this could be
verified via OAM where a source ID would be used to check against the
expected source if needed. Hence, once this is verified, using a
destination label (unique per source when no merging is done) could be
sufficient.

Marc

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: lundi 7 avril 2008 16:59
To: Nurit Sprecher
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Mpls-interop] Overview v10 and meeting notes uploaded

To know who sent you a packet you really need a real ID inside the 
packet, rather that implying a source from a path via a destination
label.

Stewart

---

From: Loa Andersson <[email-masked]>
Date: Mon, 07 Apr 2008 22:33:39 +0200

Nurit,

exactly what is the problem of adding "source information" in the
OAM information that follows the ACH?

/Loa

Nurit Sprecher wrote:
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Stewart Bryant
> Sent: Monday, April 07, 2008 16:17
> To: Malcolm Betts
> Cc: [email-masked]; [email-masked]; [email-masked]
> A couple of comments:
> 1) It would be nice to retain the name of the individual contributors in
> 
> some form, rather than just listing their companies.
> 
> 2) Slide 7  - "no LSP path merge" if strictly interpreted this is quite 
> restrictive in the design. Is this really the requirement or is it 
> really a simplification of a more complex problem - adequate resources +
> 
> trail to trail disambiguation etc.? This may not be the time/place to 
> discuss, but we should understand this at some time.
> 
> Stewart
> 
> 
> Jwt mailing list
> [email-masked]
> http://mail.testbed.se/mailman/listinfo/jwt
> 
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]
_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 07 Apr 2008 17:14:40 -0400

Yes, and you can then tracking that at the end-points.  We in fact
already have that information in the BFD session information (discriminator
+ src + destination) information and can track it back to the originator
easily. From there if you want to examine the underlying path, use LSP
tree-trace based on that FEC at the originating point.

    --Tom

---

From: Loa Andersson <[email-masked]>
Date: Tue, 08 Apr 2008 08:44:13 +0200

Nurit,

LSPid?

/Loa

Nurit Sprecher wrote:
> Hi Loa,
> 
> How do you differentiate between 2 LSPs that were originated by the same
> source and got merged at a certain point in the network, like in the
> very simple case in the following figure?
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> This can happen in Traffic-Engineered/Transport network.
> 
>  
> 
> In addition, if we use another identifier in the OAM packet (e.g. src
> identification/address), we need to hold this information at each MP (in
> addition to the label) information to verify the packet integrity. 
> 
> What about AIS generation? We'll need to generate it for each LSP......
> 
>  
> 
> Also what is this src identifier? If one of the requirements is to
> decouple between a control plane and the OAM mechanism, we can not count
> on IP src address. So if MPLS is implemented over Ethernet server, it
> will be MAC address, and if in a future phase we'll decide to implement
> for example MPLS over optical server layer (with GFP), it will be
> another identifier. So should we include also the identifier type? Etc.
> 
>  
> 
> Label merging is purposed for scalability of labels. Do we really have
> issue of scalability in the transport network with a 20-bit length
> label?
> 
>  
> 
> Best regards,
> 
> Nurit
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> From: ext Loa Andersson [mailto:[email-masked]] 
> Sent: Monday, April 07, 2008 23:34
> To: Nurit Sprecher
> Cc: Stewart Bryant; Malcolm Betts; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Jwt] RE: [Mpls-interop] Overview v10 and meeting notes
> uploaded
> 
>  
> 
> Nurit,
> 
>  
> 

-- 
Loa Andersson

---

From: "Italo Busi" <[email-masked]>
Date: Tue, 8 Apr 2008 09:16:11 +0200

Loa, Nurit,

I think that for some OAM functions adding a source information (in the forms of
source address and LSPid) could work.

However there are some OAM functions (e.g. connection verification, aka
connectivity supervision, and loss measurement) that are not able to work, as
far as I can understand.

Considering Nurit's example, if there is a mismerge condition affecting the blue
LSP, the destination node is not able to detect whether it affects the blue, the
red or both LSPs.

In order to perform loss measurement on each LSP, the destination node has also
to know whether packets are received from the red or blue LSP.

I also agree with Nurit's comment regarding the scalability. If and where the
number of labels (LSPs) becomes too high, label stacking allows reducing the
number of LPSs in transit nodes.

Italo

> [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: Tuesday, April 08, 2008 8:44 AM
> To: Nurit Sprecher
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Mpls-interop] [Jwt] RE: Overview v10 and 
> meeting notes uploaded
> 
> Nurit,
> 
> LSPid?
> 
> /Loa
> 
> Nurit Sprecher wrote:
> > Hi Loa,
> > 
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf
> > Of
> > 
> >> ext Stewart Bryant
> > 
> >> 1) It would be nice to retain the name of the individual 
> contributors
> > in
> > 
> > 
> >> really a simplification of a more complex problem - 
> adequate resources
> > +
> > 
> >

---

From: Loa Andersson <[email-masked]>
Date: Tue, 08 Apr 2008 10:44:30 +0200

> LSP, the destination node is not able to detect whether it affects the blue, the

and how do you decide that on the received label?

> to know whether packets are received from the red or blue LSP.

well the LSPid or the bfd method (discriminator + source + destination)
would solve that

/Loa

-- 
Loa Andersson

---

From: "Malcolm Betts" <[email-masked]>
Date: Tue, 8 Apr 2008 08:26:35 -0400

The problem is not confined to the OAM flow, that is easy to fix by
including the source identifier in the OAM frame.
 
The more difficult problem is demultiplexing the connections at the
receive end. In the diagram below how can the box on the far right
demultiplex the frames from the "blue" and "orange" connections.
Clearly if the client is an IP router it does not need to rely on the
server layer to distinguish the source (since it is in the IP header).
However for an arbitrary client it is necessary for the server layer to
distinguish between the client connection that it is supporting.

Malcolm Betts 
Nortel Networks 
Phone: +1 613 763 7860 (ESN 393) 
email: [email-masked] 

Confidentiality Notice:  This message and any attachments may contain
information that is privileged and confidential. If you have reason to
believe that you are not the intended recipient or a person responsible
for delivering this message to an intended recipient, you are hereby
notified that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have reason to believe that
you are not the intended recipient or a person responsible for
delivering this message to an intended recipient, please contact the
sender immediately by reply email and destroy all copies of the original
message.

________________________________

	From: Nurit Sprecher [mailto:[email-masked]] 
	Sent: Monday, April 07, 2008 6:39 PM
	To: ext Loa Andersson
	Cc: Stewart Bryant; Betts, Malcolm (CAR:X632);
[email-masked]; [email-masked]; [email-masked]; Nurit Sprecher
	Subject: RE: [Jwt] RE: [Mpls-interop] Overview v10 and meeting
notes uploaded

	Hi Loa,

	How do you differentiate between 2 LSPs that were originated by
the same source and got merged at a certain point in the network, like
in the very simple case in the following figure?

	 

	In addition, if we use another identifier in the OAM packet
(e.g. src identification/address), we need to hold this information at
each MP (in addition to the label) information to verify the packet
integrity. 

	What about AIS generation? We'll need to generate it for each
LSP......

	Also what is this src identifier? If one of the requirements is
to decouple between a control plane and the OAM mechanism, we can not
count on IP src address. So if MPLS is implemented over Ethernet server,
it will be MAC address, and if in a future phase we'll decide to
implement for example MPLS over optical server layer (with GFP), it will
be another identifier. So should we include also the identifier type?
Etc.

	Label merging is purposed for scalability of labels. Do we
really have issue of scalability in the transport network with a 20-bit
length label?

	Best regards,

	Nurit

	 

	-----Original Message-----
	From: ext Loa Andersson [mailto:[email-masked]] 
	Sent: Monday, April 07, 2008 23:34
	To: Nurit Sprecher
	Cc: Stewart Bryant; Malcolm Betts; [email-masked];
[email-masked]; [email-masked]
	Subject: Re: [Jwt] RE: [Mpls-interop] Overview v10 and meeting
notes uploaded

	Nurit,

	exactly what is the problem of adding "source information" in
the

	/Loa

	> 1) It would be nice to retain the name of the individual
contributors in

	 

	-- 

	Loa Andersson

	Kista, Sweden                      email:
[email-masked]

	                                            [email-masked]

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 8 Apr 2008 12:08:34 -0700

>From: Alexander Vainshtein [mailto:[email-masked]] 
>Sent: Tuesday, April 08, 2008 6:20 AM
>To: Malcolm Betts
>Cc: Stewart Bryant; [email-masked]; [email-masked]; 
>[email-masked]; Nurit Sprecher; ext Loa Andersson
>Malcolm and all,
>I have been following this discussion for some time now, and 
>it seems to me that the underlying problems have been 
>perceived but have not been explicitly named yet.
> 
>The first of these problems is lack of an addressing scheme 
>for links and nodes in MPLS-TP. (The word "multiple" in the 
>right pane on Slide 14 could be IMHO as well replaced by "none".)

JD:  Why wouldn't we re-use the existing addressing scheme?
 
> 
>I strongly doubt that the attempts to replace such a scheme 
>with various kludges (like overlaying the labels with the 
>source ID/address functionality) could work. This doubt is 
>closely related to my second problem, namely the MPLS-TP label 
>space definition (or, actually, lack thereof).
> 
>As you know, RFC 3031 has defined two label spaces in an LSR:
>
>*	per-platform. Incoming labels from this space are 
>handled regardless of the link on which they have been received
>*	link-specific.  Incoming labels from this space can be 
>shared between all the MPLS-capable links, and their handling 
>is defined by the combination of the ingress link and label.
>
>This definition implies (or so it seems to me) that, in the 
>case of stacked labels, only the upper one can be from the 
>link-specific space, the rest of the labels in the stack MUST 
>be from the per-platform space. 

JD:  Why?

> 
>Co-cs (SONET/SDH) and earlier co-ps networks (FR and ATM) have 
>used only link-specific labels (timeslots, DLCI, VPI or 
>VPI/VCI combination). This fact facilitated trivial pairing of 
>two directions of the each connection:
>
>*	Both directions always crossed the same set of links
>*	On each link, both directions have always used the same label.

JD:  It's been a while since I did anything with ATM, but I don't
remember any    requirement that the same label be used in both
directions.  In GMPLS there is no such requirement.
  
>
>This technique does not work with stacked labels in MPLS, but 
>since MPLS does not deal with bi-directional connections, nobody cares.

JD:  See above.  Label stacking in GMPLS works just fine. 

>MPLS-TP presumably requires bi-directional connections, so the 
>label space issue becomes relevant. 

JD:  I don't think there is any label space issue.  GMPLS supports
bi-directional LSPs and LSP hierarchy.

> 
>One way out of this problem could be administrative 
>domain-global labels managed by the OSS, but this looks to me 
>as a serious scalability problem not to mention links between 
>administrative domains. (Please note that the example of a 
>"global SDH" network given by Maarten does not fit, since the 
>"labels" are link-specific.)
> 
>My 2c.
>             Sasha
> 
> 
> 
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Malcolm Betts
>Sent: Tuesday, April 08, 2008 3:27 PM
>To: Nurit Sprecher; ext Loa Andersson
>Cc: Stewart Bryant; [email-masked]; [email-masked]; 
>[email-masked]
>	The problem is not confined to the OAM flow, that is 
>easy to fix by including the source identifier in the OAM frame.
>	 
>	The more difficult problem is demultiplexing the 
>connections at the receive end. In the diagram below how can 
>the box on the far right demultiplex the frames from the 
>"blue" and "orange" connections.  Clearly if the client is an 
>IP router it does not need to rely on the server layer to 
>distinguish the source (since it is in the IP header).  
>However for an arbitrary client it is necessary for the server 
>layer to distinguish between the client connection that it is 
>supporting.
>	 
>
>	Malcolm Betts 
>	Nortel Networks 
>	Confidentiality Notice:  This message and any 
>attachments may contain information that is privileged and 
>confidential. If you have reason to believe that you are not 
>the intended recipient or a person responsible for delivering 
>this message to an intended recipient, you are hereby notified 
>that any review, dissemination, distribution, or copying of 
>this message is strictly prohibited. If you have reason to 
>believe that you are not the intended recipient or a person 
>responsible for delivering this message to an intended 
>recipient, please contact the sender immediately by reply 
>email and destroy all copies of the original message.
>
>	 
>
>
>		Subject: RE: [Jwt] RE: [Mpls-interop] Overview 
>v10 and meeting notes uploaded
>		
>		
>
>		Hi Loa,
>
>		How do you differentiate between 2 LSPs that 
>were originated by the same source and got merged at a certain 
>point in the network, like in the very simple case in the 
>following figure?
>
>		 
>
>		 
>
>		
>
>		 
>
>		 
>
>		 
>
>		In addition, if we use another identifier in 
>the OAM packet (e.g. src identification/address), we need to 
>hold this information at each MP (in addition to the label) 
>information to verify the packet integrity. 
>
>		Also what is this src identifier? If one of the 
>requirements is to decouple between a control plane and the 
>OAM mechanism, we can not count on IP src address. So if MPLS 
>is implemented over Ethernet server, it will be MAC address, 
>and if in a future phase we'll decide to implement for example 
>MPLS over optical server layer (with GFP), it will be another 
>identifier. So should we include also the identifier type? Etc.
>
>		 
>
>		Label merging is purposed for scalability of 
>labels. Do we really have issue of scalability in the 
>transport network with a 20-bit length label?
>
>		 
>
>		Best regards,
>
>		Nurit
>
>		 
>
>		 
>
>		 
>
>		 
>
>		 
>
>		 
>
>		Cc: Stewart Bryant; Malcolm Betts; 
>[email-masked]; [email-masked]; [email-masked]
>		Subject: Re: [Jwt] RE: [Mpls-interop] Overview 
>v10 and meeting notes uploaded
>
>		 
>
>		Nurit,
>
>		 
>
>		> From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of
>
>		> ext Stewart Bryant
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 09 Apr 2008 11:58:38 +0100

Nurit Sprecher wrote:
>
> Hi Loa,
>
> How do you differentiate between 2 LSPs that were originated by the 
> same source and got merged at a certain point in the network, like in 
> the very simple case in the following figure?
>
>  
>
>  
>
>  
>
The only way that you can distinguish using Labels is to rely on the 
integrity of the label system, and yet here we are considering that case 
where it is compromised - I therefore share Loa's concern as to how you 
figure this out from the labels?

When I said source address, I was not thinking about this case, but we 
can fix that with source address + instance identifier.

> identification/address), we need to hold this information at each MP 
> (in addition to the label) information to verify the packet integrity.
>
Is your concern that previously you used the label a proxy for the node 
identifier, and now you need a real identifier. If that is the concern 
that I would have thought that a real identifier (that is network 
unique) was an improvement.

> What about AIS generation? We'll need to generate it for each LSP......
I do not understand the implications here.
> decouple between a control plane and the OAM mechanism, we can not 
> count on IP src address. So if MPLS is implemented over Ethernet 
> server, it will be MAC address, and if in a future phase we'll decide 
> to implement for example MPLS over optical server layer (with GFP), it 
> will be another identifier. So should we include also the identifier 
> type? Etc.
>
Probably we should, though we could impose a common type. For example we 
could include an Ethernet address in a device without an Ethernet 
interface in order to provide a convenient UID. There is certainly 
presidence for that approach.

Let me step up a level - can we assert that all boxes will have a UID, 
either included an manufacture, or loaded via management via a unique 
identifiable physical path?
> issue of scalability in the transport network with a 20-bit length label?
>
Surely we fix that with hierarchy?

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 09 Apr 2008 12:08:11 +0100

Malcolm Betts wrote:
> server layer to distinguish the source (since it is in the IP 
> header).  However for an arbitrary client it is necessary for the 
> server layer to distinguish between the client connection that it is 
> supporting.
>  
The original context was PHP, in which case the context passed must be 
sufficient to identify the next processing operation.

In the case of IP then the IP address does that.

In the case of MPLS the top label (for example the PW label) does that.

In the case of OAM we are suggesting that an identifier in the OAM 
payload would be sufficient, and in the case of certain network faults 
would probably be better than implying the source from the destination 
label.

Stewart

---

From: "Italo Busi" <[email-masked]>
Date: Fri, 11 Apr 2008 12:13:04 +0200

Sasha,
 
my comments in line marked with [ib]
 
Italo

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alexander Vainshtein
Sent: Tuesday, April 08, 2008 3:20 PM
To: Malcolm Betts
Cc: Nurit Sprecher; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Jwt] RE: [Mpls-interop] Overview v10 and meeting notes uploaded

Malcolm and all,
I have been following this discussion for some time now, and it seems to me that
the underlying problems have been perceived but have not been explicitly named
yet.
 
The first of these problems is lack of an addressing scheme for links and nodes
in MPLS-TP. (The word "multiple" in the right pane on Slide 14 could be IMHO as
well replaced by "none".) 
 
I strongly doubt that the attempts to replace such a scheme with various kludges
(like overlaying the labels with the source ID/address functionality) could
work. This doubt is closely related to my second problem, namely the MPLS-TP
label space definition (or, actually, lack thereof).

*	per-platform. Incoming labels from this space are handled regardless of
the link on which they have been received 

*	link-specific.  Incoming labels from this space can be shared between
all the MPLS-capable links, and their handling is defined by the combination of
the ingress link and label.

This definition implies (or so it seems to me) that, in the case of stacked
labels, only the upper one can be from the link-specific space, the rest of the
labels in the stack MUST be from the per-platform space. 

[ib] Is it really a MUST? I have not seen this requirement in RFC 3031.
So far T-MPLS supports both per-platform and per-interface label spaces as in
RFC 3031.
I think this is valid also for MPLS-TP.

Co-cs (SONET/SDH) and earlier co-ps networks (FR and ATM) have used only
link-specific labels (timeslots, DLCI, VPI or VPI/VCI combination). This fact
facilitated trivial pairing of two directions of the each connection:

This technique does not work with stacked labels in MPLS, but since MPLS does
not deal with bi-directional connections, nobody cares.
MPLS-TP presumably requires bi-directional connections, so the label space issue
becomes relevant. 

[ib] I think this issue was already identified and analysed within ITU-T.
As opposed to ATM and SONET/SDH, bidirectional T-MPLS LSPs do not need to have
the same label in the transmit and receive direction. An LSR needs only to know
the relationship between the label value used in the transmit direction and the
label value used in the receive direction for that bidirectional LSP: the former
value is allocated by the downstream node (as per RFC 3031) and the latter is
allocated by the LSR itself.
I think this is valid also for MPLS-TP.

One way out of this problem could be administrative domain-global labels managed
by the OSS, but this looks to me as a serious scalability problem not to mention
links between administrative domains. (Please note that the example of a "global
SDH" network given by Maarten does not fit, since the "labels" are
link-specific.)

[ib] In SONET/SDH "labels" (timeslot) are link-specific. The timeslots are
interchanged at every SONET/SDH XC. The only difference with (T-)MPLS(-TP) is
that SONET/SDH mandates that the timeslot used in the transmit direction MUST be
the same used in the receive direction.

My 2c.
             Sasha

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Malcolm
Betts
Sent: Tuesday, April 08, 2008 3:27 PM
To: Nurit Sprecher; ext Loa Andersson
Cc: Stewart Bryant; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Jwt] RE: [Mpls-interop] Overview v10 and meeting notes uploaded

The problem is not confined to the OAM flow, that is easy to fix by including
the source identifier in the OAM frame.
 
The more difficult problem is demultiplexing the connections at the receive end.
In the diagram below how can the box on the far right demultiplex the frames
from the "blue" and "orange" connections.  Clearly if the client is an IP router
it does not need to rely on the server layer to distinguish the source (since it
is in the IP header).  However for an arbitrary client it is necessary for the
server layer to distinguish between the client connection that it is supporting.

Malcolm Betts 
Nortel Networks 

Confidentiality Notice:  This message and any attachments may contain
information that is privileged and confidential. If you have reason to believe
that you are not the intended recipient or a person responsible for delivering
this message to an intended recipient, you are hereby notified that any review,
dissemination, distribution, or copying of this message is strictly prohibited.
If you have reason to believe that you are not the intended recipient or a
person responsible for delivering this message to an intended recipient, please
contact the sender immediately by reply email and destroy all copies of the
original message.

  _____  

From: Nurit Sprecher [mailto:[email-masked]] 
Sent: Monday, April 07, 2008 6:39 PM
To: ext Loa Andersson
Cc: Stewart Bryant; Betts, Malcolm (CAR:X632); [email-masked];
[email-masked]; [email-masked]; Nurit Sprecher
Subject: RE: [Jwt] RE: [Mpls-interop] Overview v10 and meeting notes uploaded

Hi Loa,

How do you differentiate between 2 LSPs that were originated by the same source
and got merged at a certain point in the network, like in the very simple case
in the following figure?

 

What about AIS generation? We'll need to generate it for each LSP..

Also what is this src identifier? If one of the requirements is to decouple
between a control plane and the OAM mechanism, we can not count on IP src
address. So if MPLS is implemented over Ethernet server, it will be MAC address,
and if in a future phase we'll decide to implement for example MPLS over optical
server layer (with GFP), it will be another identifier. So should we include
also the identifier type? Etc.

Label merging is purposed for scalability of labels. Do we really have issue of
scalability in the transport network with a 20-bit length label?

Best regards,

Nurit

 

-----Original Message-----
From: ext Loa Andersson [mailto:[email-masked]] 
Sent: Monday, April 07, 2008 23:34
To: Nurit Sprecher
Cc: Stewart Bryant; Malcolm Betts; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Jwt] RE: [Mpls-interop] Overview v10 and meeting notes uploaded

Nurit,

/Loa

 

-- 

Loa Andersson

                                            [email-masked]

---

From: "Italo Busi" <[email-masked]>
Date: Fri, 11 Apr 2008 12:24:12 +0200

Loa,

> and how do you decide that on the received label?

You can decide it because the mismerged traffic is received with the label
identifying the blue traffic.

Of course, this mechanism needs to be coupled with a Connectivity Verification
OAM function that carries a globally unique identifier (called MEG ID in Y.1731)
for the LSP.
The destination node, when receives the CV OAM PDU with a the label identifying
the blue LSP and with a MEG ID different from the expected one can understand
that there is a mismerge problem on the blue LSP.

The node can then perform the consequent action of dropping all the packets
received with the blue label (until the mismerge condition is solved) while
allowing the packets received from the red LSP processed.

Italo

> From: Loa Andersson [mailto:[email-masked]] 
> Sent: Tuesday, April 08, 2008 10:45 AM
> To: Italo Busi
> Cc: 'Nurit Sprecher'; [email-masked]; [email-masked]; 
> [email-masked]
> >> (e.g. src
> >> really have