Subject: Re: status signalling of MPLS PW state

From: Luca Martini <[email-masked]>
Date: Mon, 23 Jun 2003 15:47:12 -0600

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
>  > 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:
> 
>            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"   
> 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: Wei Luo <[email-masked]>
Date: Mon, 23 Jun 2003 15:52:01 -0700

The way written in the draft is fine, no ambiguity for implementation.  I do
have a couple of comments and questions regarding this draft.

1. This draft makes reference to draft-ietf-pwe3-control-protocol-03.txt which
is not available online yet.  Maybe providing that would help clarify how the
new PW status TLV is used.  Especially, whether it's possible to encode it in
the LDP notification message and corresponding actions need to perform upon
receiving this TLV.

2. What is the difference between Frame Relay Port mode and HDLC mode?

---Wei

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