[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [PWE3] NSP signaling
Chris and all,
Please see some 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: Chris Metz [mailto:chmetz@cisco.com]
> Sent: Tuesday, October 08, 2002 5:51 PM
> To: Sasha Vainshtein
> Cc: Shahram Davari; 'pwe3@ietf.org'; ppvpn@ppvpn.francetelecom.com
> Subject: RE: [PWE3] NSP signaling
>
>
> Sasha/all-
> Agree. But the question involved NSP signaling. I think it
> can be done in
> one of two ways without violating principles laid down in the PLD:
>
> 1. Transparently tunnel it ... this is the easiest
>
If it exists natively. I assume that if it doesn't exist, you
do not invent it for the PW use.
>
> 2. Interwork NSP with PW signaling. This is the hardest and
> should not
> involve any changes to PW signaling behavior. It is strictly an
> implementation matter left up to the designers.
>
I do not see any problem with a transparent placeholder
in the PW signaling (like Optional Interface Descriptor string
in Section 5.1 of draft-ietf-pwe3-control-protocol-00.txt). Of course
interpretation of any data sent in such a placeholder is
purely a local matter. In particular, the PW setup MUST NOT
be rejected based on inability to fill or interpret this
information. I assume that this is what you mean by "not
involving any changes in the PW signaling behavior".
>
> Cheers ...
>
>
>
>
> At 09:29 AM 10/8/2002 +0200, Sasha Vainshtein wrote:
> >Shahram, Chris and all,
> >NSP is not a mystic box doing whatever the designer
> >seems fit.
> >It is a _native_ service processor that happens to be
> >part of the PE instead of residing out of it.
> >Hence it should not - and I think the layering draft
> >explains it quite well - do things that are not natively
> >part of the emulated service.
> >Going to Shahram's example, the PWE3 should not care
> >whether the ATM cell stream carried over the PW is
> >generated by an NSP that resides within a PE or by an
> >external device. In particular, the PW behavior should
> >not be affected by the fact that one of its end points
> >is connected to an NSP within the PE performing AAL1
> >adaptation of a TDM stream while the other
> >is connected to a "native" ATM port with adaptation
> >to TDM being performed by the CE. (The layering document
> >expicitly mentions such use cases - e.g., see Fig. 3).
> >
> >The bottom line: NSP signaling should be out of scope of
> >PWE3.
> >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: Chris Metz [mailto:chmetz@cisco.com]
> > > Sent: Monday, October 07, 2002 5:39 PM
> > > To: Shahram Davari
> > > Cc: 'pwe3@ietf.org'; ppvpn@ppvpn.francetelecom.com
> > > Subject: RE: [PWE3] NSP signaling
> > >
> > >
> > > Sharam-
> > >
> > > At 07:07 AM 10/7/2002 -0700, Shahram Davari wrote:
> > > >Chris,
> > > >
> > > >NSPs may need to coordinate certain parameters with each
> other. For
> > > >example imagine that the service is TDM, and that we are
> > > using ATM CES
> > > >over MPLS. In that case, the NSPs may need
> > > >to inform each other of the type of the traffic (structured,
> > > unstructured,
> > > >structured w/CAS, etc.).
> > >
> > > I would think PWE3 since the dynamic programming of the NSPs
> > > is needed at
> > > each end to establish the PWE3 service. Aren't there LDP TLV
> > > placeholders
> > > for this kind via the VC FEC interface parameters? This
> > > should serve as a
> > > useful mechanism to opaquely carry this information from one
> > > NSP to another.
> > >
> > > In my previous response I was thinking more in the context of
> > > a broader
> > > VPWS-style environment where an NSP may behave as an autonomous
> > > signaling/routing node communicating with other like
> NSP's or native
> > > signaling/routing elements. PWE3 certainly should not care what
> > > signaling/routing messages may be exchanged between NSP's.
> > > Any interaction
> > > at all between NSP signaling/routing and PWE3 signaling
> > > should be a local
> > > matter, IMHO ...
> > >
> > > Cheers ...
> > >
> > > >
> > > >
> > > >I would like to know in which WG should this be defined.
> > > >
> > > >Thanks,
> > > >-Shahram
> > > >
> > > > > -----Original Message-----
> > > > > From: Chris Metz [mailto:chmetz@cisco.com]
> > > > > Sent: Monday, October 07, 2002 9:40 AM
> > > > > To: Shahram Davari
> > > > > Cc: 'pwe3@ietf.org'; ppvpn@ppvpn.francetelecom.com
> > > > > Subject: Re: [PWE3] NSP signaling
> > > > >
> > > > >
> > > > > Shahram-
> > > > >
> > > > > At 03:07 PM 10/4/2002 -0700, Shahram Davari wrote:
> > > > > >Hi,
> > > > > >
> > > > > >In the PW layering architecture a PE is divided in to PREP
> > > > > (pre-processor)
> > > > > >and IW.
> > > > > >The PREP is further divided to NSP and Forwarder.
> > > > > >
> > > > > >Draft-rosen and draft-martini define signaling methods for
> > > > > communication
> > > > > >between IWs or forwarders.
> > > > > >
> > > > > >Many different services could use the same Forwarder and/or
> > > > > IW function.
> > > > > >However, they may need their own signaling for configuration
> > > > > of their NSP.
> > > > >
> > > > > Configuration in what sense? If it is specific to an AC
> > > > > terminating in the
> > > > > local PE (NSP) then it is a local matter outside the scope of
> > > > > any WG (PWE3
> > > > > or PPVPN) as far as I can make out.
> > > > >
> > > > > IMO, if it involves manipulation of the forwarder and/or IW
> > > > > function then
> > > > > again it is a local matter as to how the NSP may want to
> > > > > interact with the
> > > > > PW protocol machinery. NSPs are also free to convey
> > > > > signaling messages
> > > > > amongst themselves in a transparent overlay fashion without
> > > > > any PW interaction.
> > > > >
> > > > > >
> > > > > >
> > > > > >I was wondering in which WG should this type of signaling be
> > > > > defined? and
> > > > > >has anybody defined
> > > > > >such a signaling (independent of the Forwarder and IW
> > > function) yet?
> > > > >
> > > > > This should be dependent on the type and nature of the NSP.
> > > > > Do you have an
> > > > > example in mind?
> > > > >
> > > > > Cheers ...
> > > > >
> > > > >
> > > > >
> > > > > >Thanks,
> > > > > >-Shahram
> > > > > >_______________________________________________
> > > > > >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
> > >
> > > _______________________________________________
> > > 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
>
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3