[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.
> >
>
>