Subject: RE: Re: I-D ACTION: draft-martini-pwe3-MH-PW-requirements-00.txt

From: [email-masked]
Date: Mon, 7 Feb 2005 06:23:25 -0500

Comments in line.

Thanks,
Nabil

|---------+---------------------------->
|         |           "David McDysan"  |
|         |           <dave.mcdysan@mci|
|         |           .com>            |
|         |                            |
|         |           01/19/2005 12:49 |
|         |           PM               |
|         |                            |
|---------+---------------------------->
  >--------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                            |
  |       To:       "'Luca Martini'" <[email-masked]>, "'Sasha Vainshtein'" <[email-masked]>                                             |
  |       cc:       [email-masked], [email-masked], [email-masked], "'Alik Shimelmits'" <[email-masked]>, "'PWE3 WG      |
  |        (E-mail)'" <[email-masked]>, [email-masked], Nabil N. Bitar/EMPL/MA/Verizon@VZNotes, [email-masked],                   |
  |        [email-masked], [email-masked], [email-masked], [email-masked], "'Sharon Galtzur'"     |
  |        <[email-masked]>, "'Ping Pan'" <[email-masked]>, [email-masked], [email-masked], [email-masked],      |
  |        [email-masked]                                                                                                         |
  |       Subject:  RE: [PWE3] Re: I-D ACTION: draft-martini-pwe3-MH-PW-requirements-00.txt                                                    |
  >--------------------------------------------------------------------------------------------------------------------------------------------|

Some additional comments on draft-martini-pwe3-MH-PW-requirements-00.txt
not
covered in previous posts.

Dave

Section 5 Use cases, iv, PWs in Metro networks

Suggest adding a sentence stating that the topology that connects a U-PE
access metro device to an S-PE metro aggregation may be simple (e.g.,
single
homed from a packet routing perspective) and that restoration may be
handled
at lower layers (e.g., SONET/SDH protection).

NB> Can add that. Hoever, a valid configuration is also to setup a backup
PW in certain cases if one
NB> is to protect against S-PE failure.

Section 6.2 Traffic Engineering

Suggest stating the full set of TE parameters: capacity (at least average
rate, possibly peak rate), burst duration (token bucket depth). Has the use
of affinities (i.e., colors) been considered to support the diversity
requirement in section 6.4, routing?

NB> This is obviously important in the dynamic signaling of the PW (i.e.,
no
NB> static provisioning at S-PEs). We can specify traffic parameters in the
doc.
NB> However, that raises another issue about mapping from the native AC to
the
NB> PW parameters that would need to mentioned as well. Any thoughts on
that?

Section 6.3 QoS

This discussion needs to be converted into requirements language. Two
requirements I read out of this are:
             1) Mandatory request for QoS - if this cannot be met, then the
MH-PW
attempt is rejected
             2) Desirable request for QoS - if this cannot be met, then
another
QoS characteristic can be provided. Suggest that in this case notification
indicate the type of QoS that was provided. This would in general need to
be
a list if a number of domains are traversed.

NB> We should tighten the anguage on QoS. I thought (1) is covered, but
will doublecheck. Are you suggesting in (2)
NB> (2) seems to add more complexity to the setup process and I am not sure
that is needed.

Of course, need to more precisely define what is meant by QoS and what
standard convention would be used to communicate it.

NB> The question in this case is whether we should signal delay and jitter
requirements. If we do,
NB> the remaining budget should be carried in the setup of the PW to help
the S-PE select
NB> a path. This will imply a speciic way of setting up the MH-PW.
NB> The alternative is to be more laxed and signal the CoS only and assume
that the performance parameter bounds
NB> are implicit in that CoS definition.

Fourth paragraph: Need more descriptive text on BW broker. Is there a
reference to this concept that provides defines the concept and the
proposed
protocols? How would the BW broker interact with routing?

6.4 Routing

Suggest adding a mandatory (SHALL) requirement where the sequence of S-PEs
is explicitly specified.

<NB> Specifying the sequence of S-PEs in the MH-PW path should be an option
that
<NB> contrain the path of a MH-PW. This is equivalent to adding an ERO and
applies
<NB> in the single-ended signaling requirement. Will work that in the
draft.

There are at least two ways of implementing this; via an object in the PW
signaling message, or OSS provisioning of the intermediate S-PEs with the
S-PE next hop using (part of) the generic FEC, possibly AGI to identify
this
explicit route.

This explicit routing specification of S-PEs does not meet all resiliency
scenarios, but would be useful in scenarios where topology and alternate
routes are limited (e.g., a metro access network).

<NB> It does help setting specifying a diversified alternate path for a
backup.

As mentioned in earlier posts, the general problem of designing another
level of S-PE routing is not trivial and a simple solution that meets a
simpler network environment as a subset of the full solution is desirable.

<NB> Doesn't the static stitching at S-PEs of MH-PW segments satisfy this?

---

From: David McDysan <[email-masked]>
Date: Wed, 09 Feb 2005 09:56:10 -0500

Nabil,

Trimming distro to pwe3. A few responses in line below.

Thanks,

Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, February 07, 2005 6:23 AM
> To: David McDysan
> Cc: 'Alik Shimelmits'; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 'Luca 
> Martini'; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; 'Ping Pan'; 'PWE3 WG 
> (E-mail)'; [email-masked]; [email-masked]; 'Sasha 
> Vainshtein'; 'Sharon Galtzur'; 
> [email-masked]; [email-masked]
> Subject: RE: [PWE3] Re: I-D ACTION: 
> draft-martini-pwe3-MH-PW-requirements-00.txt
> 
> 
> 
> 
> 
> 
> Comments in line.
> 
> Thanks,
> Nabil
> 
> 
> 
>   |       Subject:  RE: [PWE3] Re: I-D ACTION: 
> draft-martini-pwe3-MH-PW-requirements-00.txt                  
> 
> 
> 
> 
> Some additional comments on 
> draft-martini-pwe3-MH-PW-requirements-00.txt
> not
> Suggest adding a sentence stating that the topology that 
> connects a U-PE access metro device to an S-PE metro 
> aggregation may be simple (e.g., single homed from a packet 
> routing perspective) and that restoration may be handled at 
> lower layers (e.g., SONET/SDH protection).
> 
> NB> Can add that. Hoever, a valid configuration is also to setup a 
> NB> backup

Agreed. Suggest that the document mention both cases: that is, U-PE homed to
a single S-PE and U-PE homed to two or more S-PEs.

> Suggest stating the full set of TE parameters: capacity (at 
> least average rate, possibly peak rate), burst duration 
> (token bucket depth). Has the use of affinities (i.e., 
> colors) been considered to support the diversity requirement 
> in section 6.4, routing?
> 
> 
> NB> This is obviously important in the dynamic signaling of the PW 
> NB> (i.e.,
> no
> NB> static provisioning at S-PEs). We can specify traffic 
> parameters in 
> NB> the
> doc.
> NB> However, that raises another issue about mapping from the 
> native AC 
> NB> to
> the

I'm not sure that I understand the question about mapping native Attachment
circuit (AC) to the PW parameters with respect to TE parameters. One that
seems obvious is that the peak rate is less than or equal to the AC physical
transmission rate. If you have some other examples in mind, please
elaborate.

> 
> Section 6.3 QoS
> 
> This discussion needs to be converted into requirements 
> language. Two requirements I read out of this are:
>              1) Mandatory request for QoS - if this cannot be 
> met, then the MH-PW attempt is rejected
>              2) Desirable request for QoS - if this cannot be 
> met, then another QoS characteristic can be provided. Suggest 
> that in this case notification indicate the type of QoS that 
> was provided. This would in general need to be a list if a 
> number of domains are traversed.
> 
> NB> (2) seems to add more complexity to the setup process and 
> I am not 
> NB> sure
> that is needed.

My comment was that requirements need to use SHALL, SHOULD, MAY. 

A way of simplifying this could be if originator signals mandatory QoS, and
if that fails (need to have indication in signaling that indicates the
reason) then originator resignals without QoS request. I think a similar
approach was discussed for OAM on the list.

> 
> Of course, need to more precisely define what is meant by QoS 
> and what standard convention would be used to communicate it.
> 
> NB> The question in this case is whether we should signal delay and 
> NB> jitter
> requirements. If we do,
> NB> the remaining budget should be carried in the setup of the PW to 
> NB> help
> the S-PE select
> NB> a path. This will imply a speciic way of setting up the 
> MH-PW. The 
> NB> alternative is to be more laxed and signal the CoS only and assume

As Jerry Ash pointed out, both of these methods are covered in the following
NSIS draft:

http://ietf.org/internet-drafts/draft-ash-nsis-y1541-qsp-00.txt.

Suggest referencing this draft in the next version.

Signaling the accumulated QoS parameter (latency, latency variation, loss,
etc.) is more general, yet more complex. The use of certain class or service
(CoS) (e.g., Y.1541) seems to implicitly assume a reference configuraiton,
which may or may not be appropriate. If this CoS method is used, would be
useful to track the domains traversed so that it could be mapped against the
reference model.

Suggest that both methods: accumulate QoS parms and use CoS be mentioned in
the next version. 

> 
> Fourth paragraph: Need more descriptive text on BW broker. Is 
> there a reference to this concept that provides defines the 
> concept and the proposed protocols? How would the BW broker 
> interact with routing?
> 
> 6.4 Routing
> 
> Suggest adding a mandatory (SHALL) requirement where the 
> sequence of S-PEs is explicitly specified.
> 
> <NB> Specifying the sequence of S-PEs in the MH-PW path 
> should be an option that <NB> contrain the path of a MH-PW. 
> This is equivalent to adding an ERO and applies <NB> in the 
> single-ended signaling requirement. Will work that in the draft.

Suggest that the protocol definition must support this capability (SHALL),
however, the object and procedures need not be supported in every
implementaiton (MAY).

> 
> There are at least two ways of implementing this; via an 
> object in the PW signaling message, or OSS provisioning of 
> the intermediate S-PEs with the S-PE next hop using (part of) 
> the generic FEC, possibly AGI to identify this explicit route.
> 
> This explicit routing specification of S-PEs does not meet 
> all resiliency scenarios, but would be useful in scenarios 
> where topology and alternate routes are limited (e.g., a 
> metro access network).
> 
> <NB> It does help setting specifying a diversified alternate 
> path for a backup.
> 
> As mentioned in earlier posts, the general problem of 
> designing another level of S-PE routing is not trivial and a 
> simple solution that meets a simpler network environment as a 
> subset of the full solution is desirable.
> 

Partially. Believe this approach does not address at least the following
issues: discovering S-PEs, selecting a path that meets constraints (QoS, OAM
capability, diversity, etc.), minimizing number of OSS touches (every
stitching point must be configured).

---

From: Seung Yeop Yang <[email-masked]>
Date: Sun, 13 Feb 2005 02:37:59 -0800 (PST)

Hi-

How about putting PW protection switching requirements in the document? 

++++++++++++++++++++++++++++++++++++++++++++++++++++++ 

6.7 Protection Switching Requirements

As PWE3 can provide a transport service for carrier L2 services, it is required that PWE3 should provide “carrier-class” availability. 

High availability can be achieved through 1) increasing mean time between failure (MTBF), 2) decreasing mean time to repair (MTTR), or providing redundancy such as protection switching. 

This PW protection switching is to apply primarily to the situations where a underlying PSN protection switching does not exist or does not fulfill the condition of availability that is supposed to be provided by each emulated service.

PW protection switching should be independent from underlying PSN’s fault recovery procedures, but can coexist or corporate with them.

PW protection switching can provide a 1+1 or an m:n type protection.

PW protection switching can protect a complete multi-hop PW (MH-PW) or the segment of it.

PW protection switching may use PW OAM procedures to detect failures or service degradataions, or to switching to protecting entities for end-to-end or segment of MH-PW.

PW protection switching may provide revertive and non-revertive switching.

PW protection switching does not preclude lockout of protection or forced switching by operator.

PW protection switching may provide “hold-off” time to delay beginning of the protection action.

PW protection switching can provide hitless protection switching.

++++++++++++++++++++++++++++++++++++++++++++++++++++++ 

Regards,

Seung Yeop.

---------------------------------
Do you Yahoo!?
 Yahoo! Search presents - Jib Jab's 'Second Term'

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3