Subject: [Mpls-interop] Slides on MPLS-TP Linear Protection

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 25 Aug 2008 13:21:28 +0200

Hi,

As promised in the last MEAD conf call, attached please find the slides
on MPLS-TP linear protection. We discussed the slides with Stewart in
Dublin and integrated his comments into the attached version.

Please review and comment. It is recommended to look at the slides at
the 'show' mode. 

We would like to start writing the document based on the slides so your
review will be appreciated.

Best regards,

Nurit

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

---

From: Martin Vigoureux <[email-masked]>
Date: Mon, 25 Aug 2008 15:52:23 +0200

Hi Nurit, Yaacov,

thanks for the slides. Two small comments:
- On slide 3, I think it would be preferable not to use Tandem 
Connection to "name" the sub-path on which a connection can be
protected. "Segment" (used right after) is more appropriate.
Indeed Tandem Connection, is currently used to refer to the entity
serving monitoring purposes over a segment (of the LSP or PW).

- If the additional objective was to educate the reader then I think
that complementary info on the "signalling" and coordination actions
between end-points may be useful.

regards,

-m

Sprecher, Nurit (NSN - IL/Hod HaSharon) a écrit :
> ------------------------------------------------------------------------
>

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 26 Aug 2008 13:10:42 +0200

Hi Nurit,

what do you mean when saying that we should use same termino than OAM?
(TC or segment?)

As you say OAM and Survivability are linked, yet they are two different 
things:
IMHO we should not use the same term to describe the entity
used for monitoring (TC) and the portion of the path (segment) over
which is done that monitoring and recovery; hence my proposition.

-m

Sprecher, Nurit (NSN - IL/Hod HaSharon) a écrit :
> Hi Martin,
> Thanks for your review.
> I really doubt whether to use segment or TC. In the survivability framework we used the segment terminology which is consistent with the IETF terminology. I think we should use the same terminology as in OAM, because we are monitoring the entity and perform the segment protection switching based also on OAM triggers.
> Of course we need to address the signaling and coordination actions. We wanted first to see if the team agree on the foundation before we start developing the details.
> Best regards,
> Nurit 
> 
> -----Original Message-----
> From: ext Martin Vigoureux [mailto:[email-masked]] 
> Sent: Monday, August 25, 2008 16:52
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Weingarten, Yaacov (NSN - IL/Hod HaSharon)
> Cc: MEAD team
> Subject: Re: [Mpls-interop] Slides on MPLS-TP Linear Protection
> 
> Hi Nurit, Yaacov,
>

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 26 Aug 2008 12:52:01 +0200

Hi Martin,
Thanks for your review.

-----Original Message-----
From: ext Martin Vigoureux [mailto:[email-masked]] 
Sent: Monday, August 25, 2008 16:52
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Cc: MEAD team
Subject: Re: [Mpls-interop] Slides on MPLS-TP Linear Protection

Hi Nurit, Yaacov,

regards,

-m

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 26 Aug 2008 14:09:44 +0200

Hi Nurit,

You wrote:

> As promised in the last MEAD conf call, attached please find the
> slides on MPLS-TP linear protection. We discussed the slides with
> Stewart in Dublin and integrated his comments into the attached
> version.
> 
> Please review and comment. It is recommended to look at the slides
> at the 'show' mode.
> 
> We would like to start writing the document based on the slides so
> your review will be appreciated.

On slide 3: I agree with Martin that the term "Tandem connection"
should *not* be used in this context.
A tandem connection consists of any number of segments, from 2 to
*all* segments in the path. So it would be better to use the term
segment in this case.
The last item span needs more explanation, if it is a special
segment then it belongs to the list of segments.

Slide 4: the protecting entity is of the same type as the working
entity.

Slide 7, first dash: in case of protection switch the traffic on
both the protecting entities is used. (in 1+1 is not really
switched).
The same for uni-dir.

Slide 8, first bullit: this refers only to 1:1 non-revertive,
in 1:1 revertive the traffic is always sent on the working
entity, during protection it is bridged to the protecting
entity too.

Slide 9: permanent bridge should be selective bridge.

Slide 10A: should we also consider 1+1 b-directional switching?

Slide 16: the use of RDI as an alternative should be avoided.
RDI should only be used for administration (e.g. PM), due to
the filtering it introduces uncertain switching delays. It
does not report signal degrade condition.
(yes I know the IEEE proposes to use RDI, but that is due to
misunderstanding the purpose of RDI).

Regards, Huub.

-- 
================================================================
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: "Drake, John E" <[email-masked]>
Date: Tue, 26 Aug 2008 08:12:58 -0700

I like Martin's proposal 

>From: Martin Vigoureux [mailto:[email-masked]] 
>Sent: Tuesday, August 26, 2008 4:11 AM
>To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
>Cc: MEAD team; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
>used for monitoring (TC) and the portion of the path (segment) 
>over which is done that monitoring and recovery; hence my proposition.
>
>-m
>
>> I really doubt whether to use segment or TC. In the 
>survivability framework we used the segment terminology which 
>is consistent with the IETF terminology. I think we should use 
>the same terminology as in OAM, because we are monitoring the 
>entity and perform the segment protection switching based also 
>on OAM triggers.
>> Of course we need to address the signaling and coordination 
>actions. We wanted first to see if the team agree on the 
>foundation before we start developing the details.
>> Best regards,
>> Nurit
>> 
>> From: ext Martin Vigoureux 
>[mailto:[email-masked]]
>> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Weingarten, 
>Yaacov (NSN - 
>> IL/Hod HaSharon)
>> Cc: MEAD team
>>> Stewart in Dublin and integrated his comments into the 
>attached version.
>>>

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 26 Aug 2008 08:23:47 -0700

Nurit,

I reviewed your slides and they looked like a primer on
protection/restoration.

What exactly are you planning to write that isn't already covered by the
existing MPLS/GMPLS documents?  (E.g., RFCs 5298, 4873, 4872, 4428,
4427, and 4426.) 

Thanks,

John 

>From: Huub van Helvoort [mailto:[email-masked]] 
>Sent: Tuesday, August 26, 2008 5:10 AM
>Cc: MEAD team
>*all* segments in the path. So it would be better to use the 
>term segment in this case.
>Slide 4: the protecting entity is of the same type as the 
>working entity.
>
>Slide 7, first dash: in case of protection switch the traffic 
>on both the protecting entities is used. (in 1+1 is not really 
>switched).
>The same for uni-dir.
>
>entity, during protection it is bridged to the protecting entity too.
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 27 Aug 2008 13:51:12 +0100

All,

John's question captures perfectly my concerns about 
draft-sprecher-mpls-tp-survive-fwk (of which I am an author).

I personally feel that there may be very little new in this I-D. When ring 
protection was still on the table, I think we had an example of something 
that the I-D could throw up as needing more work. But that one seems to have 
been removed for now.

So, I think that this I-D should be (as John implies) a primer. It should 
take the requirements from the requirements I-D and show which building 
blocks should be used to meet the requirements. Lots of cross-references, 
some explanations, no surprises.

Is that everyone else's understanding of what we should be doing?

Thanks,
Adrian

For reference, to complete the list, we have:

RFC 3469
Framework for Multi-Protocol Label Switching (MPLS)-based Recovery

RFC4090
Fast Reroute Extensions to RSVP-TE for LSP Tunnels

RFC 4426
Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional 
Specification

RFC 4427
Recovery (Protection and Restoration) Terminology for Generalized 
Multi-Protocol Label Switching (GMPLS)

RFC 4428
Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based 
Recovery Mechanisms (including Protection and Restoration)

RFC 4872
RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label 
Switching (GMPLS) Recovery

RFC 4873
GMPLS Segment Recovery

RFC 4920
Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE

RFC 5298
Analysis of Inter-Domain Label Switched Path (LSP) Recovery

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 27 Aug 2008 07:23:52 -0700

Works for me. 

>From: Adrian Farrel [mailto:[email-masked]] 
>Sent: Wednesday, August 27, 2008 5:51 AM
>To: MEAD team
>I personally feel that there may be very little new in this 
>I-D. When ring protection was still on the table, I think we 
>had an example of something that the I-D could throw up as 
>needing more work. But that one seems to have been removed for now.
>
>So, I think that this I-D should be (as John implies) a 
>primer. It should take the requirements from the requirements 
>I-D and show which building blocks should be used to meet the 
>requirements. Lots of cross-references, some explanations, no 
>surprises.
>
>Generalized Multi-Protocol Label Switching (GMPLS) Recovery 
>Functional Specification
>
>RFC 4427
>Recovery (Protection and Restoration) Terminology for 
>Generalized Multi-Protocol Label Switching (GMPLS)
>
>RFC 4428
>Analysis of Generalized Multi-Protocol Label Switching 
>(GMPLS)-based Recovery Mechanisms (including Protection and 
>Restoration)
>
>RFC 4872
>RSVP-TE Extensions in Support of End-to-End Generalized 
>Multi-Protocol Label Switching (GMPLS) Recovery
>
>RFC 4873
>GMPLS Segment Recovery
>
>RFC 4920

---

From: <[email-masked]>
Date: Wed, 27 Aug 2008 10:29:15 -0400

Sounds perfect to me as well.

Cheers,
Andy

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Drake, John E
Sent: Wednesday, August 27, 2008 10:24 AM
To: Adrian Farrel; MEAD team
Subject: Re: [Mpls-interop] Slides on MPLS-TP Linear Protection

Works for me.

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 27 Aug 2008 16:49:44 +0200

In general we try not to re-define things and to refer to existing
documents as much as possible.
Maybe I am wrong, but I cannot recall that there is a message defined in
the IETF, to coordinate the protection state between the peers of the
protection switching which is run inband and is not dependent on a
control plane of IP functionality.
I am not sure if there is a way to configure the protection entities
without using a control plane, etc. 
Before defining the messages exchanges, our intention was to see that
people agree to the concept.
Regards,
Nurit

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext
[email-masked]
Sent: Wednesday, August 27, 2008 17:29
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Mpls-interop] Slides on MPLS-TP Linear Protection

Cheers,
Andy

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

Works for me.