Subject: Static PW label provisioning

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 20 Mar 2003 18:17:37 -0500

I agree with Dave Allen that PW Label Withdrawel is not the right mechanism to deal with failure conditions (see attached email). If his proposal is accepted, it would obviate a part of my question, but let me ask it anyway.
 
The pwe3-control draft mentions the option of static provisioning of PW labels. However, the draft mandates the use of the Label Withdraw message to notify the far side about failure conditions. When this failure condition disappears, I presume that the Label Mapping message has to be used to indicate to this to the far end and to reestablish the PW. And, as 5.5.1 explains, it is preferable to use a new PW label value to make sure that there are no problems with sequence numbers. In this case, how can you speak of static provisioning?
 
At a minimum, the draft should state that in case the control word is not used for a certain PW type, the statically provisioned PW labels can be reused.
 
The question remains: what exactly is static provisioning? If it means that there is no need for the Label Mapping message, is there still a need for LDP session initialization and for the Hello protocol? It would be helpful if the draft was more explicit about this.
 
Peter

-----Original Message-----
From: David Allan [mailto:[email-masked]]
Sent: Thursday, March 20, 2003 4:55 PM
To: 'Luca Martini'; [email-masked]
Subject: RE: [PWE3] [Fwd: draft-ietf-pwe3-control-protocol-02.txt]

I'll reiterate a general observation made at the PWE3 meeting mike. 

The draft currently uses label withdraw as a fault notification mechanism. It would be useful if the text stated that this was a MUST only in the absence of other fault notification mechanisms. 

Data plane notification would be particularly useful for physical circuits, PVCs etc. things that do not go away on failure. IMHO withdrawing a label may introduce a lot of overhead for somthing that may need to be promptly put back (circuit flapping). Data plane notification that simply leaves the label in place could be a whole lot simpler. esp. if associated stats need to be journalled when labels are withdrawn.

cheers 
Dave

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 21 Mar 2003 11:18:53 -0500

>I agree with Dave Allen that PW Label Withdrawel is not the right 
>mechanism to deal with failure conditions (see attached email). If his 
>proposal is accepted, it would obviate a part of my question, but let me 
>ask it anyway.

         The use of the label withdraw is acceptable if your time
scale is large enough. If it is not, then a more proactive
mechanism can be used to detect failure conditions such as
VCCV.

         --Tom

>
>The pwe3-control draft mentions the option of static provisioning of PW 
>labels. However, the draft mandates the use of the Label Withdraw message 
>to notify the far side about failure conditions. When this failure 
>condition disappears, I presume that the Label Mapping message has to be 
>used to indicate to this to the far end and to reestablish the PW. And, as 
>5.5.1 explains, it is preferable to use a new PW label value to make sure 
>that there are no problems with sequence numbers. In this case, how can 
>you speak of static provisioning?
>
>At a minimum, the draft should state that in case the control word is not 
>used for a certain PW type, the statically provisioned PW labels can be reused.
>
>The question remains: what exactly is static provisioning? If it means 
>that there is no need for the Label Mapping message, is there still a need 
>for LDP session initialization and for the Hello protocol? It would be 
>helpful if the draft was more explicit about this.
>
>Peter
>
>
>The draft currently uses label withdraw as a fault notification mechanism. 
>It would be useful if the text stated that this was a MUST only in the 
>absence of other fault notification mechanisms.
>
>Data plane notification would be particularly useful for physical 
>circuits, PVCs etc. things that do not go away on failure. IMHO 
>withdrawing a label may introduce a lot of overhead for somthing that may 
>need to be promptly put back (circuit flapping). Data plane notification 
>that simply leaves the label in place could be a whole lot simpler. esp. 
>if associated stats need to be journalled when labels are withdrawn.
>
>cheers
>Dave
>

http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X

---

From: "David Allan" <[email-masked]>
Date: Fri, 21 Mar 2003 13:15:41 -0500

Tom:

Label withdraw is not a detection mechanism....I was referring more to
notification (e.g. 1711 FDI or similar)...

Dave

> From: Thomas D. Nadeau [mailto:[email-masked]] 
> Sent: Friday, March 21, 2003 11:19 AM
> To: Busschbach, Peter B (Peter); [email-masked]
> Subject: Re: [PWE3] Static PW label provisioning
> 
> 
> 
>          The use of the label withdraw is acceptable if your 
> time scale is large enough. If it is not, then a more 
> proactive mechanism can be used to detect failure conditions 
> such as VCCV.
> 
>          --Tom
> 
> 
> >
> >At a minimum, the draft should state that in case the 
> control word is 
> >not

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

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 21 Mar 2003 13:18:45 -0500

It depends on how you look at it.

         --tom

> > From: Thomas D. Nadeau 
> [<mailto:[email-masked]>mailto:[email-masked]]
> > >From: David Allan 
> [<mailto:[email-masked]>mailto:[email-masked]]
><http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X>http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X 
>
>
><https://www1.ietf.org/mailman/listinfo/pwe3>https://www1.ietf.org/mailman/listinfo/pwe3 
>

---

From: "David Allan" <[email-masked]>
Date: Fri, 21 Mar 2003 13:51:31 -0500

Tom:

I'm missing somthing. VCCV can detect PW or PSN errors and the messaging
draft indicates what mappings of PSN/PW problems should be performed into
ACs. But I do not see a means of communcating one AC problem across the PW
except via the MUST withdraw label proviso in the Martini draft. That's the
notification mechanism I was referring to.

??
Dave

> Sent: Friday, March 21, 2003 1:19 PM
> To: Allan, David [CAR:NS00:EXCH]; Busschbach, Peter B 
> (Peter); [email-masked]
> Subject: RE: [PWE3] Static PW label provisioning
> 
> 
> 
> > > scale is large enough. If it is not, then a more 
> proactive mechanism 
> > > can be used to detect failure conditions such as VCCV.
> > >
> > >          --Tom
> > >
> > >
> > > >
> > > >The draft currently uses label withdraw as a fault notification 
> > > >mechanism. It would be useful if the text stated that this was a 
> > > >MUST
> > > only in the
> ><http://www.elsevier-international.com/catalogue/title.cfm?IS
> BN=1558607
> >51X>http://www.elsevier-international.com/catalogue/title.cfm
> ?ISBN=155860751X
> >
> >
> ><https://www1.ietf.org/mailman/listinfo/pwe3>https://www1.iet
f.org/mail
>man/listinfo/pwe3

---

From: [email-masked]
Date: Fri, 21 Mar 2003 18:44:00 -0000

Thomas D. Nadeau wrote 21 March 2003 16:19
> 
> PB=>I agree with Dave Allen that PW Label Withdrawel is not the right 
> TN=> The use of the label withdraw is acceptable if your time

I am not sure on what basis you believe the above is true:  that is, that
some 'in-between' layer OAM is more acceptable (and to whom?), and can
replace/augment proper MPLS layer OAM.  It would certainly not be acceptable
to us (under any circumstances that I can think of), and it does not avoid
the need for proper fault-management of (i) the MPLS network itself (so
please use Y.1711 for p2p LSPs) or (ii) the client layer.  We are seeking
minimal 'in-between' layer functions in any X/MPLS client/server layer
adaptation relationship for the reasons I have previously explained (eg see
my mail to Sasha 19/03/03).

regards, Neil

---

From: Eric Rosen <[email-masked]>
Date: Fri, 21 Mar 2003 15:08:05 -0500

Peter> The question remains: what exactly is static provisioning? 

That's a good question. 

While static provisioning is sometimes regarded as a simplification, I think
it is really a complication, and  an unnecessary one at that.  One should be
able to assume that  if you have PWs, you have a  control connection of some
sort.   If  everything  has to  work  both  in  the  presence of  a  control
connection and  in the absence of  a control connection,  then everything is
just that much more complicated.  Do we really need this complication?

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 21 Mar 2003 15:15:19 -0500

>except via the MUST withdraw label proviso in the Martini draft. That's 
>the notification mechanism I was referring to.

         Sorry, I misread your assertion.  Withdrawing the
label is a heavy weight way of notification of failure, but it
of course should be treated as one if received by the far end.
As Eric just pointed out on another thread,
draft-shah-pwe3-control-protocol-extension-00.txt
provides an interesting way of doing this in cases where you
might not want to withdraw the label.

         --Tom

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 24 Mar 2003 06:45:55 -0500

Tom,

Thanks - I was about to make this same point myself.  I would like to 
propose that this draft either become a WG draft on its own, or be folded 
into draft-ietf-pwe3-control-protocol-02.  As Mark pointed out in that 
other thread, it mirrors the way status signaling is done with L2TP, so it 
maintains the symmetry between MPLS and L2TP tunnels.  It also provides 
status signaling support for the static case without having to withdraw or 
re-advertise static labels.  And to get back to the primary subject of this 
thread, I've been talking to multiple service providers are already either 
planning, testing, or deploying PWE3 services with static labels.  They 
have a number of different requirements that lead to the use of static 
labels, including network management policies and the ability to provision 
PWs that cross area, AS, and/or provider boundaries without requiring the 
use of cross-area, cross-AS, or cross-provider dynamic label 
allocation.  So there are a number of good reasons for retaining static 
provisioning, and using draft-shah-pwe3-control-protocol-extension as the 
status signaling component.

Cheers,
Andy

-------

At 3/21/2003 03:15 PM -0500, Thomas D. Nadeau wrote:

>>ACs. But I do not see a means of communcating one AC problem across the 
>>PW except via the MUST withdraw label proviso in the Martini draft. 
>>That's the notification mechanism I was referring to.
>

---

From: "himanshu shah" <[email-masked]>
Date: Mon, 24 Mar 2003 09:39:41 -0500

Hi Toby,

You are absolutely correct about the status information.

We did present status information as a separate msg in
arp-mediation draft. And yes, you proposed that whole
section.

Incidently, we have been talking about extending the
control protocol in a generic fashion so that future extensions
can be made without having to constantly proposing new FEC types or
messages. This is what I am proposing in the extension draft.

I had run this by Eric and Luca in last IETF meeting and we
agreed that I will write the draft and send it along for
review. Unfortunately, I did not get to it until the last
minute before the deadline for this IETF meeting, so I submitted
the draft, to be reviewed and authored by more people
(including you) for later revision.

Having said that I am curious to know why you do not
believe protocol-ext proposal in not a correct venue?

The protocol-ext proposal is also targetted to be rolled into
main control protocol. I did talk to Luca and Eric about
this during the recent IETF meeting.

regards,
himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Toby
Smith
Sent: Monday, March 24, 2003 9:13 AM
To: Andrew G. Malis
Cc: Thomas D. Nadeau; [email-masked]
Subject: Re: [PWE3] Static PW label provisioning

> Thanks - I was about to make this same point myself.  I would like to
propose
> that this draft either become a WG draft on its own, or be folded into
> draft-ietf-pwe3-control-protocol-02.  As Mark pointed out in that other
> thread, it mirrors the way status signaling is done with L2TP, so it
maintains
> the symmetry between MPLS and L2TP tunnels.  It also provides status
signaling
> support for the static case without having to withdraw or re-advertise
static
> labels.  And to get back to the primary subject of this thread, I've been
> talking to multiple service providers are already either planning,
testing, or
> deploying PWE3 services with static labels.  They have a number of
different
> requirements that lead to the use of static labels, including network
> management policies and the ability to provision PWs that cross area, AS,
> and/or provider boundaries without requiring the use of cross-area,
cross-AS,
> or cross-provider dynamic label allocation.  So there are a number of good
> reasons for retaining static provisioning, and using
> draft-shah-pwe3-control-protocol-extension as the status signaling
component.

Given enough time, everything comes full circle.

When we were discussing draft-shah, I added the section for the new
status message; in the case of draft-shah, it was used to denote CE IP
addresses.  After a lukewarm reception it ended up sticking, but with
the feeling that ultimately it might be nice to move such a message
into the main control draft since it could serve a more generic
purpose.

More recently, we've been using the status message for another
application, namely, to convey the CE-facing interface's status to a
remote PE.  Thinking the time might be at hand to incorporate this
message into pwe3-control, I wrote up a few new sections and sent it
off to Eric and Luca for their thoughts.  They believed that I should
present the message on its own in a separate draft, to avoid any
perceptions of making a control draft end-run.

I was happy with this, but, as this conversation took place a few days
before this IETF deadline, I didn't have time to pull the text into a
separate document in time for this meeting.

It's more or less complete now, though, and if there's no strong
disagreement, I'd love to have one piece of text describing the use of
the status message; while I (with obvious bias...) think that the text
in draft-shah is fine, I don't believe it's the correct venue.

I can post my control extensions later today.

Regards,
Tob

---

From: Toby Smith <[email-masked]>
Date: 24 Mar 2003 09:43:00 -0500

"himanshu shah" <[email-masked]> writes:

> review.

Ah, I've apparently been out of the loop; when I ran my text by Eric &
Luca a few weeks ago, they didn't mention this.

> believe protocol-ext proposal in not a correct venue?

I was referring to the old draft-shah, the arp-mediation draft, not
your new one, which sounds appropriate enough.

Regards,
Tob

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sun, 23 Mar 2003 21:07:07 -0500

Tom,

Cheers,
Andy

-------

---

From: Luca Martini <[email-masked]>
Date: Thu, 27 Mar 2003 16:56:50 -0700

> just that much more complicated.  Do we really need this complication? 
No.
In fact this is historical. At one time we thought that some implementations 
would choose this mode because LDP was too much work to implement. It turned 
out that this was not true.

I Propose that we remove Static PW label provisioning .

Any comments ? ( besides Andy's :-) )

Luca