RE: [PWE3] status signalling of MPLS PW state

["Hamid Ould-Brahim" <hbrahim@nortelnetworks.com>]

Luca,

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

I think I sense some misunderstanding here. I am perfectly

fine with Notify message if we can make it work (at least no major

issue) and clarify the behavior ;-).

 

The motivation for this suggestion is not

to start from scratch but to accommodate status signaling with

providing the framework for signaling items needed during

the lifetime of PW and at the same time address some points

raised before (sooner or later when there is a need -and there will be-

to signal additional stuff to PW, folks will at least find the

framework already established and not just overload the label mapping).

In fact this suggestion doesn't require any negotiation or P bit support,

etc (and looks to me less complex than resolving the U bit items

in notify message).

 

But anyway no matter what approach is taken,

let's look at items that I think are important to consider

(some have already been covered and addressed):

 

a) Backward compatibility rule:

 

   A PE that doesn't understand status TLV should be able to establish

   a PW to another PE (supporting Status TLV) using normal

   procedures. In this case both PEs will not advertise (signal)

   status TLV.

 

   That rule requires that the sender PE (supporting status TLV)

   needs to find out implicitly or explicitly the intentions/capabilities

   of the receiving PE.

   The notify message (including the use of a new message in that regard)

   cannot provide such information.

 

   There are two options for that:

 

   - Either include in the label mapping the status (or capability)

     for just the initial setup (no need to send the label mapping each time

     status has changed). The behavior is what is indicated in my

     previous email which pretty much reused Himanshu's status TLV

     behavior, or

     

   - Have some capability advertisement between PEs or session

     negotiation. I realize there is some resistance to that and may

     require some work on the session hand shake...

 

    For simplicity I picked the first option. Yes the status will

    appear in two messages. But this is okay since the status TLV needs

    to appear for events that require status notification. 

 

 

b) Initial PW status Notification

 

   It is desirable that two PEs establishing a PW and both

   supporting status TLV need to be able to find out upfront the status

   of PW such that they take appropriate actions before even accepting

   and forwarding traffic.

 

   For this requirement, either we assume that initially the

   PW is not forwarding until the notification is received or

   we just indicate in the label mapping the status. Given a) I prefer

   to use label mapping.

 

I think Dave mentioned as well the benefit of using status

TLV in label mapping during graceful restart...

 

Some other comments below as well:

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

 

Yes. I don't see problem with that. There are events where

sending status is important:

 

a) During the initial PW establishment.

b) When operational status changes.

 

To meet a) we include it in label mapping, and to meet

b) use notify or new message or the preferred mode.

 

> 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 :-)
>

 

Yes, with the understanding that we clarify the issues with

respect to basic LDP functionality and with the understanding

that this approach may motivate other folks

to add new stuff to notify message later on. This may not

be a desirable approach....but don't get me wrong I am just

trying to be clear on that (not asking for perfection ;-)).

As I said I can live with notify message given we can reach

agreement on its usage and how best it meets most of the

requirements.

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

 

I meant the negotiation is in fact "implicit" through normal

PW label mapping exchange...no need to add P bit, session nego,

etc...

 

Hamid.

 

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