Subject: RE: [PWE3] BFD for MPLS PWs

From: "Sasha Vainshtein" <[email-masked]>
Date: Tue, 1 Aug 2006 19:07:59 +0200

Tom,
I've snipped the long discussion to make your summary and my response
clearly readable:

... snipped ...
>  Lets forget about the LSP ping mode for a second. 
> For BFD there are currently 2 options: 

> 1) BFD 
> or 
> 2) BFD + status codes. 

> What is being proposed are 4 options now: 
>
> 1) BFD (with IP headers) 
> 2) BFD (with IP headers) + status 
> 3) BFD (without IP headers) 
> 4) BFD (without IP headers) + status. 
>
> The intent was for options 1/2 to function as-specified today. The latter
> two are the optimized modes that are useful for those using the
> latest MPLS CW.
> 
> 	--Tom
[Sasha] This short text clarifies the proposal, it's a pity we ahve not started from
this point.

Now my question: 

Would it be correct to say that, where applicable, the actual OA&M functionality 
(i.e. ability to detect and trouble-shoot PW connectivity problems)  provided by 
options (3) and (4) is exactly the same as one provided by options (1) and (2)
respectively, while applicability scope of options (1) and (2) is strictly wider than 
that of (3) and (4)?

Regards,
                        Sasha

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 1 Aug 2006 13:50:37 -0400

On Aug 1, 2006, at 1:07 PM, Sasha Vainshtein wrote:

> respectively, while applicability scope of options (1) and (2) is  
> strictly wider than that of (3) and (4)?

	I don't see why this matters. All 4 have their place.

	--Tom

---

From: "Mustapha Aissaoui" <[email-masked]>
Date: Tue, 1 Aug 2006 14:12:31 -0400

Tom and Sasha,
I do not see the need to add a CV type for the following:
4) BFD (without IP headers) + status 

The argument used so far was that an IP control plane may not exist for
these implementations. Thus, we should restrict the new encapsulation to
work without PW status notifications only.

Mustapha.

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]] 
> Sent: Tuesday, August 01, 2006 1:51 PM
> To: Sasha Vainshtein
> Cc: pwe3 WG ((((E-mail))))
> Subject: Re: [PWE3] BFD for MPLS PWs
> 
> 
> >> The intent was for options 1/2 to function as-specified today. The 
> >> latter two are the optimized modes that are useful for those using 
> >> the latest MPLS CW.
> >>
> >> 	--Tom
> > [Sasha] This short text clarifies the proposal, it's a pity we ahve 
> > not started from this point.
> >
> > Now my question:
> >
> > Would it be correct to say that, where applicable, the actual OA&M 
> > functionality (i.e. ability to detect and trouble-shoot PW 
> > connectivity
> > problems)  provided by

---

From: Rahul Aggarwal <[email-masked]>
Date: Tue, 1 Aug 2006 21:37:23 -0700 (PDT)

Hi Mustapha,

On Tue, 1 Aug 2006, Mustapha Aissaoui wrote:

> these implementations.

How will these "implementations", establish PWs ?

How will they establish PSN tunnels ?

rahul

> Thus, we should restrict the new encapsulation to

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 02 Aug 2006 10:34:46 +0100

>How will they establish PSN tunnels ?

via provisioning?

via an out of band control plane?

Stewart

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 2 Aug 2006 09:53:43 -0400

> How will they establish PSN tunnels ?

	Manually. The BFD+status code mode should
be used for static PWs.  We updated the text
in the last revision to state that explicitly
based on last call comments from several people
including Luca.

	--Tom

---

From: "Mustapha Aissaoui" <[email-masked]>
Date: Wed, 2 Aug 2006 11:58:09 -0400

Tom, 

> Sent: Wednesday, August 02, 2006 9:54 AM
> To: Rahul Aggarwal
> Cc: 'pwe3 WG ((((E-mail))))'; Mustapha Aissaoui; 'Sasha Vainshtein'
> >> The argument used so far was that an IP control plane may 
> not exist 
> >> for these implementations.
> >
> 	Manually. The BFD+status code mode should be used for 
> static PWs.  We updated the text in the last revision to 
> state that explicitly based on last call comments from 
> several people including Luca.

MA> I am not sure I understand what "status" you are referring to here. Did
you mean PW status?
What I am proposing is that we should only have a single CV type similar to
the existing 0x08 for the new encapsulation since it is expected these
implementations will not suppport a T-LDP control plane and will thus use
BFD codes for all OAM notifications.

> 	--Tom
> 
> 
> > rahul
> >
> >> Thus, we should restrict the new encapsulation to work without PW 
> >> status notifications only.
> >>
> >> Mustapha.
> >>
> >>>> options (3) and (4) is exactly the same as one provided 
> by options
> >>>> (1) and (2)

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 3 Aug 2006 00:01:52 -0700 (PDT)

Hi Tom,

On Wed, 2 Aug 2006, Thomas D. Nadeau wrote:

> 	Manually.

>The BFD+status code mode should
> be used for static PWs.

Can you please point me to:

a) Definition of a static PW ?
b) Requirements for a static PW ?
c) Specifically OAM requirements of a static PW ?
d) Definition of a "manually" established PSN ?
e) Requirements for a manually established PSN...

I will probably have a few more questions once these are answered.

  We updated the text
> based on last call comments from several people

Can you please point me to the text in draft-ietf-pwe3-vccv-10.txt that
spells out how BFD is used for static PWs ?

rahul

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 3 Aug 2006 11:05:50 -0400

> e) Requirements for a manually established PSN...

	Static PWs are manually provisioned.

> spells out how BFD is used for static PWs ?

	The text in VCCV as defined does not explicitly state
that it applies to signaled or static PWs, but it doesn't say
that it explicitly doesn't either. We could certainly put a
sentence in that says which portions do (i.e.: the packet format)
and do not if that would make you sleep better at night.
Although as you know there are specific
sections that describe how a PE advertises VCCV capabilities
using the two signaling protocols (see LT2Pv3 + LDP TLVs). However,
if you are not using a signaling protocol, you probably don't want
to advertise the BFD+status code capability (or any others) using
a signaling protocol, right?

	--Tom

>>>>>> options (3) and (4) is exactly the same as one provided by  
>>>>>> options
>>>>>> (1) and (2)

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 3 Aug 2006 12:46:05 -0700 (PDT)

Hi Tom,

> 	Static PWs are manually provisioned.

You didn't answer any of the above. With this state, I don't see how PWE3
can use static PWs as a motivation for adding a new encapsulation
type for BFD for PWs.

> and do not

Perhaps you should first spell out the motivation, requirements and
procedures for establishing static PWs and "manually provisioned PSNs."

> if that would make you sleep better at night.

> a signaling protocol, right?

Before discussing the procedures for BFD for "static PWs", PWE3
should first spell out the motivation, requirements and
procedures for establishing static PWs and "manually provisioned PSNs."

rahul

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 3 Aug 2006 15:54:45 -0400

> can use static PWs as a motivation for adding a new encapsulation

	The motivation for the new encapsulation is not
based on a need to support static PWs. The motivation
for *removing* them from the spec. is that
that mode applies to static PWs only. If you carefully read
the document, you will find that BFD+status codes is not
applicable when signaling is in use. Therefore it makes
no sense to signal that capability.

> procedures for establishing static PWs and "manually provisioned  

	I don't think those things belong in the VCCV specification.
It is a protocol specification, not a requirements document. It
also isn't the purpose of the VCCV document to describe how
static PWs are configured.

	--tom

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 3 Aug 2006 16:03:23 -0700 (PDT)

Hi Tom,

On Thu, 3 Aug 2006, Thomas D. Nadeau wrote:

> based on a need to support static PWs.

I heard Mustapha say that the need for a new encapsulation was driven by
the desire to support PW OAM on devices that do not have an IP control
plane.

Mustapha - Can you please clarify ?

> The motivation
> that mode applies to static PWs only.

That is not correct. The BFD status notifications can be used even if LDP
is used for signaling - in this case status notifications should not be
sent using LDP. See below..

> If you carefully read

This is what the document currently says:

"This type SHOULD not be used when a control protocl such as LDP
   is available that can signal the AC/PW status to the remote
   endpoint of the PW due to complications that can arise from
   synchronization issues between the control protocol's status
   signaling messags and the BFD messages containing fault status
   information. "

The above should be revised to read:

"This type SHOULD not be used when a control protocl such as LDP
   is used to signal the AC/PW status to the remote
   endpoint of the PW due to complications that can arise from
   synchronization issues between the control protocol's status
   signaling messags and the BFD messages containing fault status
   information."

> static PWs are configured.

Agreed. Given the above:

If VCCV includes a new option to encapsulate BFD packets for MPLS PWs, the
motivation and applicability of this option should be clearly articulated.
Further if this applicability includes "static PWs", VCCV must reference a
document that clearly spells out the definition, motivation, requirements
and procedures for static PWs. Further if this is the case VCCV must
clearly spell out which of the procedures in VCCV are applicable to these
"static PWs" and which are not. All of this likely to create much
discussion and delay VCCV.

The alternative would be:

If PWE3 really wants to cater to static PWs, I would suggest the
group to produce a document that describes how the existing set of
mechanisms in PWE3 can be used to establish these static PWs and this
document can desscribe how VCCV can be used for static PWs along with any
potential changes/enhancements to VCCV and any other PWE3 mechanisms.

rahul

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Fri, 4 Aug 2006 10:04:25 +0200

Tom and all,
 
Please see some comments inline below.
I've snipped the parts of the thread that are not related to tese comments to make the remainder more readable.
 
Regards,
                    Sasha

________________________________

From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Thu 03/08/2006 22:54
To: Rahul Aggarwal
Cc: 'pwe3 WG ((((E-mail))))'; Mustapha Aissaoui; Sasha Vainshtein
Subject: Re: [PWE3] BFD for MPLS PWs

... snipped ...
[Tom]        The motivation for the new encapsulation is not
based on a need to support static PWs. The motivation
for *removing* them from the spec. is that
that mode applies to static PWs only.

[Sasha] I agree that BFD with static codes only applies to manually provisioned PWs which are explicitly allowed by the PWE Requirements  (RFC 3916, Section 5.1, 2nd para) and Architecture(RFC 3985, Section 7.1 4th para) documents. I believe this addresses some of Rahul's questions.

I do NOT see, however, any linkage between manual provosioning of the PWs and absense/presense of UDP/IP headers in the VCCV encapsulation. These issues look completely orthogonal to me. 

In fact, my earlier question (Do or do not IP-free encaps for VCCV provide any additional OA&M functionality when comperaed with UDP/IP-based VCCV enacps?) that you've decided not to address looks even more meaningful to me now. 

[Tom] If you carefully read the document, you will find that BFD+status codes is not
applicable when signaling is in use. Therefore it makes no sense to signal that capability.

... snipped to the end ...

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 4 Aug 2006 10:19:29 -0400

> Mustapha - Can you please clarify ?

	For reference there were a number of others who wanted
the new encapsulation.

> sent using LDP. See below..

	Yes, they may be used, but there are many who
have suggested that we prefer the LDP status notifications
over these to simplify implementations.

>    signaling messags and the BFD messages containing fault status

	That sounds reasonable to me.

> potential changes/enhancements to VCCV and any other PWE3 mechanisms.

	I personally don't see why another document is necessary
to describe this. All of VCCV's functions remain the same
for static PWs except that the capability advertisement functions
are not used.  A simple sentence or two is all that is required
to spell this out, although I think it is obvious that
if you are using statically provisioned PWs, that you wouldn't
be using any of the LDP setup messages. :P

	--Tom

>>>>>>>>>> [Sasha] This short text clarifies the proposal, it's a  
>>>>>>>>>> pity we
>>>>>>>>>> ahve

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 4 Aug 2006 10:23:35 -0400

On Aug 4, 2006, at 4:04 AM, Sasha Vainshtein wrote:

> I've snipped the parts of the thread that are not related to tese  
> comments to make the remainder more readable.
>
> Regards,
>                     Sasha
>
> [Sasha] I agree that BFD with static codes only applies to manually  
> provisioned PWs which are explicitly allowed by the PWE  
> Requirements  (RFC 3916, Section 5.1, 2nd para) and Architecture 
> (RFC 3985, Section 7.1 4th para) documents. I believe this  
> addresses some of Rahul's questions.

> I do NOT see, however, any linkage between manual provosioning of  
> the PWs and absense/presense of UDP/IP headers in the VCCV  
> encapsulation. These issues look completely orthogonal to me.
	Yes, I agree.
>
> In fact, my earlier question (Do or do not IP-free encaps for VCCV  
> provide any additional OA&M functionality when comperaed with UDP/ 
> IP-based VCCV enacps?) that you've decided not to address looks  
> even more meaningful to me now.
>
	Precisely the paradox I have been trying to point out! *)

	--Tom

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 7 Aug 2006 10:55:52 +0200

[YJS]  Section 7.1 of RFC 3985 states:

   Setup or teardown of a PW can be triggered by an operator command,
   from the management plane of a PE, by signaling set-up or teardown of
   an AC (e.g., an ATM SVC), or by an auto-discovery mechanism.
   ...
   Manual configuration of PWs can be considered a special kind of
   signaling and is allowed.

[YJS] Same as requirements for any other PW.

[YJS] Same as requirements for any other PW.

[YJS] see above excerpt from RFC 3985

[YJS] I didn't hear anyone talking about manually establishing a PSN.

---

From: Luca Martini <[email-masked]>
Date: Tue, 08 Aug 2006 17:15:59 -0600

Mustapha,

I do not agree with your slightly wider statement "an IP control plane
may not exist for these implementations". We never said this.
What we said is that the Ip header is superfluous for this particular
application.
The PW status messaging is required by RFC4447 ( the WG insisted on the
MUST at the time ), so the VCCV should always use PW status, and may use
 BFD status additionally.

Option 4 is therefore required.

Luca

---

From: Luca Martini <[email-masked]>
Date: Tue, 08 Aug 2006 17:27:42 -0600

Rahul Aggarwal wrote:
[snip]
> and procedures for static PWs. Further if this is the case VCCV must
I diagree.  A reference to rfc4447 is sufficient.

> mechanisms in PWE3 can be used to establish these static PWs and this

this document has already been published as rfc4447 section 3 secont to
last paragraph:
" In addition to the protocol specified herein, static assignment of PW
labels may be used, and implementations of this protocol SHOULD
provide support for static assignment."

> potential changes/enhancements to VCCV and any other PWE3 mechanisms.
VCCV needs to also be able to function for PWs where the labels are
statically assigned.

I do not see a problem here. VCCV will function properly for static PWs.

Luca

---

From: "Mustapha Aissaoui" <[email-masked]>
Date: Tue, 8 Aug 2006 22:36:40 -0400

Luca,
We already have code points 0x04 and 0x08 for the cases below. The only
justification I could find for not wanting to use an IP control channel for
BFD over a PW is because some implementation may not use an IP control
plane, and thus no LDP.

Mustapha. 

> From: Luca Martini [mailto:[email-masked]] 
> Sent: Tuesday, August 08, 2006 7:16 PM
> To: Mustapha Aissaoui
> Cc: 'Thomas D. Nadeau'; 'pwe3 WG ((((E-mail))))'; 'Sasha Vainshtein'
> I do not agree with your slightly wider statement "an IP 
> control plane may not exist for these implementations". We 
> never said this.
> What we said is that the Ip header is superfluous for this 
> particular application.
> The PW status messaging is required by RFC4447 ( the WG 
> insisted on the MUST at the time ), so the VCCV should always 
> use PW status, and may use  BFD status additionally.
> 
> > The argument used so far was that an IP control plane may not exist 
> > for these implementations. Thus, we should restrict the new 
> > encapsulation to work without PW status notifications only.
> > 
> > Mustapha.
> > 
> pity we ahve

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 9 Aug 2006 10:45:04 -0400

The PW's control channel is orthogonal to
the control plane used to setup the PW (if it
exists) except where the control channel is used
to setup the control channel.

	--Tom