[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PWE3] status signalling of MPLS PW state
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:
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).
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
other TLVs (IP address, etc).
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-----
From: Ould-Brahim, Hamid [CAR:1A00:EXCH]
Sent: Tuesday, June 17, 2003 1:43 PM
To: Luca Martini
Cc: Andrew G. Malis; pwe3@ietf.org
Subject: RE: [PWE3] status signalling of MPLS PW state
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
>
>
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3