[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [PWE3] status signalling of MPLS PW state
Andy and Luca,
I support Andy's position.
Please see also additional comments inline.
With best regards,
Sasha Vainshtein
email: sasha@axerra.com <mailto:sasha@axerra.com>
tel: +972-3-7659993 (office)
+972-8-9254948 (res.)
+972-58-674833 (cell.)
> -----Original Message-----
> From: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com]
> Sent: Wednesday, June 11, 2003 7:59 PM
> To: Luca Martini
> Cc: pwe3@ietf.org
> Subject: RE: [PWE3] status signalling of MPLS PW state
>
>
> 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.
>
> 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.
>
IMHO, adding a new message to LDP would require involvement of the MPLS WG.
>
> Is there a really good reason why the Operational Status TLV
> can't work?
>
I think that the Operational Status TLV in LDP and the
Circuit Status AVP in L2TPv3 serve exactly the same purpose
and hence should carry the same information. Currently there
are some minor differences.
I also agree with Himanshu that ability to signal the attachment
circuit status at the PW establishment is important.
>
> 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.
>
Does not the same logic apply to "wild card withdrawal" of PW labels based
on Group ID as presented in Section 5.1 of
draft-ietf-pwe3-control-protocol-02.txt?
>
> 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