Subject: RE: [PWE3] NSP signaling

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 8 Oct 2002 09:29:48 +0200

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:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: Chris Metz [mailto:[email-masked]]
> Sent: Monday, October 07, 2002 5:39 PM
> To: Shahram Davari
> Cc: [email-masked]'; [email-masked]
> 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:[email-masked]]
> > > Sent: Monday, October 07, 2002 9:40 AM
> > > To: Shahram Davari
> > > Cc: [email-masked]'; [email-masked]
> > > 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
> > > >[email-masked]
> > > >https://www1.ietf.org/mailman/listinfo/pwe3
> > >
> >_______________________________________________
> >pwe3 mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/pwe3
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Chris Metz <[email-masked]>
Date: Tue, 08 Oct 2002 11:51:05 -0400

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

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.

Cheers ...