RE: [PWE3] status signalling of MPLS PW state

["Himanshu Shah" <hshah@wavesmithnetworks.com>]

comments in line...

> -----Original Message-----
> From: Luca Martini [mailto:luca@level3.net]
> Sent: Wednesday, June 11, 2003 7:06 PM
> To: Andrew G. Malis
> Cc: pwe3@ietf.org
> Subject: Re: [PWE3] status signalling of MPLS PW state
> 
> 
> 
> 
> Andrew G. Malis wrote:
> > Luca,
> > 
> > I would like to agree with Himanshu's message.
> > 
> > To tell you the truth, I was a bit surprised to your 
> message proposing 
> > Toby's text for status signaling.  I was under the 
> impression (perhaps 
> > mistaken?) that WG consensus had already been determined to accept 
> > draft-shah-pwe3-control-protocol-extension-00.txt and that 
> it was in the 
> > process of being incorporated into the main control signaling draft.
> > 
> actually most of that draft belongs in PPVPN. I had only 
> agreed to consider it 
> , and WG feed back was that it is a good idea to have such mechanisms.
> 
> lot's of reasons where in the text that I posted earlier.

Himanshu> Actually none of the draft-shah-pwe3-control-protocol-extension-00.txt 
belongs to PPVPN. It is all related to signaling attributes of the PW.

The main purpose of the draft is also to propose a mechanism
which allows future extensions in backward compatible 
fashion without having anybody to keep requesting the changes in
the base draft.




> 
> > I certainly agree that one or the other is needed, and if I had to 
> > choose between them, the Operational Status TLV is 
> certainly easier to 
> > implement and less disruptive to existing LDP 
> implementations than the 
> > PW Link Status Message.  Is there a really good reason why the 
> > Operational Status TLV can't work?
> > 
> > I saw Toby's comment about only using the group ID to 
> reflect interface 
> > outages, but that's only useful if you have multiple parallel PWs 
> > between the same two logical interfaces at the edge of the 
> network (they 
> > have to share the same LDP session), which isn't going to 
> be all that 
> > common.  I can tell you from experience in large FR and ATM 
> networks 
> > that end-to-end status signaling on a per-VC (per-PW in our 
> case) basis 
> > works just fine, even when you have interface outages.
> > 
> Actually back in the san diego IETF there was a strong 
> request for the group ID 
> mechanisms for large NNI to NNI applications.
> the down notification had to be immediate for 10000 PWs.
> One other issue is that we would like to limit what goes into 
> this message. 
> There is a very limited set of useful failures at the PW 
> abstraction layer.
> The TLVs proposed in 
> draft-shah-pwe3-control-protocol-extension-00 are useful 
> and need to be included where most appropriate.
> Operational state in not a FEC, this is why I did not put 
> this in the interface 
> parameters..
> 

Himanshu>
If group ID is important, operational status TLV of draft-shah 
can be extended to include group ID with a group ID present bit.
When present, the status is applied to the whole group.

regards,
himanshu





> Thanks.
> Luca
> 
> 
> > Are there any other reasons?
> > 
> > Thanks,
> > Andy
> > 
> > ---------
> > 
> > At 6/10/2003 09:22 AM -0400, Himanshu Shah wrote:
> > 
> >> Luca,
> >>
> >> I am glad that you have recognized the need for
> >> conveying the link status as compared to withdrawing
> >> the VC-LABEL for the same and Toby has good
> >> proposal.
> >>
> >> However, I would like PWE3 to approach this slightly
> >> differently as described in
> >> draft-shah-pwe3-control-protocol-extension-00.txt.
> >>
> >> We need a +generic mechanism+ to relay "dynamic
> >> attributes" of the PW, including the status of the AC (and
> >> yes, it should be AC or PW status as compared to link status).
> >> The generic mechanism can then be used to extend
> >> control signaling without having to constantly change
> >> the base draft.
> >>
> >> The extension draft proposes that such PW attributes
> >> be included in "optional parameter" field of the Label
> >> mapping message. The advantage of this approach is,
> >>
> >> 1) conveying of one or more dynamic attributes in a
> >>      single label mapping message. Extension draft describes
> >>      IP addr (needed for ARP-mediation) , IP+MAC addr (needed
> >>      for IPLS), QOS, tunnel mechanisms used, etc TLVs.
> >> 2) a way to include these attributes in first mapping msg
> >>      as compared to a follow-on status msgs (for example,
> >>      PE does not know the status of the remote AC until
> >>     link status msg follows the initial label mapping msg)
> >> 3) allows update of the attributes. When dynamic attribute
> >>     changes, an update is sent without withdrawing the VC-FEC
> >> 4 ) allows definitions of new attributes without
> >>       modifying base LDP or martini signaling draft
> >>
> >> I would like PWE3 to consider this approach.
> >>
> >> /himanshu
> >> wavesmith networks
> >>
> > 
> 
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3