[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PWE3] status signalling of MPLS PW state


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




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

[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:
> >.DS 0 0
> 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| PW Status (0x0???) | Length |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Status Code |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> .DE
> 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...
> 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
> Since these are codepoints in Hex the above should be
rewritten to: 0x0000 - Pseudo Wire forwarding ( clear all
failures )
0x0001 - Pseudo Wire Not Forwarding
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 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. 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 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
> > 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| Notification (0x0001) | Message Length |
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >| Message ID |
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >| PW FEC TLV |
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >| PW Status TLV |
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >.DE
> > 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.
> >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
> >Status message, using a PW FEC TLV with only the group ID
> set, to denote
> >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.
> >
>
> 

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3