Subject: status signalling of MPLS PW state

From: Luca Martini <[email-masked]>
Date: Mon, 09 Jun 2003 13:00:38 -0600

WG,

The text below was sent to me by Toby Smith as a proposal to resolve some 
shortcomings of the  label withdraw signaling method currently in the control 
WG document.

I do not agree with the negotiation part, but I think that the status TLV has 
merit, and we should use the ignore bit for backward compatibility, in addition 
to a setting that would use the old label withdraw method. (but this is an 
implementation detail).

I would like to keep this thread concise to this status TLV problem , and 
actually conclude it quickly.

Thanks.
Luca

----------------------
6. Signaling of Pseudo Wire Link Errors

    The signaling mechanisms described in the sections above provide
    at most a coarse-grained notion of the remote PW's forwarding
    state (via withdrawal of the PW label).  However, the use of PW
    label withdrawal to connote interface state has two shortcomings:
    first, its use is inconsistent among interface types; for example,
    Ethernet VLAN PWs use label withdrawal to indicate CE interface
    operStatus events, whereas ATM VCC PWs do not.  Second, when label
    withdrawal is used, it often conveys insufficient information about
    the type of event that instigated the label withdrawal; it may be
    due to an unexpected PE-CE interface failure event, for example, or
    due to a planned operator change to the PE's configuration.

    This section details an optional signaling mechanism which augments
    the mechanisms described in the sections above and conveys more
    detailed information about pseudo wire link errors.

6.1 Negotiation of Signaling Method

    To maintain backward compatibility with baseline PW signaling
    implementations, use of pseudo wire link error (PWLE) signaling
    is negotiated between the two PW peers.  If either peer does
    not support the use of PWLE signaling then baseline signaling
    behavior, as described in the above sections, MUST be utilized.

Martini, et al.                                                [Page 13]

Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    December 2002

    A PE indicates its desire to utilize PWLE signaling by setting the
    P bit in the VC Type field to 1, and immediately signaling its PW
    label to its peer, regardless of the CE-facing interface's
    operational status.  The negotiation procedure detailed in Appendix
    A MUST be followed to determine the state of the P bit for the PW.

    Once negotiation of the value of the P bit is complete, the PE
    determines its signaling behavior.  If the P bit is not set after
    negotiation, the baseline signaling behavior described in the
    sections above MUST be used.  If the P bit is set after
    negotiation, the signaling mechanisms described below MUST be
    used.

6.2 Use of Label Mappings in PWLE Mode

    When both peers signal their willingness to participate in PWLE
    mode, the use of label mappings and label withdraws differs
    slightly from the baseline signaling.  When in PWLE mode, PEs MUST
    send PW label mapping messages to their peers as soon as the PW is
    configured and administratively enabled, regardless of the CE
    interface state.  The PW label MUST NOT be withdrawn unless the
    user administratively configures the CE interface down (or the PW
    configuration is deleted entirely).

6.3 Signaling PW Link Errors in PWLE Mode

    When PWLE mode is in use, the PE devices use a new LDP TLV to
    indicate status to their remote peers, instead of withdrawing their
    PW FEC labels.  This Link Status TLV contains more information than
    the simple Label Withdraw message used in the baseline signaling.

    The format of the Link Status TLV is:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|0|   Link Status (0x0700)    |      Length                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Status Code           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Where status is a 2 octet bit field:

     0x0001 - Pseudo Wire Not Forwarding
     0x0002 - Local Customer-facing Interface Receive Error
     0x0004 - Local Customer-facing Interface Transmit Error
     0x0008 - Local Core-facing Interface Receive Error
     0x0010 - Local Core-facing Interface Transmit Error

    The presence of the lowest bit (PW Not Forwarding) acts only as a
    summary of the other bit fields, or to convey a link-down event for
    which none of the other bits apply.

    The Link Status TLV is transported to the remote PW peer via a new
    LDP message, the PW Link Status Message.

Martini, et al.                                                [Page 14]

Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    December 2002

    The format of the PW Link Status Message is:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|   PW Link Status (0x0700)   |      Message Length           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Message ID                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           PW FEC TLV                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Link Status TLV                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Optional Parameters                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The rationale for using a new LDP message type instead of resending
    the PW FEC label mapping with an enclosed Link Status TLV is
    twofold: first, when updating PW link status, there is no need to
    convey actual label mapping information, and use of the Label
    Mapping message requires the inclusion of a Label TLV.  Second, and
    more importantly, when a PE's CE-facing interface encounters an
    error, use of the new message allows the PE to send a single Link
    Status message, using a PW FEC TLV with only the group ID set, to
    denote this change in status for all affected PW connections.  The
    use of a PW FEC TLV with only group ID set is undefined for use in
    Label Mapping messages.

---

From: "Mark Seery" <[email-masked]>
Date: Mon, 9 Jun 2003 22:15:17 -0700

Hi Luca,

>> Luca: I do not agree with the negotiation part, but I think that the
status TLV has merit, and we should use the ignore bit for backward
compatibility, in addition to a setting that would use the old label
withdraw method. (but this is
an implementation detail)....<<

Not sure I understand your comment.

The following specifies a way to indicate that the old label withdraw method
is indicated (though could be more explicit I suppose) "If the P bit is not
set after negotiation, the baseline signaling behavior described in the
sections above MUST be used.  If the P bit is set after negotiation, the
signaling mechanisms described below MUST be used. "

So is your comment simply that you agree with this, but "ignore bit" should
be used in addition?

========

In addition....

Not sure if you were looking for feed back on status codes, but........for
the sake of those that come after us, I find the terms a little confusing.
Clearly by the title of the section there is an intent to signal PW link
errors, but also an indication to signal link status, as denoted by the TLV
name. So maybe two different concepts got mixed up in one mechanism or
perhaps I am just being pedantic, but it would seem that a link error and a
link status are not the same thing.

For example, one might expect a link status to be: up, down, initializing,
quiescing (sp?), forwarding, blocked, whatever.....whereas "Local
Customer-facing Interface Receive Error" seems more like an event, a
counter, or a reason code for a status code.

Now I suppose the setting of the lowest bit is a "status code" of types (the
summary comment not withstanding), and if forwarding/not forwarding are the
only two states a link can be in, then that is fine. If a link can be in
other states, seems like a more generalized format might be useful for the
long term/or the TLV should be called something like "Link Error TLV"
instead.

In addition, I would be interested to know if operators would like
information on the type of link error, and if yes, maybe a field where
vendors can place a description code.

Mark

---

From: David Zelig <[email-masked]>
Date: Tue, 10 Jun 2003 09:18:07 +0200

Luca,

> -----Original Message-----
> From: Luca Martini [mailto:[email-masked]]
> Sent: Monday, June 09, 2003 9:01 PM
> To: [email-masked]
> Subject: [PWE3] status signalling of MPLS PW state
> 
> 
-+-+-+
>     which none of the other bits apply.

I think additional status of "Local Customer-facing Interface
Administratively Down" is required: While the peer should not send traffic,
it is preferred not to report a red alarm in this case.

In addition to Local Core-facing Errors, a more general error would be the
inability to send/receive traffic due to a failure of the outer tunnel (it
may fail also due to mid-network conditions and has the same effect as core
facing interface failure). Maybe an indication of "Core side Receive Error"
and "Core side Transmit Error" instead (or in addition) are required.

For terminology, I believe the term "failure" is more suitable than "error",
since an error on physical interface is usually related to a temporary event
while failure is declared after an error is persisted for pre-defined time
window.

David

---

From: "Himanshu Shah" <[email-masked]>
Date: Tue, 10 Jun 2003 09:22:56 -0400

Luca,

I am glad that you have recognized the need for 
conveying the link status as compared to withdrawing
the VC-LABEL for the same and Toby has good 
proposal.

However, I would like PWE3 to approach this slightly
differently as described in
draft-shah-pwe3-control-protocol-extension-00.txt.

We need a +generic mechanism+ to relay "dynamic
attributes" of the PW, including the status of the AC (and
yes, it should be AC or PW status as compared to link status).
The generic mechanism can then be used to extend
control signaling without having to constantly change
the base draft. 

The extension draft proposes that such PW attributes
be included in "optional parameter" field of the Label
mapping message. The advantage of this approach is,

1) conveying of one or more dynamic attributes in a 
     single label mapping message. Extension draft describes
     IP addr (needed for ARP-mediation) , IP+MAC addr (needed
     for IPLS), QOS, tunnel mechanisms used, etc TLVs.
2) a way to include these attributes in first mapping msg
     as compared to a follow-on status msgs (for example,
     PE does not know the status of the remote AC until
    link status msg follows the initial label mapping msg)
3) allows update of the attributes. When dynamic attribute
    changes, an update is sent without withdrawing the VC-FEC
4 ) allows definitions of new attributes without 
      modifying base LDP or martini signaling draft

I would like PWE3 to consider this approach.

/himanshu
wavesmith networks

> Sent: Monday, June 09, 2003 3:01 PM
> To: [email-masked]
> Martini, et al.                                               
>  [Page 13]
> > 
> Martini, et al.                                               
>  [Page 14]
> > 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: "David Allan" <[email-masked]>
Date: Tue, 10 Jun 2003 09:59:16 -0400

Hi:

I think there is a few things not being considered.

1) Not clear that it is useful to negotiate support on a per-PW basis.
Presumably peers learn node behavior and carry it forward for subsequent
transactions. So what is learned from the first PW mapping attempt should be
sticky.

2) Upon a restart of a peer, it may be due to a software upgrade, so
behavior needs to be re-learned. 

3) If negotation is part of a label transaction, and it occurs regardless of
the status of the attachement circuit, some unlucky PW may get to be set up,
discover the far end does not support status signalling, and get promptly
torn down again. If during a restart, you are trying to do multiple
mappings, this can be very messy esp if somthing like an ATM OC3 is down
with thousands of VCCs mapping to PWs and that is the first mapping
communicated between peers. 

4) Although status signalling is a unique requirement of PWs (IP uses
routing), I do not quite undestand the prohibition from negotiating support
at LDP session establishment. Seems to avoid a lot of race condition. The
only wrinkle being some ACs for which status may not apply at the present
time.

5) The reason code needs some extensions:
	- administratively down
	- loss of peer control plane
	- phy down
	- virtual interface (e.g. VCC/DLCI) down

cheers
Dave

> From: Himanshu Shah [mailto:[email-masked]] 
> Sent: Tuesday, June 10, 2003 9:23 AM
> To: Luca Martini; [email-masked]
> Subject: RE: [PWE3] status signalling of MPLS PW state
> 
> 
> Luca,
> 
> yes, it should be AC or PW status as compared to link 
> status). The generic mechanism can then be used to extend 
> control signaling without having to constantly change the base draft. 
> 
> > > > 
> > > > 
> >     |                           Message ID                  
>         |
> >     |                           PW FEC TLV                  
>         |
> >     |                         Link Status TLV               
>         |
> >     |                      Optional Parameters              
>         |

---

From: "Himanshu Shah" <[email-masked]>
Date: Tue, 10 Jun 2003 11:28:34 -0400

I agree. The capability negotiation should be nodal.
The shah-extension draft is backward-compatible with
base signaling draft and does not require any capability
exchange.
 
/himanshu

-----Original Message-----
From: David Allan [mailto:[email-masked]]
Sent: Tuesday, June 10, 2003 9:59 AM
To: Himanshu Shah; Luca Martini; [email-masked]
Subject: RE: [PWE3] status signalling of MPLS PW state

Hi: 

1) Not clear that it is useful to negotiate support on a per-PW basis. Presumably peers learn node behavior and carry it forward for subsequent transactions. So what is learned from the first PW mapping attempt should be sticky.

2) Upon a restart of a peer, it may be due to a software upgrade, so behavior needs to be re-learned. 

3) If negotation is part of a label transaction, and it occurs regardless of the status of the attachement circuit, some unlucky PW may get to be set up, discover the far end does not support status signalling, and get promptly torn down again. If during a restart, you are trying to do multiple mappings, this can be very messy esp if somthing like an ATM OC3 is down with thousands of VCCs mapping to PWs and that is the first mapping communicated between peers. 

4) Although status signalling is a unique requirement of PWs (IP uses routing), I do not quite undestand the prohibition from negotiating support at LDP session establishment. Seems to avoid a lot of race condition. The only wrinkle being some ACs for which status may not apply at the present time.

cheers 
Dave 

> From: Himanshu Shah [ mailto:[email-masked]] 
> > From: Luca Martini [ mailto:[email-masked]]

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Tue, 10 Jun 2003 11:29:48 -0400

Mark,

> vendors can place a description code.

I agree. It is beneficial to know the nature of the error. Something
like diagnostic code-description needs to be supported.

Hamid.

---

From: Luca Martini <[email-masked]>
Date: Tue, 10 Jun 2003 18:03:49 -0600

> Not sure I understand your comment.
not having a label mapping means that the PW has not yet been configured , 
which is almost equivalent to saying it is down. I think that we can say that 
if the label mapping is withdrawn , the PW is down for backward compatibility.

So should new implementations not be required to do a label withdraw ?
I think yes. and an optional feature could be to also support configuration of 
the old method.

> So is your comment simply that you agree with this, but "ignore bit" should
I was not clear.
I think that the negotiation is an unnecessary complication.
I think that the ignore bit should be set so that we remain compatible with old 
martini implementations ( save for the status signaling ).

> link status are not the same thing.

yes I think that I might have to reword this somewhat.
let us  call this link failure, and remove the error references.
I still think that this is a status message as in the LDP status message 
definition (rfc3036).

> vendors can place a description code.
I'll think about it.

Luca

---

From: "Mark Seery" <[email-masked]>
Date: Tue, 10 Jun 2003 21:38:42 -0700

Hi Luca,

[snip]
>>> I still think that this is a status message as in the LDP status message
definition (rfc3036). <<

If this is an advisory notification associated with a previous
message/notification, then I agree it meets the definition specified in the
LDP spec. (3036). So in the context of say a previous link error
notification, then calling it a link status TLV makes sense, WRT to 3036
definition. However, the question I would ask is if sometime in the future
(if not already in existance) we wanted to create a "status" message in
response to a link state change event/notification, what would that TLV be
called. Perhaps it can be the same thing.

So understand you are operating within the context of 3036, and the
terminology it uses.

Best,
Mark

---

From: Shahram Davari <[email-masked]>
Date: Wed, 11 Jun 2003 08:16:48 -0700

Where is the P-bit defined?

-Shahram

---

From: Luca Martini <[email-masked]>
Date: Wed, 11 Jun 2003 11:02:29 -0600

Shahram,

It is not, this is just a starting point.
P means "i want to use the status TLV"
I don't think it is necessary.
I'll send revised text soon.

Luca

---

From: Luca Martini <[email-masked]>
Date: Wed, 11 Jun 2003 11:07:54 -0600

Mark,

There are a couple of reasons: the remote PE probably want to take action to 
notify the attached CE that the PW is broken.( Frame ILMI in the NNI case, or 
ATM OAM if the PW is broken , but the control plane still works )
the PE might want to take such action as attempting to bypass the issue  maybe 
by using an alternate route or PW.
Also the remote PE might want to keep track of how long the PW is in the down 
state.

Luca

Mark Seery wrote:
> Thanks Hamid.
> 
> I agree as a general principle it is good to know why
> an error has occurred. But in mulling this over since
> I first wrote it, it occurs to me that it might depend
> on where/why the error is communicated.
> 
> For example, the full link error information could be
> communicated via the management plane - if an operator
> really needs to know. I guess the real question is why
> is the control plane being asked to communicate this
> information from one LDP peer to the other. Is it
> because it expects the LDP peer to take some action?
> If so, then simply knowing there has been an
> error+forwarding status might be enough. If the extra
> information can not be used by the control plane, then
> it probably doesn't make sense to carry it around, we
> are just complicating the implemenation.
> 
> Bottom line is I am not sure I understand what the
> intended consequences/actions are of the LDP peer
> receiving this information, so now not sure what is
> sufficient information or not.
> 
> Perhaps Luca could give some background, or perhaps it
> is simply an implementation decision what to do with
> the new knowledge that the other end of a PW has
> experienced a failure.
> 
> mark
> 
> --- Hamid Ould-Brahim <[email-masked]>
> wrote:
> 
>>Mark,
>>
>>
>>>In addition, I would be interested to know if
>>
>>operators would like
>>
>>>information on the type of link error, and if yes,
>>
>>maybe a field where
>>

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Wed, 11 Jun 2003 13:20:24 -0400

Luca,

> Let's make the distinction between reporting an error  to the
> operator , and
> the need to send the specific cause in the protocol.
> There is no doubt that the nature of the error has to be
> reported to the
> operator, but the specifics need only be reported by the PE that is
> experiencing the problem.
>
> So for example , as PW might be down because the local PE is
> out of buffer
> memory. The message to the remote PE can simply be     0x0001
> - Pseudo Wire Not
> Forwarding.
> Yet the message sent, by the local PE, as a SNMP trap or to
> syslog, can be
> "Pseudo Wire Not Forwarding out of buffer memory".
>

Yes. But I think there may be other reasons that can help the
remote PE to make some policy decisions. For example ability to 
trigger a backup scenario for some type of reasons compared to others
(for resiliency purposes). Reasons can be link/port failure,
administrative operation, protocol down (if any is used between ce-pe), 
etc.
 
Besides, although not explictely mentioned in the draft, there were some 
additions to the control draft before that were motivated by the
ability to support SVC (dynamic PW) case (among other reasons). 
I assume for these types as well a reason maybe required by the 
protocol used in signaling.
 
Hamid.

> There is an assumption here that some operator will monitor
> both sides.
>
>
> Luca
>
>
>

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Wed, 11 Jun 2003 13:22:23 -0400

Mark,

> on where/why the error is communicated.

Yes.

> are just complicating the implemenation.
 
But if there is another way to make a PE communicate
with remote PE then other information can as well be
communicated outside the signaling scheme (such as encaps, 
etc). It looks to me that since status is conveyed through 
the signaling then maybe it is preferable/logical to convey the 
reason for that particular status report using the same vehicle. 
 
Not sure it really complicates that much the implementation 
besides indicating the nature of the error. 
 
In general it looks to me it is beneficial to have such
description now while we are discussing the status tlvs....
but I join your call for operators to indicate their 
opinion/preference on this item...
 
Hamid.

---

From: Shahram Davari <[email-masked]>
Date: Wed, 11 Jun 2003 10:37:49 -0700

Hamid,
 
It is the operator not the PEs that needs to know the reason for failure. 
The NMS is the proper place to communicate such information. All a PE
wants to know is whether the other PE could receive and forward the
traffic or not.
 
-Shahram

-----Original Message-----
From: Hamid Ould-Brahim [mailto:[email-masked]]
Sent: Wednesday, June 11, 2003 1:22 PM
To: Mark Seery
Cc: [email-masked]; Luca Martini
Subject: RE: [PWE3] status signalling of MPLS PW state

Mark,

Yes.

 

Hamid.

---

From: "Lin, Zhi-Wei" <[email-masked]>
Date: Wed, 11 Jun 2003 13:59:28 -0400

So in the case of a failure, how much information are you envisioning need
to be carried (e.g., details per LSP?), and how often would this information
be propagated (periodically, event driven?)?
 
Zhi

-----Original Message-----
From: Hamid Ould-Brahim [mailto:[email-masked]]
Sent: Wednesday, June 11, 2003 1:22 PM
To: Mark Seery
Cc: [email-masked]; Luca Martini
Subject: RE: [PWE3] status signalling of MPLS PW state

Mark,

Yes.

 

Hamid.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 11 Jun 2003 13:59:19 -0400

Luca,

I would like to agree with Himanshu's message.

To tell you the truth, I was a bit surprised to your message proposing 
Toby's text for status signaling.  I was under the impression (perhaps 
mistaken?) that WG consensus had already been determined to accept 
draft-shah-pwe3-control-protocol-extension-00.txt and that it was in the 
process of being incorporated into the main control signaling draft.

I certainly agree that one or the other is needed, and if I had to choose 
between them, the Operational Status TLV is certainly easier to implement 
and less disruptive to existing LDP implementations than the PW Link Status 
Message.  Is there a really good reason why the Operational Status TLV 
can't work?

I saw Toby's comment about only using the group ID to reflect interface 
outages, but that's only useful if you have multiple parallel PWs between 
the same two logical interfaces at the edge of the network (they have to 
share the same LDP session), which isn't going to be all that common.  I 
can tell you from experience in large FR and ATM networks that end-to-end 
status signaling on a per-VC (per-PW in our case) basis works just fine, 
even when you have interface outages.

Are there any other reasons?

Thanks,
Andy

---------

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Wed, 11 Jun 2003 16:33:45 -0400

Zhi,

Propagated when operational status changes. Not that much information 
either a code indicated the reason or fine grained status codes (up to
operators to indicate their preference)...
 
Hamid.
 
 Zhi

-----Original Message-----
From: Hamid Ould-Brahim [mailto:[email-masked]]
Sent: Wednesday, June 11, 2003 1:22 PM
To: Mark Seery
Cc: [email-masked]; Luca Martini
Subject: RE: [PWE3] status signalling of MPLS PW state

Mark,

Yes.

 

Hamid.

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Wed, 11 Jun 2003 16:39:31 -0400

Shahram,

It is the operator not the PEs that needs to know the reason for failure.   
 The NMS is the proper place to communicate such information.  
 
NMS is fine (particularly reporting the reason
for the PE experiencing the problem).
 
 All a PE wants to know is whether the other PE could receive and forward
the
traffic or not. 
 
My question/suggestion for operators is whether it is desirable
to indicate to the remote PE the reason of the failure in
case the operator had previously put some policies for
taking specific actions  depending on the reason for
a particular status type (an example I can think of is the case 
where a backup pw is/is not triggered).
 
Hamid.

-Shahram

-----Original Message-----
From: Hamid Ould-Brahim [mailto:[email-masked]]
Sent: Wednesday, June 11, 2003 1:22 PM
To: Mark Seery
Cc: [email-masked]; Luca Martini
Subject: RE: [PWE3] status signalling of MPLS PW state

Mark,

Yes.

 

Hamid.

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Wed, 11 Jun 2003 16:48:40 -0400

Andy,

[clipped]...

>
> I certainly agree that one or the other is needed,

How about both proposals to be merged (when possible/applicable)?

Hamid.

>  <https://www1.ietf.org/mailman/listinfo/pwe3>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 11 Jun 2003 17:22:30 -0400

Hamid,

Well, they're really two alternative ways to extend LDP to convey the same 
information.  The only way to really merge them would be to support them 
both ....

Thanks,
Andy

---------

---

From: Luca Martini <[email-masked]>
Date: Wed, 11 Jun 2003 17:06:18 -0600

> process of being incorporated into the main control signaling draft.
actually most of that draft belongs in PPVPN. I had only agreed to consider it 
, and WG feed back was that it is a good idea to have such mechanisms.

lot's of reasons where in the text that I posted earlier.

> I certainly agree that one or the other is needed, and if I had to 
> choose between them, the Operational Status TLV is certainly easier to 
> implement and less disruptive to existing LDP implementations than the 
> PW Link Status Message.  Is there a really good reason why the 
> Operational Status TLV can't work?
> 
> outages, but that's only useful if you have multiple parallel PWs 
> between the same two logical interfaces at the edge of the network (they 
> have to share the same LDP session), which isn't going to be all that 
> common.  I can tell you from experience in large FR and ATM networks 
> that end-to-end status signaling on a per-VC (per-PW in our case) basis 
> works just fine, even when you have interface outages.
> 
Actually back in the san diego IETF there was a strong request for the group ID 
mechanisms for large NNI to NNI applications.
the down notification had to be immediate for 10000 PWs.
One other issue is that we would like to limit what goes into this message. 
There is a very limited set of useful failures at the PW abstraction layer.
The TLVs proposed in draft-shah-pwe3-control-protocol-extension-00 are useful 
and need to be included where most appropriate.
Operational state in not a FEC, this is why I did not put this in the interface 
parameters..

Thanks.
Luca

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 12 Jun 2003 10:36:03 +0200

Andy and Luca,
I support Andy's position.
Please see also additional comments inline.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> From: Andrew G. Malis [mailto:[email-masked]]
> Sent: Wednesday, June 11, 2003 7:59 PM
> To: Luca Martini
> Cc: [email-masked]
> Message.  
IMHO, adding a new message to LDP would require involvement of the MPLS WG.
>
> Is there a really good reason why the Operational Status TLV 
> can't work?
>
I think that the Operational Status TLV in LDP and the 
Circuit Status AVP in L2TPv3 serve exactly the same purpose
and hence should carry the same information. Currently there
are some minor differences.
I also agree with Himanshu that ability to signal the attachment 
circuit status at the PW establishment is important. 
>
> I saw Toby's comment about only using the group ID to reflect 
> interface outages, but that's only useful if you have multiple parallel 
> PWs between the same two logical interfaces at the edge of the network 
> (they have to share the same LDP session), which isn't going to be all
that 
> that end-to-end status signaling on a per-VC (per-PW in our case) basis
works 
> just fine, even when you have interface outages.
> 
Does not the same logic apply to "wild card withdrawal" of PW labels based
on Group ID as presented in Section 5.1 of
draft-ietf-pwe3-control-protocol-02.txt?

---

From: David Zelig <[email-masked]>
Date: Thu, 12 Jun 2003 11:38:06 +0200

Luca,

> Sent: Thursday, June 12, 2003 1:07 AM
> To: [email-masked]
> Subject: Re: [PWE3] status signalling of MPLS PW state
> 
> 
> Latest text, including some of the feedback.
> 
> .Pb "Signaling of Pseudo Wire Link Status"
> 
> .Pc "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 interface
> state. The PW label should not be withdrawn unless the user 
> administratively
> configures the CE interface down (or the PW configuration is deleted
> entirely).
> A simple label withdraw method SHOULD also be supported as an 
> alternative.
> 

Can you elaborate why CE facing user admin down you make a withdraw and not
a status report? 

The PW has it's own admin status so if you want to force withdraw (without
deleting the configuration) you can do it directly at the PW level. I
believe it is good to separate the PW and CE admin status since you may want
to administratively close the physical port while keeping the resources at
the PW level. If there is operational need a combined administrative status
to make both operations at once we can easily add it to the PW-MIB.

David

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Thu, 12 Jun 2003 09:40:57 -0400

Luca,
 
Additional comments inline...

>     The format of the Link Status TLV is:

I think it should be clarified that initially the PW should not forward
packets until the link status message is received. The way I read the
above (particularly the semantics for code points) is initially the PW 
is enabled and forwarding (just by receiving the label mapping) and an
operational change can happen upon receiving a link status (could you
clarify 
that. Thxs). 
 
I would have assumed that the logical behavior is initially the PW 
should be up (by keeping the label) but not in forwarding state 
*until* it receives a favorable status. In Himanshu's proposal
the "not favorable status" can be communicated initially while the label is
sent giving time for the pw to react well before receiving the
link status message.
 
I think it is important for the pw/pe to know the operational 
status *before* forwarding packets (this is valid for when pw is
configured).
 
A different comment requiring clarification, it seems the codepoint 
are just indicating problems. I think the remote end should as well
receive codepoints that clear the problems (or some of
the problems). I assume this is done through clearing the bit fields. 

>     LDP message, the PW Link Status Message.
 
In fact the only case where the link status is effectively conveyed
is when a group id is used (associated to that link). I suggest
to rename that Link Status TLV to something reflecting both
the pw/ac/interface/links/groups (maybe something along
the lines of "PW status TLV", or "PE-side-PW status tlv", etc).

>     The format of the PW Link Status Message is:
 
Why include the whole PW FEC TLV with its interface parameters, PW type,
etc...

>     use of a PW FEC TLV with only group ID set is undefined for use in
 
The other issue is we know there are two FEC TLVs (exclusive). I assume 
the case described here relates to the PWid FEC (with its PW ID field).
 
In the case of Generalized ID FEC, there is no group_id field
(unless the AGI  field is used and is associated to the link)...but if 
it is an l2vpn, the most likely use of AGI will be to include a VPN-ID or 
global unique id representing the VPN membership of all the CEs
(participating
in that VPN). In that case, the link status TLV used for the
group ID (style) won't work (unless the Generalized ID
FEC will include another group_id field and a given vpn configured
on a PE will be associated with one or many group-ids/ports...).
This will require changing the generalized id fec...if not then the value
of a separate status message is diminished in l2vpn case.
 
I would like to see the status tlvs to work for both generalized id
fec and PWid fec, and obviously should work for l2vpn cases.
 
Aside: Why not have a separate draft for addressing operational 
status/link errors since this is optional for pw...
Is it because the P bits (which we still are waiting to
see it) is used in the vc type...
 
Hamid.

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Thu, 12 Jun 2003 11:00:51 -0400

Andy,
 
I meant given that now we have two solutions addressing
the status problem from a different angle, and clearly there
are issues/areas of discussions in both proposals.
 
My suggestion is instead of selecting and incorporating one 
solution in the pw control draft, and then debating in the
mailing list whether we agree on the problem
and how are we solving it, why not first take these two proposals,
work out a new draft (separate from the current control draft),
state the problem, address the requirements and then describe a 
solution that meets these requirements taking into account
items in both proposals. 
 
If at the end of the day we end up with exactly Luca/Toby's or 
Himanshu's proposal or something in between that is fine but at least
the wg will have the confidence the proposal actually satisfies the 
requirements, and addresses most of the issues raised (and
the whole wg will be winning at the end...).
 
Hamid.

Hamid,

Thanks,
Andy

---------

Andy,

[clipped]...

Hamid.

---

From: "Himanshu Shah" <[email-masked]>
Date: Thu, 12 Jun 2003 11:12:43 -0400

I will furnish the text for use of each TLV.

Note that not all TLVs are suitable for "update"
mechanism. For example, QOS TLV.  It is best
that these parameters are provided at the time
XC is programmed in the FIB and not after.

We need a +generic+ mechanism to allow
extensions without requesting changes in the base draft.

Also, I am not convinced if it is necessary to convey the
the reasons for "link down" to remote PE. I don't
believe it is useful information as such. 

The problem is, for instance, if the link and/or PW is down,
and notified, but the reasons have changed, should PE keep
notifying the change of these reasons?

/himanshu
wavesmith networks

> Sent: Wednesday, June 11, 2003 7:03 PM
> To: Andrew G. Malis
> Cc: Hamid Ould-Brahim; [email-masked]
> I read the following TLVs in the 
> draft-shah-pwe3-control-protocol-extension-00.txt :
> 
> Operational Status TLV
> IP Address TLV
> IP+MAC Address TLV
> Pseudowire QOS TLV
> 
> 
> I think most of these are needed , but they need not all be 
> part of the FEC.
> There are several bits available in the status TLV proposal, 
> can you please 
> specify what the use should be, and I can add it.
> ( please note that the draft-shah does not propose much in 
> the area of status )
> 
> Thanks.
> Luca
> 
> 
> 
> 
> Andrew G. Malis wrote:
> > Hamid,
> > 
> > Well, they're really two alternative ways to extend LDP to 
> convey the 
> > same information.  The only way to really merge them would 
> be to support 
> > them both ....
> > 
> > Thanks,
> > Andy
> > 
> > ---------
> >

---

From: "Himanshu Shah" <[email-masked]>
Date: Thu, 12 Jun 2003 11:26:17 -0400

comments in line...

> Sent: Wednesday, June 11, 2003 7:06 PM
> To: Andrew G. Malis
> Cc: [email-masked]

Himanshu> Actually none of the draft-shah-pwe3-control-protocol-extension-00.txt 
belongs to PPVPN. It is all related to signaling attributes of the PW.

The main purpose of the draft is also to propose a mechanism
which allows future extensions in backward compatible 
fashion without having anybody to keep requesting the changes in
the base draft.

> The TLVs proposed in 
> draft-shah-pwe3-control-protocol-extension-00 are useful 

Himanshu>
If group ID is important, operational status TLV of draft-shah 
can be extended to include group ID with a group ID present bit.
When present, the status is applied to the whole group.

regards,
himanshu

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Thu, 12 Jun 2003 11:41:15 -0400

David,

[clipped]...

> Can you elaborate why CE facing user admin down you make a 

I am as well interested to know why a user admin down/change
implies withdrawing the label.

> the PW level. 

Agreed.

Hamid.

>If there is operational need a combined 
> administrative status

---

From: "Himanshu Shah" <[email-masked]>
Date: Thu, 12 Jun 2003 11:54:47 -0400

Also, note that draft-shah is backward compatible
where capability of the remote peer is auto-learned
based on presence/absence of operational status TLV
in the initial label mapping message.

/himanshu
wavesmith networks

> From: Himanshu Shah 
> Sent: Thursday, June 12, 2003 11:13 AM
> To: Luca Martini; Andrew G. Malis

---

From: Luca Martini <[email-masked]>
Date: Thu, 12 Jun 2003 16:09:21 -0600

ooops.
this is a typo. it should say PE.
the text "the CE interface down" should read "the CE facing interface down"

This is equivalent to removing the configuration.
We could remove this text , it was just here for clarification.

Luca

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 12 Jun 2003 15:01:47 -0400

Having caught up on this email thread, I'm ready to agree that both 
mechanisms are necessary - the Operational Status TLV to carry end-to-end 
status signaling from and to LMI/ILMI/PVC status signaling at the 
endpoints, and the PW Link Status Message to reflect interface and PW 
outages.  I also agree with David that in a "PVC" environment labels should 
only be withdrawn when the PW is administratively destroyed (the LERs/PEs 
have been instructed to release the resources associated with the PW).  In 
an "SVC" environment, labels would be withdrawn as a result of a signaled 
CLEAR from the CE.

Thanks,
Andy

--------

---

From: Luca Martini <[email-masked]>
Date: Thu, 12 Jun 2003 17:47:19 -0600

Today's revision has the following fixes:

- replaced CE with CE-Facing
- PW FEC should not contain interface parameters
- faults can be cleared by clearing respective bits.

Outstanding issues:
- TLV value needs coordination/lookup appropriate one.

- how to make this work better with label withdraw mode.
- Ignore Bit: should it be set ?

Other points :

- I really would like not to have this be flexible to allow an infinite amount 
of status messages allocated without WG study and RFC update and proper 
documentation.

- the "let's split it because we can't agree" method has been exhausted. I do 
not believe that there is much support for creating any more drafts from splits.

- can somebody enumerate any faults that are not included here , that a PW can 
experience ?

In general we initially reserved the PW FEC, and interface parameters, for PW 
specific information , that would not change, and if incompatible it would 
cause an error and the PW would not be enabled.
Special information such as IP addresses, and QoS congestion messages, Qos 
requests ..etc that CAN change once the PW is operational need to be in a 
different message. NOT a label mapping message ! We could call this message a 
PW dynamic parameter ( or some better name, below called the PW link status 
message ) and this is mostly what is in draft-shah. The status of the PW should 
be a TLV in this message. OTher TLVs will specify other proprieties of the PW.
we then spec the status TLV, and message in this draft , and the other TLVs 
elsewhere.

This thread is very constructive , thanks for all the reading and comments.

Luca

this is today's version, tomorrow will definitely be different .....

.Pc "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).
A simple label withdraw method SHOULD also be supported as an alternative.

.Pc "Signaling PW Link status."

.DS 0 0
.DE

.nf
0x0000 - Pseudo Wire forwarding ( clear all failures )
0x0001 - Pseudo Wire Not Forwarding
0x0002 - Local Customer-facing Interface Receive Fault
0x0004 - Local Customer-facing Interface Transmit Fault
0x0008 - Local Core-facing Interface Receive Fault
0x0010 - Local Core-facing Interface Transmit Fault
.En

The above status codes can be logically combined to indicate more then a
single failure at once. Each fault can be cleared by sending an appropriate
status message with the respective bit cleared.

The presence of the lowest bit (PW Not Forwarding) acts only as a
generic failure indication when there is a link-down event for
which none of the other bits apply.

.DS 0 0
  0                   1                   2                   3
.DE

The PW FEC TLV SHOULD not include the interface parameters as they are
ignored in the context of this message. When a PE's CE-facing interface
encounters an error, use of the new message allows the PE to send a single
Link Status message, using a PW FEC TLV with only the group ID set, to
denote this change in status for all affected PW connections.

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Thu, 12 Jun 2003 15:34:38 -0400

Himanshu,

> in the initial label mapping message.

Since we are debating this topic here are some comments
as well on your draft.

>"4.1 Operational Status TLV 
>    
>   The Operational Status TLV is used to notify the remote PE peer 
>   about the change in operational status of the attached circuit or 
>   the tunnel carrying the PW. The exchange of this information is an 
>   alternative to the current practice of withdrawing the PW label for 
>   such circumstances.  
>    
>       0                   1                   2                   3 
>      |1|0| Status TLV  (TBD)         |      Length                   | 
>      |        type                   |           status              | 

If a given PE doesn't understand status TLV and receives the status TLV
from another PE mentioning "down", given that the U bit is set to 1 that 
PE will ignore the status TLV. The question is what should the sender PE do:
 
- Assume that the remote PE doesn't intend to use Status TLV 
  (by virtue of receiving a reverse label mapping with no
  status TLV included) and decides to accept the label, and follow 
  normal PW procedure with no status TLV. I have assumed this
  the case for your draft. or
 
- keep the label and wait for the remote PE to send the status TLV...
 
or just
 
- withdraw the label
 
It looks to me if a PE sends the status "down" it expects
the receiver to react to that...Why not give the choice for the PE 
to impose whether the Status TLV is mandatory or not. 
 
Now assume the other case, a PE understands status TLV but it
received a normal label mapping (with no status tlv) from a given PE.
It concluded that the remote PE doesn't understand status TLV while
in fact the remote PE didn't include it. Should the draft impose that
if a PE supports status TLV therefore it MUST include it in
the label mapping (basically that is the default behavior).
If it is not a must, what will be the behavior 
for both sender and receiver when a given PW is up through normal 
procedures and then the operator configures that status TLV needs 
to be sent?
 
I think sending the status per label mapping
(pw) basis (initially) for each PW even when the remote PE
doesn't support the status TLV has an impact on cpu cycles
for the sender (the status TLVs will end up being ignored 
anyway). I think in that case negotiation or capability advertisement 
can be useful done at the PE/session levels.
 
>     16-bit value is used to identify the interface type. A value of 1 
>    means operational status is for the attachment circuit. A value of 
>     2 means that operational status is for the unidirectional portion 
>     of the PW that spans from advertising PE to the receiving PE. 
 
If I have more than one status to convey I assume the label mapping will
carry multiple status TLVs. Since the above text indicates two types,
why not have in a single status TLV both types and values
conveyed. 

>   Status 
>     16-bit value specifies the operational status. A value of 0 means 
>     that AC or PW is down or inactive while a value of 1 means that AC 
>     or PW is up or active. 
 
Why 16 bits are needed while only 0 and 1 values have effective meanings
(up/down)? 

>      
>   The absence of status TLV in optional parameter of Label Mapping 
>   message for the VC-FEC must not be interpreted as status down. 
 
Does the absence of status TLV interpreted as the remote
PE doesn't support/intend to use status TLV?
 
>In 
>   fact, PEs should assume operational status of the remote attachment 
>   circuit and incoming PW as operational unless notified otherwise. 
>   The operational status down must then be followed by operational 
>   status up in order for remote PE to resume traffic. 
        
>  The sender has the responsibility to coordinate the status 
>   notifications. The receiver may or may not react to these 
>   notifications. 
 
Could you clarify what it means the receiver may or may not
react. In what scenario (as examples) the receiver may not react.    
 
Hamid.

---

From: "Himanshu Shah" <[email-masked]>
Date: Thu, 12 Jun 2003 17:41:50 -0400

-----Original Message-----
From: Hamid Ould-Brahim [mailto:[email-masked]]
Sent: Thursday, June 12, 2003 3:35 PM
To: Himanshu Shah; Luca Martini; Andrew G. Malis
Cc: [email-masked]
Subject: RE: [PWE3] status signalling of MPLS PW state

Himanshu,

 
- Assume that the remote PE doesn't intend to use Status TLV 
  (by virtue of receiving a reverse label mapping with no
  status TLV included) and decides to accept the label, and follow 
  normal PW procedure with no status TLV. I have assumed this
  the case for your draft. or
[Himanshu>] Correct. At the end of initial label exchange both PEs should know what other
is capable of and revert to default if either one is not capable of status TLV. This assumes
that both PE must include operational status TLV if they are capable of and intend to
use it in the initial label mapping msg. It determines the behaviour and remains in
force until labels are withdrawn and re-advertised which is when behaviour mode
is set based on each others capability. 

or just
 
- withdraw the label
 
It looks to me if a PE sends the status "down" it expects
the receiver to react to that...Why not give the choice for the PE 
to impose whether the Status TLV is mandatory or not. 
[Himanshu>] see above. Only when both PEs have exchanged status TLV, 
status TLVs are used subsequetly. If one is capable and other is not, they
both revert to traditional "label withdraw" mechanism. 
 
[Himanshu>] Yes. It MUST include if he is capable and intends to use it. If he is
capable but does not intend to use, both must revert to label-withdraw method. 

I think sending the status per label mapping
(pw) basis (initially) for each PW even when the remote PE
doesn't support the status TLV has an impact on cpu cycles
for the sender (the status TLVs will end up being ignored 
anyway). I think in that case negotiation or capability advertisement 
can be useful done at the PE/session levels.
[Himanshu>] I don't believe the impact is significant. Nodal capa nego is useful
but it would be new and not backward compatible 

 
Why 16 bits are needed while only 0 and 1 values have effective meanings
(up/down)? 
[Himanshu>] You are correct. They should be combined and perhaps if there
is no value to classify, there should be then only one indication up or down
irrespective of it being AC or PW. 

 
[Himanshu>] You are correct that this section needs to be clarified with respect 
to capability learning. My thinking is following,
1) PEs must exchange status in the XC building label mapping msg (initial or the one
    after the withdrawal)
2) Subsequently, PEs practice status exchange only when both are capable
3) Absence of status TLV (for that matter any other optional TLVs) in non-XC building 
    label mapping msg indicate no change in status (or other TLVs). This allows label 
    mapping msgs to be exchanged for updates of other TLVs without having to 
    include full set all the time.

 
Could you clarify what it means the receiver may or may not
react. In what scenario (as examples) the receiver may not react.    
[Himanshu>] this needs clarification too. What I mean is that sender should not
expect that remote PE will definitely stop the incoming the traffic (in contrast to
to the case if you were to use "label withdraw" method). If this was VLAN, sender
PE might be capable of GVRP (?right acronym) and receiver may not. This is fundamental 
difference between status msg exchange vs label withdraw method.
 
Thanks for the input.
Himanshu 

 
Hamid.

---

From: "Gregory Wright" <[email-masked]>
Date: Fri, 13 Jun 2003 08:01:44 -0400

which means it should also release the label it received from the remote PE
since the port has been "removed from the configuration"?

> Sent: Thursday, June 12, 2003 6:09 PM
> To: David Zelig
> Cc: [email-masked]
> > Can you elaborate why CE facing user admin down you make a withdraw 
> > and not a status report?
> > 
> > The PW has it's own admin status so if you want to force withdraw 
> > (without deleting the configuration) you can do it directly 
> at the PW 
> > level. I believe it is good to separate the PW and CE admin status 
> > since you may want to administratively close the physical 
> port while 
> > keeping the resources at the PW level. If there is 
> operational need a 
> > combined administrative status to make both operations at 
> once we can 
> > easily add it to the PW-MIB.
> > 
> > David
> > 
> 
>

---

From: "David Allan" <[email-masked]>
Date: Fri, 13 Jun 2003 09:00:24 -0400

Andy:

I also agree with this comment.

cheers
Dave

> Sent: Thursday, June 12, 2003 3:02 PM
> To: Himanshu Shah
> Cc: Himanshu Shah; Luca Martini; Andrew G. Malis; 
> Ould-Brahim, Hamid [CAR:1A00:EXCH]; [email-masked]
> > > Also, I am not convinced if it is necessary to convey the the 
> > > reasons for "link down" to remote PE. I don't believe it 
> is useful 
> > > information as such.
> > >
> > > The problem is, for instance, if the link and/or PW is down, and 
> > > notified, but the reasons have changed, should PE keep 
> notifying the 
> > > change of these reasons?
> > >
> > > /himanshu
> > > wavesmith networks
> > >
> > > > I think most of these are needed , but they need not 
> all be part 
> > > > of the FEC. There are several bits available in the status TLV 
> > > > proposal, can you please

---

From: Luca Martini <[email-masked]>
Date: Fri, 13 Jun 2003 11:52:41 -0600

Gregory Wright wrote:
> which means it should also release the label it received from the remote 
> PE since the port has been "removed from the configuration"?
> 

yes, of course.
Luca

---

From: Luca Martini <[email-masked]>
Date: Fri, 13 Jun 2003 14:40:22 -0600

David Zelig wrote:
> Luca,
> 
> The problem with setting the CE facing administrative status to down as a
> way to tear down the PW is that in case of logical attachments circuits
> (like VLAN as example) you may do not have one.

I'm not sure I understand this clearly.
Are you talking about the case when there are many VCs inside a single PW ?
that is never the case in the control draft.

> Another reason as I stated
> earlier is that the physical interface administrative status may be used
> separately from the PW administrative status.
> 
one thing that is clear is that if the interface is admined down the PW will 
not be forwarding.
Two things can happen:

1) a PW status TLV is sent out with the PW CE-facing tx and rx faults.

2) the PW is torn down, and this is looked at as an configuration event.

In either case the remote PE should take the same action.

> An EMS application has a separate admin can be used for tearing the PW. If
> an implementation want to tie it together to the physical port admin it is
> OK, but should be left for the implementer decision.
> 

I can see that port admin down == tear down is probably not a great idea.
but why do we need a separate status bit ?

What different PE-CE protocol action will the remote PE take in the case of 
admin down , as opposed to the Pw tx/rx CE-facing fault ?

> If there is an agreement on that, than there is a need in the status to
> inform about the physical port administrative status.
> 
> David
> 
I have no problem in allocating the bit , just need some arguments to defend it.
:-)

Thanks.
Luca

---

From: David Zelig <[email-masked]>
Date: Fri, 13 Jun 2003 23:15:14 +0200

Luca,

(like VLAN as example) you may do not have one. Another reason as I stated

David

> Sent: Friday, June 13, 2003 8:18 PM
> To: David Allan
> Cc: 'Andrew G. Malis'; Himanshu Shah; Hamid Ould-Brahim; [email-masked]
> Andy helped me get to the version below.
> 
> I changed to a PW status TLV , that is used in the LDP 
> notification message.
> ( it makes coding a little harder , but it's difficult to 
> justify another 
> message type. )
> Also changed the definitions of the PW faults.
> Now there are 32 bits of PW status.
> I still need to finish a iana section to allocate more bits.
> 
> any more comments ?
> 
> Luca
> .Pb "Signaling of Pseudo Wire Status"
> 
> 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). A simple label withdraw 
> method SHOULD
> also be supported as an alternative.
> 
> .Pc "Signaling PW status."
> The PE devices use an LDP TLV to indicate status to their 
> remote peers. This
> PW Status TLV contains more information than the alternative 
> simple Label
> Withdraw message.
> 
> The format of the PW Status TLV is:
> .DS 0 0
>   0                   1                   2                   3
> |1|0|     PW Status (0x0???)    |            Length             |
> Where status is a 4 octet bit field:
> 
> .nf
> 0x00000000 - Pseudo Wire forwarding ( clear all failures )
> 0x00000001 - Pseudo Wire Not Forwarding
> 0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault
> 0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault
> 0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault
> 0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault
> .En
> 
> status message with the respective bit cleared. The presence 
> of the lowest
> bit (PW Not Forwarding) acts only as a generic failure 
> indication when there
> is a link-down event for which none of the other bits apply.
> 
> The Status TLV is transported to the remote PW peer via the 
> LDP notification
> message. The format of the Notification Message is:
> 
> .DS 0 0
>   0                   1                   2                   3
> |1|   Notification   (0x0001)   |      Message Length           |
> |                         PW Status TLV                         |
> Status message, using a PW FEC TLV with only the group ID 
> set, to denote
> this change in status for all affected PW connections.
> 
> 
>

---

From: David Zelig <[email-masked]>
Date: Sun, 15 Jun 2003 16:44:56 +0200

Luca,

> that is never the case in the control draft.

Maybe I wasn't clear enough. In PW type EthernetVLAN for example, many PWs
may be associated with a single physical Ethernet interface. If the
interface table (in the ifMib) has no knowledge on each individual VLAN,
there is only one Administrative Status available at the physical port
without per VLAN granularity. In this case tearing an individual PW must be
done using the PW administrative status.
> one thing that is clear is that if the interface is admined 

Agree.

> I can see that port admin down == tear down is probably not a 

That's my observation too. For tearing down we have the PW administrative
status.

> but why do we need a separate status bit ?

In case of a fault indication, there might be some red alarms, automatic
fault correlation and debugging procedure that would start. With another bit
for administrative operation, no need for these processes.

> admin down , as opposed to the Pw tx/rx CE-facing fault ?
The same forwarding action, only different level of reporting.

---

From: Luca Martini <[email-masked]>
Date: Mon, 16 Jun 2003 14:01:13 -0600

Hamid Ould-Brahim wrote:
> Didn't notice the change from 16 bits to 4 octets for pw status (ignore 
> the Hex comment) for status. Though I think a 4 octets is a large field 
> for a status, why not reserve some octets in that field (something like 
> vendor specifics, etc)...   Hamid.
> 
yes , i did that , look in the iana draft, it's in there. I left it in this 
thread for discussion only.
Luca

>     From: Ould-Brahim, Hamid [CAR:1A00:EXCH]
>     Sent: Monday, June 16, 2003 11:41 AM
>     To: 'Andrew G. Malis'; Luca Martini
>     Cc: [email-masked]
>     [Catching up on my emails...]   Nice to see we are making progress
>     on an integrated approach. Some comments on the proposal...
> 
>      > >
>      >   Since the U bit in LDP notification message is set to 1 then
>     the U bit in Status TLV MUST be set to 0. In other words an LDP
>     notify message having a U bit set to 1 MUST include the status
>     message. Maybe this is not desirable for all notify messages having
>     U bit set. The problem is the notification message includes the PW
>     FEC TLV and that TLV is always present (no U bit) in notification
>     message below. In other words there is no point in including the PW
>     FEC in notify message without including the status TLV (therefore
>     the status TLV U bit must be set to 0). If we want to keep the
>     Status TLV optional, then we need to fix PW FEC (I don't expect that
>     is acceptable...). More on this item,  see the end of this email...
>      >   Since these are codepoints in Hex the above should be
>       rewritten to:     0x0000 - Pseudo Wire forwarding ( clear all
>     failures )
>       0x0002 - Local Customer-facing PW ( ingress ) Receive Fault
>       0x0004 - Local Customer-facing PW ( egress ) Transmit Fault
>       0x0008 - Local PSN-facing PW ( ingress ) Receive Fault
>       0x0010 - Local PSN-facing PW ( egress ) Transmit Fault
>       
>        The status should always be combined when multiple    errors
>     happen in an incremental way. For example at a given    time a PE
>     sends local Customer-facing ingress fault and later on    the
>     transmit fails, the sender PE should then update the previous   
>     status sent and not sent a separate status with only the latter   
>     problem reported.    This is to avoid that a new status for another
>     problem    clears the problem for the previous status. Same thing
>     when    new problems happen and other problems are cleared. The
>     receiving    PE should screen *ALL* the status bits (for updating
>     the    status of already reported problems), except for 0x001.    It
>     is important to note that when this codepoint is sent    the
>     receiving PE should *ignore* all the other bit (and not    treat
>     them as clear).      Since this is bitfield style approach,
>     depending what new status    will be added, it may happen that not
>     all combinations    are meaningful.      I am not as well clear on
>     0x001/not forwarding status.    0x0002 and 0x0010 means the PE not
>     forwarding as well. Reading    from the above, 0x001 is only
>     applicable to these two    codepoints (it is really a summary of
>     these two codepoints).    If we want it to be a summary of all the
>     codepoints    then we should call it something like
>     "Down/Disabled/General    problem".  
>      > >
>      > >   The LDP spec says that when U bit is set to 1 in the LDP
>     notification message:   "U bit
>        Should be 0 when the Status TLV is sent in a Notification message.
>        Should be 1 when the Status TLV is sent in some other message."  
>     In the PW status case, the normal notification for basic LDP is not
>     carried in some other message (still carried within the LDP
>     notification message). I assume this needs clarification with MPLS
>     WG such that LDP implementations that have U bit set will not
>     interpret that status will be received in some other messages (maybe
>     this is not an issue, a clarification/checking is always good in
>     case of ambiguity...).
>     Now if a PE doesn't understand status TLV and that PE receives a
>     notification message with U bit set and PW FEC& status included,
>     should that PE ignores the LDP notification? Note that I expect
>     basic LDP implementation to understand notify message but they may
>     not understand the status TLV. In that case, the status TLV and PW
>     FEC must always be present together, if a status TLV is ignored then
>     PW FEC is as well ignored. This area needs clarification.
>      > >   As I indicated in my previous emails, this solution works
>     only with PWid FEC not with generalized ID FEC (at least for the
>     Group ID). I suggest we have either:   a) status TLV/Notify
>     specified for both PW FECs, or b) a different one for Generalized ID
>     FEC...   In either case, the text should clarify this... Note that
>     for l2vpn, only VPLS service (vkompella proposal) is using the PWid
>     FEC, the other proposals will not take advantage of this change
>     (until this proposal works with generalized ID FEC)...   Hamid.
>      > >
>      >
>      > 
>

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Mon, 16 Jun 2003 11:41:55 -0400

[Catching up on my emails...]
 
Nice to see we are making progress on an integrated 
approach. Some comments on the proposal...

> >The format of the PW Status TLV is:
 
Since the U bit in LDP notification message is set
to 1 then the U bit in Status TLV MUST be set to 0. In other
words an LDP notify message having a U bit set to 1 
MUST include the status message. Maybe this is
not desirable for
all notify messages having U bit set. The problem is the notification
message includes the PW FEC TLV and that TLV is always
present (no U bit) in notification message below. 
In other words there is no point in including the PW FEC in notify 
message without including the status TLV (therefore the status TLV U bit
must be set to 0). If we want to keep the Status TLV
optional, then we need to fix PW FEC (I don't expect that
is acceptable...). More on this item,  see the end of this 
email...

  rewritten to:

> >is a link-down event for which none of the other bits apply.
 
   The status should always be combined when multiple
   errors happen in an incremental way. For example at a given 
   time a PE sends local Customer-facing ingress fault and later on
   the transmit fails, the sender PE should then update the previous
   status sent and not sent a separate status with only the latter
   problem reported.
   This is to avoid that a new status for another problem
   clears the problem for the previous status. Same thing when
   new problems happen and other problems are cleared. The receiving
   PE should screen *ALL* the status bits (for updating the
   status of already reported problems), except for 0x001.
   It is important to note that when this codepoint is sent 
   the receiving PE should *ignore* all the other bit (and not
   treat them as clear). 
 
   Since this is bitfield style approach, depending what new status
   will be added, it may happen that not all combinations
   are meaningful. 
 
   I am not as well clear on 0x001/not forwarding status.
   0x0002 and 0x0010 means the PE not forwarding as well. Reading
   from the above, 0x001 is only applicable to these two 
   codepoints (it is really a summary of these two codepoints).
   If we want it to be a summary of all the codepoints
   then we should call it something like "Down/Disabled/General
   problem".  

notification message:
 
"U bit
 
In the PW status case, the normal notification for basic LDP is not carried
in some other message (still carried within the LDP notification message).
I assume this needs clarification with MPLS WG such that LDP implementations
that have U bit set will not interpret that status will be received
in some other messages (maybe this is not an issue, a clarification/checking
is always good in case of ambiguity...).

Now if a PE doesn't understand status TLV and that PE receives
a notification message with U bit set and PW FEC& status
included, should that PE ignores the LDP notification? Note that
I expect basic LDP implementation to understand notify message
but they may not understand the status TLV. In that case, the
status TLV and PW FEC must always be present together, if
a status TLV is ignored then PW FEC is as well ignored. This
area needs clarification.

> >this change in status for all affected PW connections.
 
As I indicated in my previous emails, this solution works only
with PWid FEC not with generalized ID FEC (at least for the
Group ID). I suggest we have either:
 
a) status TLV/Notify specified for both PW FECs, or
b) a different one for Generalized ID FEC...
 
In either case, the text should clarify this...
Note that for l2vpn, only VPLS service (vkompella proposal) is using 
the PWid FEC, the other proposals will not take advantage 
of this change (until this proposal works with generalized
ID FEC)...
 
Hamid.

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Mon, 16 Jun 2003 12:04:27 -0400

Didn't notice the change from 16 bits to 4 octets for
pw status (ignore the Hex comment) for
status. Though I think a 4 octets is a large field for a status, 
why not reserve some octets in that field (something
like vendor specifics, etc)...
 
Hamid.

-----Original Message-----
From: Ould-Brahim, Hamid [CAR:1A00:EXCH] 
Sent: Monday, June 16, 2003 11:41 AM
To: 'Andrew G. Malis'; Luca Martini
Cc: [email-masked]
Subject: RE: [PWE3] status signalling of MPLS PW state

 

   

 

 
"U bit

 

 
Hamid.

---

From: "David Allan" <[email-masked]>
Date: Tue, 17 Jun 2003 12:51:59 -0400

I think there is still a few outstanding issues with the current
description.

1) Ideally the status TLV should be able to be carried in both the label
mapping and notification messages. IMHO there is a lot of reasons for this:
	- minimal messaging during both initial provisioning (if ducks are
aligned right off the bat) and during a graceful 
	restart
	- minimal state machine changes as we are not reusing label mapping
as a notification mechanism for subsequent status 
	changes arising after the initial label mapping.
	- simpler backwards compatibility (see #2 below)

2) Setting U=0 in status TLV carried in a label mapping message sorts out
backwards compatibility support issues relatively quickly. We can provision
PWs even if the attachment circuit is down where status TLV is supported. If
the far end does not support status TLV, then the label mapping is rejected
(net effect being the same as the semantics associated with the use of label
withdraw to communicate status, aka as non-supporting far end rejects the
mapping, net result is the same as not having offered it).

Even if we devise a per-session capability negotiation, I'd presume we'd
still want u=0 as a safety mechanism. IMHO per session capability is useful
(particularly w.r.t. graceful restart) where we do not want to blow off a
lot of time up front negotiating what works on an PW by PW basis.

3) We need to sort out the precedence semantics of the use of group ID along
with the status of individual components. Superficially it would appear that
any group status change trumps any previously communicated individual
statuses (w.r.t. the same class of error). 

cheers
Dave

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Tue, 17 Jun 2003 13:42:38 -0400

Luca, all,

Since we may end up with an extra message anyway for
carrying information other than status (for example
IP address, QoS, the stuff in Himanshu's draft).
If I recall as well, you proposed in one of your previous emails
to use a new message (called PW dynamic parameters) for carrying
such information. Why not then adopt the following proposal.

a) Instead of having a separate message
   for just status why not define a new message for carrying PW 
   dynamic parameters this can be sent after label mapping 
   (or PW operational).

   That message carries the:

   - Status TLV
   - IP address TLV,
   - QoS, 
   - etc 

(these are all optional TLVs with U bit set to 1).

b) and use initially within a label mapping the status TLV to
   convey the initial status to the remote end
   before traffic is sent.

In that case, the new message is not just for status, it is
about "things" that the remote end needs to know during the
lifetime of the PW and status TLV can be carried in both
the PW dynamic parameters and label mapping events.

This approach avoids the notify message U bit problems, and is
more or less a combination between the two proposals.

Comments?

Hamid.

> 
> comments in line.
> 
> Luca
> 
> 
> Hamid Ould-Brahim wrote:
> > [Catching up on my emails...]   Nice to see we are making 
> progress on an 
> > integrated approach. Some comments on the proposal...
> > 
> >  > >
> >  >   Since the U bit in LDP notification message is set to 
> 1 then the U 
> > bit in Status TLV MUST be set to 0. In other words an LDP 
> notify message 
> > having a U bit set to 1 MUST include the status message. 
> Maybe this is 
> > not desirable for all notify messages having U bit set. The problem 
> > is the notification message includes the PW FEC TLV and that TLV is 
> > always present (no U bit) in notification message below. In 
> other words 
> > there is no point in including the PW FEC in notify message without 
> > including the status TLV (therefore the status TLV U bit 
> must be set to 
> > 0). If we want to keep the Status TLV optional, then we 
> need to fix PW 
> > FEC (I don't expect that is acceptable...). More on this 
> item,  see the 
> > end of this email...
> 
> You have a good point.
> I'm checking around to see what the behavior would be.
> 
> I was also thinking that maybe we should not set this U bit at all.
> After all this is the standard , and maybe we should just 
> mention that for 
> backward compatibility implementations might want to set it.
> 
> 
> 
> 
> >  >     Since these are codepoints in Hex the above should 
> be   rewritten 
> > to:     0x0000 - Pseudo Wire forwarding ( clear all failures )
> errors happen in 
> > an incremental way. For example at a given    time a PE sends local 
> > Customer-facing ingress fault and later on    the transmit 
> fails, the 
> > sender PE should then update the previous    status sent 
> and not sent a 
> > separate status with only the latter    problem reported.   
>  This is to 
> > avoid that a new status for another problem    clears the 
> problem for 
> > the previous status. Same thing when    new problems happen 
> and other 
> > problems are cleared. The receiving    PE should screen 
> *ALL* the status 
> > bits (for updating the    status of already reported 
> problems), except 
> > for 0x001.    It is important to note that when this 
> codepoint is sent 
> >    the receiving PE should *ignore* all the other bit (and 
> not    treat 
> depending 
> > what new status    will be added, it may happen that not all 
> > combinations    are meaningful.      I am not as well clear 
> on 0x001/not 
> > forwarding status.    0x0002 and 0x0010 means the PE not 
> forwarding as 
> > well. Reading    from the above, 0x001 is only applicable 
> to these two 
> >    codepoints (it is really a summary of these two 
> codepoints).    If we 
> > want it to be a summary of all the codepoints    then we 
> should call it 
> > something like "Down/Disabled/General    problem".  
> 
> yes , this is the intended behavior , but I see that it needs 
> more explanation.
> 
> 
> >  > >
> >  > >|                         PW Status TLV                 
> >    Should be 1 when the Status TLV is sent in some other 
> message."   In 
> > the PW status case, the normal notification for basic LDP 
> is not carried 
> > in some other message (still carried within the LDP notification 
> > message). I assume this needs clarification with MPLS WG 
> such that LDP 
> > implementations that have U bit set will not interpret that 
> status will 
> > be received in some other messages (maybe this is not an issue, a 
> > clarification/checking is always good in case of ambiguity...).
> > notification message with U bit set and PW FEC& status 
> included, should 
> > that PE ignores the LDP notification? Note that I expect basic LDP 
> > implementation to understand notify message but they may 
> not understand 
> > the status TLV. In that case, the status TLV and PW FEC 
> must always be 
> > present together, if a status TLV is ignored then PW FEC is as well 
> > ignored. This area needs clarification.
> 
> so the PW FEC is here to identify to which PW this status 
> message applies.
> Yes, if the message is ignored because it is not understood , 
> then status 
> signaling will not work. This might be ok in some deployments.
> 
> Group ID). I 
> > suggest we have either:   a) status TLV/Notify specified 
> for both PW 
> > FECs, or b) a different one for Generalized ID FEC...   In 
> either case, 
> > the text should clarify this... Note that for l2vpn, only 
> VPLS service 
> > (vkompella proposal) is using the PWid FEC, the other 
> proposals will not 
> > take advantage of this change (until this proposal works with 
> > generalized ID FEC)...   Hamid.
> >  > >
> 
> I see. Yes , this needs fixing. It was my intention to make 
> it apply to both.
> 
> 
> >  >
> >  >
> 
> Luca
> 
>

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Tue, 17 Jun 2003 16:09:18 -0400

Adding further clarifications to this proposal. The TLV status is
exactly what is in Luca's final proposal. The behavior would be
 
a) The initial label mapping exchange includes the
   Status TLV (U bit set to 1).
 
   If the receiving PE doesn't understand the status TLV
   it will just ignore this TLV and will follow normal
   procedures.
 
   The sender PE when receiving the reverse label mapping
   checks if status TLV is included. If it is included it concludes
   that the remote PE understands the Pseudo-wire Dynamic
   Parameter message (let's just call it the PDP message).
 
   From there, when problems happen, the PDP message is sent.
   If the label mapping doesn't contain status TLV, the
   sender PE concludes that the remote PE doesn't understand
   status TLV. In that case normal behavior should
   be followed (this is the backward compatibility rule,
   PEs that do not understand PDP message will not receive it).
 
b) The status TLV will then be conveyed within the PDP
   message. The PDP message as indicated before may convey
   other TLVs (IP address, etc). 
 
c) An initial indication of "PW not forwarding/down, etc" in the
   label mapping indicates to the remote end not to send
   traffic until the PDP message is sent with a clear code point.
 
It will be advisable to have per session cap negotiation however
the above works without it with the understanding that it works
per PW.
 
Hamid.

 -----Original Message-----
From: Ould-Brahim, Hamid [CAR:1A00:EXCH] 
Sent: Tuesday, June 17, 2003 1:43 PM
To: Luca Martini
Cc: Andrew G. Malis; [email-masked]
Subject: RE: [PWE3] status signalling of MPLS PW state

Luca, all, 

   - Status TLV 
   - IP address TLV, 
   - QoS, 
   - etc 

Comments? 

Hamid.

---

From: Luca Martini <[email-masked]>
Date: Tue, 17 Jun 2003 16:31:27 -0600

no, please there is no need to make life this complicated.
this is very similar to where we started out.
There is no need to negotiate, if this is not implemented status does not work. 
( that seems to be ok for things such as draft-kompella )
There is no need to define here what PPVPN might sometime do.
A status notification is not an IP address , or a MAC address.

Hamid Ould-Brahim wrote:
> exactly what is in Luca's final proposal. The behavior would be   a) The 
> initial label mapping exchange includes the    Status TLV (U bit set to 

> 1).      If the receiving PE doesn't understand the status TLV    it 
> will just ignore this TLV and will follow normal    procedures.      The 
> sender PE when receiving the reverse label mapping    checks if status 
> TLV is included. If it is included it concludes    that the remote PE 
> understands the Pseudo-wire Dynamic    Parameter message (let's just 
> call it the PDP message).      From there, when problems happen, the PDP 
> message is sent.    If the label mapping doesn't contain status TLV, the 
>    sender PE concludes that the remote PE doesn't understand    status 
> TLV. In that case normal behavior should    be followed (this is the 
> backward compatibility rule,    PEs that do not understand PDP message 
> will not receive it).   
this is not a bad idea , except that now we have to define 2 places to send the 
status TLV in.

b) The status TLV will then be conveyed within
> the PDP    message. The PDP message as indicated before may convey    

PDP = notification :-)

c) An initial indication of "PW not
> forwarding/down, etc" in the    label mapping indicates to the remote 
> end not to send    traffic until the PDP message is sent with a clear 
> code point.   It will be advisable to have per session cap negotiation 
> however the above works without it with the understanding that it works 
> per PW.

not sure what you meant here.

    Hamid.      -----Original Message-----
>      > >  > |                         Status
>     Code                           |
>      > >  > >  0                   1                  
>     2                   3

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Wed, 18 Jun 2003 10:22:33 -0400

Luca,

> A status notification is not an IP address , or a MAC address.

I think I sense some misunderstanding here. I am perfectly
fine with Notify message if we can make it work (at least no major
issue) and clarify the behavior ;-). 
 
The motivation for this suggestion is not
to start from scratch but to accommodate status signaling with
providing the framework for signaling items needed during
the lifetime of PW and at the same time address some points
raised before (sooner or later when there is a need -and there will be-
to signal additional stuff to PW, folks will at least find the 
framework already established and not just overload the label mapping). 
In fact this suggestion doesn't require any negotiation or P bit support, 
etc (and looks to me less complex than resolving the U bit items
in notify message). 
 
But anyway no matter what approach is taken, 
let's look at items that I think are important to consider 
(some have already been covered and addressed):
 
a) Backward compatibility rule:
 
   A PE that doesn't understand status TLV should be able to establish
   a PW to another PE (supporting Status TLV) using normal
   procedures. In this case both PEs will not advertise (signal)
   status TLV.
 
   That rule requires that the sender PE (supporting status TLV)
   needs to find out implicitly or explicitly the intentions/capabilities 
   of the receiving PE. 
   The notify message (including the use of a new message in that regard)
   cannot provide such information.
 
   There are two options for that: 
 
   - Either include in the label mapping the status (or capability)
     for just the initial setup (no need to send the label mapping each time
     status has changed). The behavior is what is indicated in my
     previous email which pretty much reused Himanshu's status TLV
     behavior, or
     
   - Have some capability advertisement between PEs or session
     negotiation. I realize there is some resistance to that and may 
     require some work on the session hand shake...
 
    For simplicity I picked the first option. Yes the status will
    appear in two messages. But this is okay since the status TLV needs
    to appear for events that require status notification. 

b) Initial PW status Notification
 
   It is desirable that two PEs establishing a PW and both 
   supporting status TLV need to be able to find out upfront the status
   of PW such that they take appropriate actions before even accepting
   and forwarding traffic.
 
   For this requirement, either we assume that initially the
   PW is not forwarding until the notification is received or
   we just indicate in the label mapping the status. Given a) I prefer
   to use label mapping.
 
I think Dave mentioned as well the benefit of using status
TLV in label mapping during graceful restart...

> this is not a bad idea , except that now we have to define 2
 
Yes. I don't see problem with that. There are events where
sending status is important: 
 
a) During the initial PW establishment.
b) When operational status changes.
 
To meet a) we include it in label mapping, and to meet
b) use notify or new message or the preferred mode.

> > other TLVs (IP address, etc).  
 
Yes, with the understanding that we clarify the issues with
respect to basic LDP functionality and with the understanding
that this approach may motivate other folks
to add new stuff to notify message later on. This may not
be a desirable approach....but don't get me wrong I am just
trying to be clear on that (not asking for perfection ;-)).
As I said I can live with notify message given we can reach
agreement on its usage and how best it meets most of the
requirements.

> not sure what you meant here.
 
I meant the negotiation is in fact "implicit" through normal
PW label mapping exchange...no need to add P bit, session nego, 
etc...
 
Hamid.

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 18 Jun 2003 10:04:45 -0400

comments in line..

> Sent: Tuesday, June 17, 2003 6:31 PM
> To: Hamid Ould-Brahim

I fail to see what part is complicated.

> There is no need to negotiate, if this is not implemented 

There is no negotiation here. It is exactly same as P bit in
VC type field but better. It follows the base LDP spec's 
STATUS TLV mechanisms (which allows status to be passed
in optional parameter field of label mapping msg as well as
in notification msg).

> ( that seems to be ok for things such as draft-kompella )

I am not sure what you are referring to here

> There is no need to define here what PPVPN might sometime do.

There is no need to define it within status spec but there needs to exist
a hook for future extensions in a backward compatible fashion.

> A status notification is not an IP address , or a MAC address.

No it is not but it is in the same category as IP address or MAC address
called "dynamic attributes" and there should be one mechanism to
exchange dynamic attributes in a manner such that exchange of one attribute
does not interfere with other.

/himanshu

> >      > >  >   0                   1                   2     
>               3
> >      > >  >   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 
> 3 4 5 6 7 8
> >     9 0 1
> >      > >  >
> >     
> >      > > is the notification message includes the PW FEC 
> TLV and that
> >     TLV is
> >      > >  > >The above status codes can be logically 
> combined to indicate
> >      > >  > more then a
> >      > >  > >single failure at once. Each fault can be 
> cleared by sending
> >      > >  > an appropriate
> >      > > an incremental way. For example at a given    time 
> a PE sends
> >     local
> >      > > present together, if a status TLV is ignored then 
> PW FEC is as
> >     well
> >      > >  > >The PW FEC TLV SHOULD not include the 
> interface parameters
> >      > >  > as they are
> >      > >  > >encounters an error, use of the new message 
> allows the PE to
> >      > >  > send a single

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Thu, 19 Jun 2003 13:17:58 -0400

Luca,
 
> thread for discussion only.

Okay. I looked at the PW-IANA draft. I think that part needs
to be reworked in order to reflect exactly the usage of the 
status field. 
 
In pw-iana draft:
 
"   As specified in [1], a new PW status TLV contains a 32 bit field, PW
   status value 0 is reserved to clear all failures. PW Status Bits 0
   through 4 are defined in this document. PW Status Bits 6 through 15
   are to be assigned by IANA using the "IETF Consensus" policy defined
   in RFC2434. PW Status Bits 16 through 23 are to be assigned by IANA,
   using the "First Come First Served" policy defined in RFC2434. PW
   Status Bits 24 through 31 are vendor-specific, and values in this
   range are not to be assigned by IANA.

   PW status is a 4 octet bit field as follows:

           0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault" 
 
Since the structure is a bit field and since in that
structure some bits/set of bits are reserved. The above codepoints
do not exactly reflect the intent. For example,
it is not that 0x00000002 that makes the local customer-facing PW
receive fault but it is the setting of bit number 1 that indicates
this problem is happening. 
 
I suggest to layout the bit structure with each bit having its own 
description. Using the pw-IANA description above (btw I think there is 
a typo with respect to bit number 5 which appears as 6 in the iana draft), 
my suggestion is to rewrite the above to:
 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |N|I|E|R|T|  IANA ASSIGNED      |   IANA FCFS   |     VENDOR    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   N: The "not forwarding bit". When this bit is set, it indicates the
      PE sending the status is in "not forwarding" state.
   I: Local Customer-facing PW ( ingress ) Receive Fault
   E: Local Customer-facing PW ( egress ) Transmit Fault
   R: Local PSN-facing PW ( ingress ) Receive Fault
   T: Local PSN-facing PW ( egress ) Transmit Fault

   A value of 0x00000000 is reserved and indicates that the status
   of the Pseudo-wire is forwarding. 
 
   Obviously the NIERT bits can be set independently (and that
   makes status combination).

Hamid.

---

From: "Shah, Himanshu" <[email-masked]>
Date: Mon, 23 Jun 2003 18:34:11 -0400

You need to add more text/clarifications on
when PE should/should not send the status
signaling and how reciever should process it.

The last thing you want is deadlock due to 
inter dependant status msgs.

/himanshu
Ciena networks

> Sent: Monday, June 23, 2003 5:47 PM
> To: Hamid Ould-Brahim
> Cc: Andrew G. Malis; [email-masked]; Mark Townsley (E-mail)
> Does anybody else agree with this different way of writing this ?
> I think that pretty much either way works.
> 
> Luca
> 
> 
> Hamid Ould-Brahim wrote:
> > Luca,   > yes , i did that , look in the iana draft, it's 
> in there. I
> >  > left it in this
> > Okay. I looked at the PW-IANA draft. I think that part needs to be 
> > reworked in order to reflect exactly the usage of the 
> status field.   In 
> > pw-iana draft:   "   As specified in [1], a new PW status 
> TLV contains a 
> > 32 bit field, PW
> > Since the structure is a bit field and since in that structure some 
> > bits/set of bits are reserved. The above codepoints do not exactly 
> > reflect the intent. For example, it is not that 0x00000002 
> that makes 
> > the local customer-facing PW receive fault but it is the 
> setting of bit 
> > number 1 that indicates this problem is happening.   I 
> suggest to layout 
> > the bit structure with each bit having its own description. 
> Using the 
> > pw-IANA description above (btw I think there is a typo with 
> respect to 
> > bit number 5 which appears as 6 in the iana draft), my 
> suggestion is to 
> > rewrite the above to:       0                   1                   
> > 2                   3
> >    of the Pseudo-wire is forwarding.      Obviously the 
> NIERT bits can 
> > be set independently (and that    makes status combination).
> > Hamid.
> >  
> 
> 
>