Subject: [Mpls-interop] [Fwd: Users of Y.1711]

From: Loa Andersson <[email-masked]>
Date: Thu, 27 Mar 2008 18:41:12 +0100

All,

this is something that been nagging me since Philadelphia, and
it is brought up again by the message that Huub sent out to SG13
and SG15 on

Huub describes the MEP to MIP communication for OAM info as
follows:

To make the OAM label visible to a MIP the TTL in the server
(lower) layer is set by the MEP to expire when the OAM frame
reaches the intended MIP.

Now, RFC3032 says:

    If the outgoing TTL of a labeled packet is 0, then the labeled packet
    MUST NOT be further forwarded; nor may the label stack be stripped
    off and the packet forwarded as an unlabeled packet.  The packet's
   lifetime in the network is considered to have expired.

    Depending on the label value in the label stack entry, the packet MAY
    be simply discarded, or it may be passed to the appropriate
    "ordinary" network layer for error processing (e.g., for the
    generation of an ICMP error message, see section 2.3).

    When a labeled packet is forwarded, the TTL field of the label stack
    entry at the top of the label stack MUST be set to the outgoing TTL
    value.

This functionality is captured in silicon.

Note that it is the ttl of the "transport" label that expires, now if we
want the behavior that Huub describes, we need to look for the OAM label
in every packet with an expiring ttl. This changes silicon.

Or did I miss something???

/Loa
-- 
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: "David Sinicrope" <[email-masked]>
Date: Thu, 27 Mar 2008 12:51:08 -0500

I thought the same thing when I read his description.  This same
description is mentioned on slides 8 and 28 of the baseline slide deck.
-Dave S.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Thursday, March 27, 2008 1:41 PM
To: [email-masked]
Subject: [Mpls-interop] [Fwd: Users of Y.1711]

All,

this is something that been nagging me since Philadelphia, and it is
brought up again by the message that Huub sent out to SG13 and SG15 on

To make the OAM label visible to a MIP the TTL in the server
(lower) layer is set by the MEP to expire when the OAM frame reaches the
intended MIP.

Now, RFC3032 says:

    If the outgoing TTL of a labeled packet is 0, then the labeled
packet
    MUST NOT be further forwarded; nor may the label stack be stripped
    off and the packet forwarded as an unlabeled packet.  The packet's
   lifetime in the network is considered to have expired.

    Depending on the label value in the label stack entry, the packet
MAY
    be simply discarded, or it may be passed to the appropriate
    "ordinary" network layer for error processing (e.g., for the
    generation of an ICMP error message, see section 2.3).

/Loa
--
Loa Andersson

---

From: <[email-masked]>
Date: Thu, 27 Mar 2008 15:38:40 -0400

Loa and Dave,

If you read sections 2.2 through 2.4 of 3032, I believe the intention
was that if the "network layer" of the packet being transported by MPLS
can be inferred by the topmost label, and TTL expires, then it should be
possible to kick the packet to a appropriate "software" process that can
generate an appropriate error message. The RFC uses the example of
generating ICMP when the network layer is IP, but is not restricted to
only that. In the T-MPLS case, the "network layer" is packet transport
including OAM. If option 1 were in force, then presumably the
cooperating LSRs and T-MPLS switches would all be provisioned with label
ranges for IP and packet transport, and the processing of a packet when
TTL expires depends on which label range is in the top label.

I put "software" above in quotes because whether it's actually handled
in SW or HW is implementation dependent (doesn't affect
interoperability).

Of course, that's the theory. Whether it's implemented that way in
people's silicon is another matter.

Cheers,
Andy

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of David Sinicrope
Sent: Thursday, March 27, 2008 1:51 PM
To: Loa Andersson; [email-masked]
Subject: Re: [Mpls-interop] [Fwd: Users of Y.1711]

-----Original Message-----

All,

Now, RFC3032 says:

/Loa
--
Loa Andersson

---

From: Loa Andersson <[email-masked]>
Date: Thu, 27 Mar 2008 21:22:40 +0100

[email-masked] wrote:
> generating ICMP when the network layer is IP,
Eric Rosen confirms that this was the intention
> but is not restricted to
> only that. 
well, according to Eric IP was the only case considered, and he also
says that it is outdated
> In the T-MPLS case, the "network layer" is packet transport
> including OAM. 
sure - but would you be able to infer that from the topmost label, and
if you can infer that it is OAM you don't need the OAM Alert Label

but this misses the point I'm making, in the t-mpls case (or LFU case)
you don't infer from topmost label, but from the second from top in the
stack

> If option 1 were in force, then presumably the

this is forwarding, and forwarding is done in silicon

/Loa

-- 
Loa Andersson

---

From: David Ward <[email-masked]>
Date: Thu, 27 Mar 2008 19:44:58 -0500

Loa  -

> if you can infer that it is OAM you don't need the OAM Alert Label

DW: How can you infer it?

> you don't infer from topmost label, but from the second from top in  

DW: iff you are  exceptioned

> this is forwarding, and forwarding is done in silicon

We discussed a solution in Philly. As Kireeti mentioned "make  
everything a MEP" and *everyone agreed that in reality that was going  
to be the case. We then discussed that given that there aren't Label  
Switch Routers (channeling ca. 1997) that can only operate as circuit  
midpoints, having everything be a MEP was most practical. The other  
is ... inspect the second label when you get a TTL expire to see if  
there  is an OAM label or divine it any other way. The "bet" was that  
TTL expiring packets already required some different processing than  
"regular" packets that sneaking one below wasn't catastrophic not to  
mention that they are <<<< non TTL expiring packets.

-DWard

>> reaches the

---

From: Loa Andersson <[email-masked]>
Date: Fri, 28 Mar 2008 08:06:40 +0100

> DW: How can you infer it?

the point was that you can't

> DW: iff you are  exceptioned

well - but the point is that every packet where the ttl expires needs to
be exceptioned, and that is not present in in silicon today
> We discussed a solution in Philly. As Kireeti mentioned "make everything 
> a MEP" and *everyone agreed that in reality that was going to be the 
> case. We then discussed that given that there aren't Label Switch 
> Routers (channeling ca. 1997) that can only operate as circuit 
> midpoints, having everything be a MEP was most practical. The other is 
> ... inspect the second label when you get a TTL expire to see if there  
> is an OAM label or divine it any other way. The "bet" was that TTL 
> expiring packets already required some different processing than 

ah - yes; if you are saying that that the hack with setting the ttl
such that it expires at the MIP then it is fine, only problem is that
it is in the message from Huub to SG13 and SG15

/Loa

-- 
Loa Andersson

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 28 Mar 2008 10:21:11 +0000

I think Loa's point was that a 3032bis is needed to define this behavior
as right now this new functionality directly contradicts this.  The concern
I have is that there are devices out there with inconsistent processing of
TTL handling (pipe/hose/etc... models). It is not impossible to fix,
however, we just need to make sure the functionality is clearly spelled out
and agreed to. What we don't want to do is hose existing LSRs that will not
have any code updated (say core) for a long time.

    --Tom

---

From: David Ward <[email-masked]>
Date: Fri, 28 Mar 2008 08:17:06 -0500

The intention is what I wrote. I couldn't grok Huub's preamble to the  
question on label 14 whatsoever. I didn't understand why it was  
included vs a straightforward "has anyone deploy Y.1711." It seems  
some folks were able to understand it and we need to refine the  
message to be just the question. Malcolm, can you help here?

-DWard

On Mar 28, 2008, at 2:06 AM, Loa Andersson wrote:
>>> ...

....snip...

>> everything a MEP" and *everyone agreed that in reality that was  
>> going to be the case. We then discussed that given that there  
>> aren't Label Switch Routers (channeling ca. 1997) that can only  
>> operate as circuit midpoints, having everything be a MEP was most  
>> practical. The other is ... inspect the second label when you get  
>> a TTL expire to see if there  is an OAM label or divine it any  
>> other way. The "bet" was that TTL expiring packets already  
>> required some different processing than "regular" packets that  
>> sneaking one below wasn't catastrophic not to mention that they  
>> are <<<< non TTL expiring packets.
>

---

From: David Ward <[email-masked]>
Date: Fri, 28 Mar 2008 08:20:50 -0500

Note that if they are going to play in the transport profile for  
MPLS, they are going to have to be upgraded to handle the processing  
of the new packets. If they aren't playing, they'll get the TTL  
expire and drop the packet. I don't see what breaks...

-DWard

On Mar 28, 2008, at 5:21 AM, Thomas Nadeau wrote:

>>>> it is

---

From: Loa Andersson <[email-masked]>
Date: Fri, 28 Mar 2008 15:03:53 +0100

David,

David Ward wrote:
> 
> Note that if they are going to play in the transport profile for MPLS, 
> they are going to have to be upgraded to handle the processing of the 
> new packets.

do you mean e.g. OAM packets? If so this is a new definition of
"profile", my take has always been that the profile is something that
is a full implementation could handle, but LSRs that has only
implemented "the profile" wouldn't necessarily be able to play in
an IP/MPLS network, if this is not true this is a diverge point.

Lets face - the ttl stuff is a hack and should not be supported, it is
not needed for MEP to MEP,

the tragic here is that with PHP there would be no problem, but
people seems so set on FFU so they don't take the time to bother.

/Loa

> If they aren't playing, they'll get the TTL expire and drop 
> the packet. I don't see what breaks...
> 
> -DWard
> 
> 

-- 
Loa Andersson

---

From: Nadeau Thomas <[email-masked]>
Date: Fri, 28 Mar 2008 14:06:07 +0000

Agreed; we just need to make it clear which profile they are playing  
in, as well as the case were a box plays in both spaces.

	--Tom

>>> going

---

From: Nadeau Thomas <[email-masked]>
Date: Fri, 28 Mar 2008 14:06:07 +0000

--Tom

---

From: David Ward <[email-masked]>
Date: Fri, 28 Mar 2008 12:20:13 -0500

All -

I've asked some folks Vach, Marc, George, Luca, Stewart, Rahul,  
Kireeti, Ben, Tom N to work on the MIP OAM use cases (TTL expire) and  
also the protection/restoration scenarios.  The reviewed will be by  
the entire group when ready.

Are there errors or ambiguities that need to be cleared up in the  
current set (-04)? Note -04 will be on ftp server shortly.

-DWard

---

From: "BRUNGARD, DEBORAH A, sbcuid" <[email-masked]>
Date: Fri, 28 Mar 2008 16:25:38 -0500

Hi,

Some suggestions:
- slide 7
"IP forwarding is not required to support of OAM or data packets"
Is it "not required" or "should not be required" e.g.
"IP forwarding should not be required to support OAM or data packets."
- slide 8 typo: defined at that codepoint-> defined for that codepoint
- slide 8 typo: but, not necessarily -> but, not necessarily,
- slide 44: I didn't understand what these sentences were trying to say:
"This follows the model of GMPLS nesting and hierarchy exactly 
Thus, if MPLS label stack not useful in this scenarios demonstrates
critical flaw in GMPLS architecture."

- slide 49 "Some open discussion points" I wasn't sure why these points
were called out as the top three remaining items? Were these identified
by the ITU folks?

1. 1st point is on one-way delay:
"One way delay measurement techniques are just emerging and very hard to
solve. Decision: architecture can not preclude it
No issues w/ 2-way delay"
----
"architecture can not preclude it" is this a typo and should say
"architecture can preclude it"?
If it's not precluded, I'm not sure would conclude "are just emerging
and very hard to solve". Y.1731 has a solution (MEF has been very much
involved (Dinesh probably can comment more)). So I don't think it's a
very hard problem for us to solve if we can do similar to Y1731 (with
same architectural assumptions).

2. 3rd point:
"Measurement of packet loss to support PMs and detection of degraded
performance is difficult
One approach is to encapsulate the appropriate Y.1731 pdus in an ACH"
----
Not sure would say it's difficult - maybe difficult to do in a
meaningful way - but if could do similar to Y1731 (with same
architectural assumptions - for point-to-point only), I think we can
solve it too. So I think both of these items are solvable.

Good weekends-
Deborah

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of David Ward
Sent: Friday, March 28, 2008 1:20 PM
To: Loa Andersson
Cc: [email-masked]
Subject: Re: [Mpls-interop] [Fwd: Users of Y.1711]

All -

-DWard

---

From: "LASSERRE, Marc \(Marc\)" <[email-masked]>
Date: Mon, 31 Mar 2008 14:08:45 +0200

Dave,

The -04 rev does not include the new slides, which cover the MIP OAM
case with TTL expiry, that I sent you.

Thanks,
Marc

-----Original Message-----
Sent: vendredi 28 mars 2008 18:20

All -

-DWard

---

From: Loa Andersson <[email-masked]>
Date: Mon, 31 Mar 2008 14:30:56 +0200

All,

what happens to the TTL expiry hack if we have a fast reroute
or a detour?

/Loa

-- 
Loa Andersson

---

From: "Malcolm Betts" <[email-masked]>
Date: Mon, 31 Mar 2008 10:20:06 -0400

Loa, the point you raised has highlighted a potential difference in the
behaviour of the ITU protection mechanism and fast reroute.

I have copied the JWT and the ahtmpls list to get some other input.  My
thoughts are below:

In an ITU protection scenario both the active and backup paths are
monitored and therefore MEPs/MIPs exist on both paths.  In the event of
a failure the MEPs/MIPs on the (old) active path are used to monitor
that path to detect when it recovers and also to assist in fault
location (in the case where the lower layers cannot isolate the fault).

So the MIPs are "static" over a protection switch event i.e. the paths
do not change and the monitoring continues over protection events.  The
only change is that traffic is routed over a different path.

Protection switching (or restoration) in a lower layer (server layer)
must not impact the MEPS/MIPs in the client layer.

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.

> Sent: Monday, March 31, 2008 8:31 AM
> To: LASSERRE, Marc (Marc)

---

From: Loa Andersson <[email-masked]>
Date: Tue, 01 Apr 2008 11:43:01 +0200

Malcolm Betts wrote:
> monitored and therefore MEPs/MIPs exist on both paths.

yes - seems to be the an obvious approach

> In the event of
> that path 

yes - but in MPLS the path is defined by the label, if the failure
causes no label switched traffic over that path, when how does this
work

> to detect when it recovers 
I can understand  the "when it recovers" part
and also to assist in fault
> do not change and the monitoring continues over protection events.

with the caveat that there is not traffic? or what did I miss?

> The

yes - but I thought that there was a requirement that the OAM traffic
should follow the same path as the payload traffic
> must not impact the MEPS/MIPs in the client layer.

how can tht be? If you have a ring with nodes A to H, where traffic
enter enters at A, passes B anc C and exists at D. And you have a
MIP at C, then a failure that occurs at the link between B and C and
causes the traffic to traverse the ring in the other direction
A to H to G to F to E to D, clearly affects the MIP at C

again what is it tht I don't understand, clearly also if you use the
ttl hack to reach B, in the example above the ttl will terminate the
OAM traffic at G, but there is no guarantee that there is a MIP at G!

Wouldn't it be better to have an architecture that always bring the
OAM packet to the intended MIP or MEP??

/Loa

> Jwt mailing list
> [email-masked]
> http://mail.testbed.se/mailman/listinfo/jwt
> 
> 

-- 
Loa Andersson

---

From: "Malcolm Betts" <[email-masked]>
Date: Tue, 1 Apr 2008 09:31:41 -0400

Loa, I think we have a "hidden" assumption on ITU protection:

Segment protection is always between MEPs, logically the working and
protection paths have independent MEPs and each path runs OAM
independent of the traffic flow.  The OAM for the active path must
follow the same path as the traffic.  This is implemented by using the
same tunnel label for OAM and traffic.

OAM should monitor the path independent of the traffic, e.g. the rate of
cc messages is independent of the number of traffic frames that have
been sent.

Also see in line below:

Malcolm Betts
Nortel Networks

> From: Loa Andersson [mailto:[email-masked]] 
> Sent: Tuesday, April 01, 2008 5:43 AM
> To: Betts, Malcolm (CAR:X632)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Jwt] RE: [Mpls-interop] [Fwd: Users of Y.1711]
> 
> 
> 
> Malcolm Betts wrote:
> > Loa, the point you raised has highlighted a potential difference in 
> > the behaviour of the ITU protection mechanism and fast reroute.
> > 
> > I have copied the JWT and the ahtmpls list to get some 
> other input.  
> > My thoughts are below:
> > 
> yes - but in MPLS the path is defined by the label, if the 
> failure causes no label switched traffic over that path, when 
> how does this work

At the head end the selector directs traffic to the standby by path.
However,  the head end MEP should continue to emit OAM frames.

> I can understand  the "when it recovers" part and also to 
> assist in fault

Correct.

> yes - but I thought that there was a requirement that the OAM 
> traffic should follow the same path as the payload traffic

The OAM on the active path follows the traffic.

> how can tht be? If you have a ring with nodes A to H, where 
> traffic enter enters at A, passes B anc C and exists at D. 
> And you have a MIP at C, then a failure that occurs at the 
> link between B and C and causes the traffic to traverse the 
> ring in the other direction A to H to G to F to E to D, 
> clearly affects the MIP at C

This OAM is now running on the standby path (same as the traffic)
different set of MIPs.

> 
> again what is it tht I don't understand, clearly also if you 
> use the ttl hack to reach B, in the example above the ttl 
> will terminate the OAM traffic at G, but there is no 
> guarantee that there is a MIP at G!
> 
> Wouldn't it be better to have an architecture that always 
> bring the OAM packet to the intended MIP or MEP??

The requirement is that the OAM reaches the MIPs/MEP on the path
that the traffic has taken.  Checking the source MEP identifier
determines if this is the "expected" MIP/MEP.

> > 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.
> >  
> > 
> >> what happens to the TTL expiry hack if we have a fast reroute or a 
> >> detour?
> >>
> >> /Loa
> >>