Subject: NSP signaling

From: Shahram Davari <[email-masked]>
Date: Fri, 4 Oct 2002 15:07:52 -0700

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. 

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?

Thanks,
-Shahram

---

From: Chris Metz <[email-masked]>
Date: Mon, 07 Oct 2002 09:39:45 -0400

Shahram-

At 03:07 PM 10/4/2002 -0700, Shahram Davari wrote:
>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.

>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

---

From: Shahram Davari <[email-masked]>
Date: Mon, 7 Oct 2002 07:07:15 -0700

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 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-
> 
> >In the PW layering architecture a PE is divided in to PREP 
> (pre-processor) 
> >and IW.
> >Draft-rosen and draft-martini define signaling methods for 
> communication 
> >between IWs or forwarders.
> >
> >I was wondering in which WG should this type of signaling be 
> defined? and 
> >has anybody defined

---

From: Chris Metz <[email-masked]>
Date: Mon, 07 Oct 2002 11:38:49 -0400

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

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 ...

---

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.)

> Sent: Monday, October 07, 2002 5:39 PM
> To: Shahram Davari
> Subject: RE: [PWE3] NSP signaling
> 
> 
> Sharam-
>

---

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 ...

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 8 Oct 2002 18:22:04 +0200

Chris and all,
Please see some comments inline.

With best regards,
                                   Sasha Vainshtein

> Sent: Tuesday, October 08, 2002 5:51 PM
> To: Sasha Vainshtein
> Cc: Shahram Davari; [email-masked]'; [email-masked]
If it exists natively. I assume that if it doesn't exist, you
do not invent it for the PW use.
> 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".