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...
> >
> > > >
> > > >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...
>
> 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.
>
>
>
>
> > > 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".
>
> yes , this is the intended behavior , but I see that it needs
> more explanation.
>
>
> > > >
> > > >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.
>
> 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.
>
> > > >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.
> > > >
>
> I see. Yes , this needs fixing. It was my intention to make
> it apply to both.
>
>
> > >
> > >
>
> Luca
>
>