Subject: RE: RESEND RE: Control protocol draft - section 5.3.1 chan ge t o PW status.

From: Shahram Davari <[email-masked]>
Date: Thu, 24 Feb 2005 08:22:51 -0800

If a rather broken feature is not in the RFC, it doesn't mean it is disallowed. specially when such feature doesn't need any codepoint, or IANA assignment. Those that feel they would have competitive advantage could still implement and sell it. 

I think it is time for IETF to consider architectural principles that could ensure simplicity and future reuse of its standards, rather than short term kludges.

-Shahram

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Thomas D. Nadeau
> Sent: Thursday, February 24, 2005 10:54 AM
> To: David Allan
> Cc: [email-masked]'; [email-masked]'; 'Luca 
> Martini'; 'Mustapha
> Aissaoui'
> Subject: Re: RESEND RE: [PWE3] Control protocol draft - section 5.3.1
> change t o PW status.
> 
> 
> 
> 
> >  I've never been happy with label withdraw, esp. when either
> >  AIS or RDI termination at a PE is indicative of an AC fault
> >  and if not ignored, withdrawl on RDI will ultimately lock
> >  down the PW (as withdrawl escalates all faults to AIS at 
> the far AC).
> >
> >  I would agree with Mustapha's concerns, backwards
> >  compatibility with somthing that is broken is not really a 
> good idea.
> 
> 	I have to disagree and agree with Luca's original assertion.
> There are too many deployments in the field that are working
> just fine to disallow this as an option going forward.  Ultimately
> folks may choose to not configure this behavior once all of the
> status signaling is implemented, but we should not preclude
> those that are working today and want to keep with what they have.
> 
> 	--Tom
> 
> 
> 
> 
> >
> >  cheers
> >  Dave
> >
> >>>> Luca,
> >>>> However, it all appears that if the label withdraw PW status
> >>> method is
> >>>> used, then a label is withdrawn if say a AIS cell is
> >>> received from the
> >>>> local ATM network or LMI indicated a fault. Am I wrong?
> >>>>
> >>>>
> >>>>
> >>> yes. This is correct, then the remote end would re-generate
> >>> the AIS alarm.
> >>>
> >>>> Also, how should we interpret the new text? Initially, you
> >> advertize
> >>>> the label regardless of the state of AC. Then, if the PW status
> >>>> negotiation results in the use of the label withdraw PW
> >>> status method,
> >>>> would you immediately withdraw the label because the AC is
> >>> not active?
> >>>>
> >>>>
> >>>>
> >>> That would be my understanding. Some state needs to be kept
> >>> for this PW,
> >>> for the life of the LDP session, to indicate that the PW 
> uses label
> >>> withdraw method.
> >>>
> >>>
> >>>> I would like to see a simplification to the procedures. The
> >>> reason why
> >>>> label withdrawal is to be avoided as much as possible is 
> because it
> >>>> confuses a fault condition with an adiministrative
> >>> operation. We do not
> >>>> want to have the network react to some unstable CPE or L2 network
> >>>> condition.
> >>>>
> >>>>
> >>>>
> >>> For this reason we have PW status TLV infrastructure.
> >>> Remember that this
> >>> is a MUST implement, therefore this is what is going to be
> >>> used by ALL
> >>> PWE3 implementations.
> >>>
> >>>> I suggest that regardless of the PW status method used, 
> a label is
> >>>> withdrawan only if the user configures the AC administrative
> >>> state to
> >>>> DOWN. Any other fault condition should raise an alarm to the
> >>> management
> >>>> system but should not cause a label withdrawal.
> >>>>
> >>>>
> >>>>
> >>> This would break any status notification.
> >>> The intent is not to break current deployments. After all
> >>> they must be
> >>> working fine with just the label withdraw method.
> >>> Whether this text is there or not , the implementations will
> >>> implement
> >>> label withdraw anyway. We all agree that if there is no label
> >>> advertisement the PW is down.
> >>> That is the main point.
> >>> Why are you so keen in disabling the backward compatibility ?
> >>> I would like this standard to be implemented, not the old
> >>> draft-martini.
> >>>
> >>> Luca
> >>>
> >>>> Mustapha.
> >>>>
> >>>> -----Original Message-----
> >>>> From: [email-masked] [mailto:[email-masked]]
> >>> On Behalf Of
> >>>> Luca Martini
> >>>> Sent: Friday, February 18, 2005 10:45 AM
> >>>> To: [email-masked]
> >>>> Cc: [email-masked]
> >>>> Subject: Re: [PWE3] Control protocol draft - section 5.3.1
> >>> change to PW
> >>>> status.
> >>>>
> >>>> [email-masked] wrote:
> >>>>
> >>>>
> >>>>
> >>>>> Luca asked:  Please let me know if you have any comments
> >> about this
> >>>>> text.
> >>>>>
> >>>>> Question:  Is there is any inference in this text (or
> >> other text in
> >>>>> this draft, or in any other draft for that matter) that a
> >>> PW must be
> >>>>> taken down in response to a failure on an AC?  If there is
> >>> then its wrong.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> In the new PW status design, described here , the  PW is 
> not "taken
> >>>> down ", but instead attachment circuit status is
> >> communicated to the
> >>>> remote end of the PW. So the answer is no. Example ATM AIS
> >>> alarm. The
> >>>> AIS OAM cells will be passed along the PW , additionally a
> >> PW status
> >>>> TLV "interface Receive Fault" will also be transmitted in
> >>> the control
> >>>> protocol.
> >>>>
> >>>> Luca
> >>>>
> >>>>
> >>>>
> >>>>> One should NEVER take down a server layer trail in response to a
> >>>>> defect
> >>>>> in some client layer link connection.  Just think if we did
> >>> this for
> >>>>> all nested layer networks right down to optics!
> >>>>>
> >>>>> regards, Neil
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: [email-masked] [mailto:[email-masked]]
> >>> On Behalf
> >>>>>> Of Luca Martini
> >>>>>> Sent: 17 February 2005 23:35
> >>>>>> To: PWE3 WG (E-mail)
> >>>>>> Subject: [PWE3] Control protocol draft - section 5.3.1
> >>> change to PW
> >>>>>> status.
> >>>>>>
> >>>>>>
> >>>>>> In this section , we were asked to make the implementation
> >>> of the PW
> >>>>>> status messages/TLV mandatory.
> >>>>>> Also all "CE-facing port" terminology will be changed to
> >>> "attachment
> >>>>>> circuit".
> >>>>>>
> >>>>>> 5.3.1. Use of Label Mappings.
> >>>>>>
> >>>>>>  The PEs MUST send PW label mapping messages to their
> >>> peers as soon
> >>>>>> as
> >>>>>>  the PW is configured and administratively enabled,
> >> regardless of
> >>>>>> the
> >>>>>>  CE-facing interface state. The PW label should not be 
> withdrawn
> >>>>>>  unless the user administratively configures the
> >>> CE-facing interface
> >>>>>>  down (or the PW configuration is deleted entirely). Using the
> >>>>>> procedures outlined in this section a simple label
> >>> withdraw method
> >>>>>>  MAY also be supported as a primitive means of signaling
> >>> PW status.
> >>>>>> It
> >>>>>>  is strongly RECOMMENDED that the PW status signaling 
> procedures
> >>>>>> below
> >>>>>>  be fully implemented. In any case if the Label mapping is not
> >>>>>>  available the PW MUST be considered in the down state.
> >>>>>>
> >>>>>> will change to:
> >>>>>>
> >>>>>> 5.3.1. Use of Label Mappings.
> >>>>>> The PEs MUST send PW label mapping messages to their peers
> >>> as soon as
> >>>>>> the PW is configured and administratively enabled,
> >>> regardless of the
> >>>>>> attachment circuit state. The PW label should not be
> >>> withdrawn unless
> >>>>>> the user administratively configures the CE-facing
> >>> interface down (or
> >>>>>> the PW configuration is deleted entirely). Using the procedures
> >>>>>> outlined in this section a simple label withdraw method
> >>> MUST also be
> >>>>>> supported as a primitive means of signaling PW status. In
> >>> any case if
> >>>>>> the Label mapping is not available the PW MUST be
> >>> considered in the
> >>>>>> down state.
> >>>>>>
> >>>>>> Once, the PW status negotiation procedures are completed
> >>> and if they
> >>>>>> result in the use of the label withdraw method for PW status
> >>>>>> communication, the label withdraw PW status method MUST be
> >>> used. This
> >>>>>> will result in the PW label mapping message being
> >>> advertised only if
> >>>>>> the attachment circuit becomes active. The PW status signaling
> >>>>>> procedures described in this section MUST be fully implemented.
> >>>>>>
> >>>>>>
> >>>>>> Please let me know if you have any comments about this 
> text. Luca
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> pwe3 mailing list
> >>>>>> [email-masked]
> >>>>>> https://www1.ietf.org/mailman/listinfo/pwe3
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> _______________________________________________
> >>>>> pwe3 mailing list
> >>>>> [email-masked]
> >>>>> https://www1.ietf.org/mailman/listinfo/pwe3
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> pwe3 mailing list
> >>>> [email-masked]
> >>>> https://www1.ietf.org/mailman/listinfo/pwe3
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> pwe3 mailing list
> >>> [email-masked]
> >>> https://www1.ietf.org/mailman/listinfo/pwe3
> >>>
> >>>
> >>
> >
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 24 Feb 2005 11:42:40 -0500

> If a rather broken feature is not in the RFC, it doesn't mean it is 
> disallowed. specially when such feature doesn't need any codepoint, or 
> IANA assignment. Those that feel they would have competitive advantage 
> could still implement and sell it.

	The problem with this approach is that it eliminates the
possibility for backwards compatibility for standard
implementations.

> I think it is time for IETF to consider architectural principles that 
> could ensure simplicity and future reuse of its standards, rather than 
> short term kludges.

	A while back some said that IP was a kludge,
and again recently MPLS. So I wouldn't say that
all kludges are necessarily bad because they are
not architecturally pure.  That is IMHO not what
the IETF is all about. :P

	--Tom

---

From: Shahram Davari <[email-masked]>
Date: Thu, 24 Feb 2005 09:22:31 -0800

> possibility for backwards compatibility for standard

No it doesn't. It only eliminates the possibility for
backward compatibility for products that ONLY implement this
RFC. So one could still claim Standards compliance if they implement
extra functions.

> the IETF is all about. :P

I never heard anybody suggest that the Kludge that
we are talking about is good.

-Shahram

> >> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> >> Thomas D. Nadeau

---

From: "David Allan" <[email-masked]>
Date: Thu, 24 Feb 2005 16:55:08 -0500

Hi Luca:

Technically if withrawal means broken, then both AIS and RDI mean broken.
Only withdrawing on AIS has problems...

rgds
Dave

> From: Luca Martini [mailto:[email-masked]] 
> Sent: Thursday, February 24, 2005 3:46 PM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: 'Mustapha Aissaoui'; [email-masked]'; [email-masked]'
> Subject: Re: RESEND RE: [PWE3] Control protocol draft - 
> section 5.3.1 change t o PW status.
> 
> 
> David Allan wrote:
> 
> > 
> Yes I agree.
> I only meant withdraw on AIS, is that not what is specified 
> in the atm 
> document ?
> Luca
> 
> 
> >>>yes. This is correct, then the remote end would 
> re-generate the AIS 
> >>>alarm.
> >>>
> >>>      
> >>>
> >>>That would be my understanding. Some state needs to be 
> kept for this 
> >>>PW, for the life of the LDP session, to indicate that the PW uses 
> >>>label withdraw method.
> >>>
> >>>
> >>>      
> >>>
> Remember that 
> >>>this is a MUST implement, therefore this is what is going to be
> >>>used by ALL 
> >>>PWE3 implementations.
> >>>
> >>>      
> >>>
> >>>>I suggest that regardless of the PW status method used, a 
> label is 
> they must 
> >>>be working fine with just the label withdraw method.
> >>>>>defect in some client layer link connection.  Just think 
> if we did
> >>>>>          
> >>>>>
> >>>this for
> >>>      
> >>>
> >>>>>>below  be fully implemented. In any case if the Label 
> mapping is 
> >>>>>>not  available the PW MUST be considered in the down state.
> >>>>>>
> >>>>>>will change to:
> >>>>>>