Andrew G. Malis wrote:
Luca,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.
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.
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?Actually back in the san diego IETF there was a strong request for the group ID mechanisms for large NNI to NNI applications.
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.
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