Subject: Re: [Mpls-interop] ttl-expiration question

From: "Drake, John E" <[email-masked]>
Date: Mon, 3 Nov 2008 07:34:07 -0800

Huub,

Actually, it doesn't really say much at all.

It mentions setting the TTL to the max for MEP/MEP flows, which is
consistent with my statement that within a hierarchical LSP, the Generic
ACH Label itself is sufficent to deliver OAM packets to the hierarchical
LSP endpoints.

Wrt to MEP->MIP flows, it does mention setting the TTL to the number of
hops, but it also states that a MIP only accepts packets addressed to
it, which is consistent with the use of IP forwarding.

Although it mentions unicast p2p and p2mp, I think that the authors have
an implicit assumption that OAM is operating in the context of
bi-directional LSPs and haven't really explored the raamifications of
uni-directional LSPs.

Thanks,

John

>-----Original Message-----
>From: Huub van Helvoort [mailto:[email-masked]] 
>Sent: Friday, October 31, 2008 3:09 PM
>To: Drake, John E
>Cc: George Swallow; Loa Andersson; MEAD team; Weingarten, 
>Yaacov (NSN - IL/Hod HaSharon)
>Subject: Re: [Mpls-interop] ttl-expiration question
>
>Hi John,
>
>FYI draft-busi-mpls-tp-oam-framework explains the MEP and MIP 
>and the use of TTL to reach a MIP from a MEP.
>
>Regards, Huub.
>=========================
>
>Drake, John E wrote:
>> Snipped, comments inline
>> 
>>>>> I won't use the term tandem-connection since I am not
>>> completely sure
>>>>> of what people mean by that.  I'll use Hierarchical LSP instead.
>>>>>
>>>>> When we did the JWT work, nesting LSPs in a hierarchy was both 
>>>>> assumed and was used as a corner-stone of how the TTL
>>> expiration would work for MPLS-TP.
>> 
>> JD:  Within an Hierarchical LSP, TTL expiration is unnecessary.  The 
>> Generic ACH label itself is sufficient to identify the packet as an 
>> OAM packet at the LSP's endpoints.  To reach the ingress for 
>the cases 
>> of unidirectional P2P and P2MP, as well as to reach 
>intermediate nodes 
>> along the LSP's path, I thought that we had agreed in the interim 
>> meeting that routing the OAM packets was required.
>> 
>> 
>>>>> It was never stated that the mechanism would translate 
>over to the 
>>>>> rest of MPLS without some alterations.
>>>>>
>>>>> I do not recall anyone saying that LSPs would be mapped 
>1-1 to LSPs 
>>>>> further down the hierarchy.  Such an idea goes against all
>>> notions of scalability.
>>>>> If someone wants to place that restriction in their 
>product, please 
>>>>> go ahead (as long as you don't work for my company :-).
>> 
>> JD:  Amen.  This is what I have been saying all along.
>
>
>--
>================================================================
>                   http://www.van-helvoort.eu/ 
>================================================================
>Always remember that you are unique...just like everyone else...
>
_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 4 Nov 2008 18:59:30 +0100

Hi George,
I have thought more about your points of 1x1 mapping (with no
multiplexing) between LSP and TC.
We may need this aggregation (with multiplexing) when monitoring or
protection of a section/span is needed. In such a case we may define a
TC between the LSRs residing at the edge of the section/span and
aggregate all LSPs traversing the section/span over the TC. With this we
can provide the same way of monitoring, protection, etc. also in the
section/span level as with LSPs, PWs and TCs. 
Best regards,
Nurit

-----Original Message-----
From: ext George Swallow [mailto:[email-masked]] 
Sent: Wednesday, October 29, 2008 18:02
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Loa Andersson
Cc: MEAD team; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] ttl-expiration question

I think I mostly agree with Nurit here....

On 10/22/08 3:41 PM, "Sprecher, Nurit (NSN - IL/Hod HaSharon)"
<[email-masked]> wrote:

> The same way as it is done with OAM (TCME), what is the difference?
> I think in the JWT it was discussed how a TC can be set up for a LSP
and
> how it is handled, using label stacking at the edges of a TC. It was
> even indicated how a TC can be defined on active LSP without
disruption
> to the service, using make-before-break. It was indicated that
unlimited
> of nesting can be supported.
> I am a little bit surprised, what was the use of TC in OAM if we do
not
> use it also for protection switching?

I won't use the term tandem-connection since I am not completely sure of
what people mean by that.  I'll use Hierarchical LSP instead.

When we did the JWT work, nesting LSPs in a hierarchy was both assumed
and
was used as a corner-stone of how the TTL expiration would work for
MPLS-TP.
It was never stated that the mechanism would translate over to the rest
of
MPLS without some alterations.

I do not recall anyone saying that LSPs would be mapped 1-1 to LSPs
further
down the hierarchy.  Such an idea goes against all notions of
scalability.
If someone wants to place that restriction in their product, please go
ahead
(as long as you don't work for my company :-).

For MPLS-TP (other than path protection) we can have only link repair.
That
is a repair always goes between two nodes that were originally adjacent
in
the LSP.  If they are adjacent at the physical link level, the link can
be
repaired via another physical link between those two nodes or via
nesting
within another LSP that also goes between those two nodes.  This
preserves
the TTL count.

The same is true for LSP hops are nested in the original configuration.
The
connection over which they are nested will have a working and protect
LSP.
Note that the number of hops in the working and protect LSPs need not be
the
same.

I see no reason to change the OAM mechanisms that were agreed.  The fact
that they do not apply to bypass node-repair or to detour lsps with
different numbers of hops is something that we just deal with.  We
already
have mechanisms that work.  If the new mechanisms cannot be applied
here, so
be it.

...George
 
> From: ext Loa Andersson [mailto:[email-masked]]
> Sent: Wednesday, October 22, 2008 21:35
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
> Cc: MEAD team
> Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:
>> Hi,
>> I think the answer is pretty clear. That is why we need to define the
>> protected segment as a Tandem Connection (TC), with 1:1 mapping to
the
>> end-to-end LSP. The TC should be monitored using TCME and protected
>> accordingly.
>> With TC, we use the MPLS construct of hierarchical LSPs, and each
> level
>> the TTL is setup accordingly.
> 
> exactly how? I assume that no magic is used :)
> 
> /Loa
> 
> 
>> That is why I issued the e-mail a few weeks ago (attached) asking to
>> include the new architectural functional element 'Tandem Connection'
> in
>> the MPLS framework. OAM should handle the TCME, i.e. the maintenance
>> domain that is used to monitor the TC. TC should be used for OAM,
>> protection switching and maybe for other functions as well.
>> Best regards,
>> Nurit
>> 
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of ext Loa Andersson
>> Sent: Tuesday, October 21, 2008 23:11
>> To: MEAD team
>> Subject: [Mpls-interop] ttl-expiration question
>> 
>> 
>> All,
>> 
>> I've a question about how will ttl-expiration work with for
>> Label 13 in the case of segement protection.
>> 
>> In the following scenario Label 13 will end up on top if
>> the TTL is set correctly at F.
>> 
>>      +---+     +---+     +---+     +---+     +---+     +---+
>> -----| A |-----| B |-----| C |-----| D |-----| E |-----| F |-----
>>      +---+     +---+     +---+     +---+     +---+     +---+
>> 
>>      ttl=6     ttl=5     ttl=4     ttl=3     ttl=2     ttl=expired
>> 
>> 
>> So an packet with a Label 13 will reach F and treated as an
>> OAM packet :) !
>> 
>> Now assume that we sprotect the segment from B to E by a path
>> like this:
>> 
>> 
>>      +---+     +---+     +---+     +---+     +---+     +---+
>> -----| A |-----| B |--x--| C |-----| D |-----| E |-----| F |-----
>>      +---+     +---+     +---+     +---+     +---+     +---+
>>                  |                             |
>>      ttl=6     ttl=5                           |
>>                  |                             |
>>                  |                             |
>>                +---+                         +---+
>>                | G |                         | L |
>>                +---+                         +---+
>>                  |                             |
>>                ttl=4                           |
>>                  |                             |
>>                +---+     +---+     +---+     +---+
>>                | H |-----| I |-----| J |-----| K |
>>                +---+     +---+     +---+     +---+
>> 
>>                ttl=3     ttl=2     ttl=expired
>> 
>> 
>> The packet don't reach F :( !
>> 
>> What is the cure? Do we bump the ttl up?
>> 
>> /Loa
>> 
>