Subject: Comments on draft-martini-pwe3-mh-pw-requirements-01.txt

From: [email-masked]
Date: Tue, 8 Mar 2005 11:22:04 -0000

Colleagues,

This version of the draft looks much better than the -00 versino, however I still have a couple of comments on it...

Section 6.4 (MS-PW Setup Mechanisms) states:
"There are four different SS-PW signaling protocols that are defined to signal PWs:
        -i. Static configuration of the SS-PW (MPLS or L2TPv3).
       -ii. LDP using PWid FEC 128
      -iii. LDP using the generalized PW FEC 129
       -iv. L2TPv3
Any combination of these signaling protocols MUST be supported."

While I believe the intent of this requirement is laudable I think it's a bit strong.  The requirement as it stands implies to me that upto 12 signalling interworking combinations MUST be supported which is quite a lot of work & additional complexity to mandate/implement/deploy.  How about making it a SHOULD or a MAY?

Section 7 (Operations and Maintenance (OAM)), requirement -viii states:
"All PE routers along the MS-PW MUST agree on a common PW OAM mechanism to use to the MS-PW."

This is very similar to Section 6.6., requirement -vii in the -00 draft on which I commented:
"I can see what this is trying to achieve and tend to agree (i.e. let's try
and interwork as little as possible and just use best of breed functional
components) but it somewhat contradicts section 5, use case -iii (PSN
Internetworking - leaving aside that PSN interworking using MH-PWs is
likely IMO to be a something of a nightmare) - i.e. it's OK to use MH-PWs
to interwork between different PWE3 signalling protocols and PSN types but
not different OAM types/mechanisms?  Is section 6.6., requirement -vii
actually achieveable when PSN internetworking is being performed (e.g. is
it possible to use the same OAM mechanism (VCCV?!?) over both LDP and
L2TPv3 PWs)"

and Matthew Bocci responded:
"MB> i have a similar question and would appreciate feedback from the list.
Ideally, I think we want to minimise the amount interworking that goes on
at the S-PE, which means avoiding using different PW OAM mechanisms either side of an S-PE. I don't think this imposes restrictions on the PSN OAM on either side."

I think this strengthens my argument above re: MS-PW setup - if the intention is to minimise the amount of interworking perfromed at a S-PE and therefore avoid using different PW OAM mechanisms either side of a S-PE why not apply the same approach to the PW signalling protocol and try and minimise the amount of signalling protocol interworking required rather than mandating that any combination of signalling protcol interworking MUST be supported (as is currently the case)?

Thanks
Ben

-- 
Ben Niven-Jenkins
Networking Specialist, BT Exact

e-mail: [email-masked]
tel: +44(0) 1473 648225
mob: +44(0) 7918 077205

pp34/161 B81 Callisto House, Adastral Park, Martlesham, Ipswich IP5 3RE, UK

BT Exact is a trademark of British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no. 1800000

---

From: "Nurit Sprecher" <[email-masked]>
Date: Tue, 8 Mar 2005 17:47:13 +0200

Hi,

Personally I don't understand why a requirement draft for MH PW should
have any restriction or requirement on the protocol type to be used.
Isn't it part of the solution drafts? 

In addition, it may be that for a TE PW for example, one on the
specified protocols is not a natural solution. 

Some other comments:

1.    In section 6.3, it is written: "The ability to associate the
appropriate QoS class with each PW PDU is a strict requirement at each
router...." 

a.    I agree with this requirement. However, note that it may probably
be required to signal the required QoS class (diffserv information).

b.    It may also be that the MS PW has a requirement for a specific
Diffserv-TE class. This TE class should be signaled as well in addition
to the BW requirements. The routers should support the extensions for
Diffserv-TE.

2.    It is written: "A per PW/QoS class setup priority should be
provided"

a.    What about the holding priority?

b.    It should be required that the appropriate tunnel is selected also
based on this traffic priorities.

3.    In the TE requirements I miss the requirements for
administratively setting and signaling of explicit routes for the MS
PWs. It may be required for the PW to traverse certain S-PEs (for
security or other purposes).

4.    The following comments refer to the resiliency section:

a.    "The backup and primary paths should have the ability to traverse
separate S-PEs"

                                                          i.
Defining the explicit routes for the PWs may help in this.

                                                      ii.      In order
to guarantee that the pw is protected, it may be required to setup a
disjoint path for the backup end-to-end PW, and to set it in advance.

b.    It is defined: "When a MS-PW is tunneled over PSN tunnels with
fast reroute capability..."

                                                          i.      I
think that this should be one of the requirements for the MS PW as well,
that traffic is not disturbed for more than 50ms in case of a failure,
that is the PSN tunnels that should be selected should be protected by a
FRR mechanism. This information should be signaled as well.

Thanks and best regards,

Nurit.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, March 08, 2005 1:22 PM
To: [email-masked]
Subject: [PWE3] Comments on draft-martini-pwe3-mh-pw-requirements-01.txt

Colleagues,

This version of the draft looks much better than the -00 versino,
however I still have a couple of comments on it...

"There are four different SS-PW signaling protocols that are defined to
signal PWs:

       -iv. L2TPv3

While I believe the intent of this requirement is laudable I think it's
a bit strong.  The requirement as it stands implies to me that upto 12
signalling interworking combinations MUST be supported which is quite a
lot of work & additional complexity to mandate/implement/deploy.  How
about making it a SHOULD or a MAY?

"All PE routers along the MS-PW MUST agree on a common PW OAM mechanism
to use to the MS-PW."

This is very similar to Section 6.6., requirement -vii in the -00 draft
on which I commented:

"I can see what this is trying to achieve and tend to agree (i.e. let's
try

and interwork as little as possible and just use best of breed
functional

likely IMO to be a something of a nightmare) - i.e. it's OK to use
MH-PWs

to interwork between different PWE3 signalling protocols and PSN types
but

actually achieveable when PSN internetworking is being performed (e.g.
is

L2TPv3 PWs)"

"MB> i have a similar question and would appreciate feedback from the
list.

Ideally, I think we want to minimise the amount interworking that goes
on

at the S-PE, which means avoiding using different PW OAM mechanisms
either side of an S-PE. I don't think this imposes restrictions on the
PSN OAM on either side."

I think this strengthens my argument above re: MS-PW setup - if the
intention is to minimise the amount of interworking perfromed at a S-PE
and therefore avoid using different PW OAM mechanisms either side of a
S-PE why not apply the same approach to the PW signalling protocol and
try and minimise the amount of signalling protocol interworking required
rather than mandating that any combination of signalling protcol
interworking MUST be supported (as is currently the case)?

Thanks

Ben

-- 

Ben Niven-Jenkins

tel: +44(0) 1473 648225

mob: +44(0) 7918 077205

pp34/161 B81 Callisto House, Adastral Park, Martlesham, Ipswich IP5 3RE,
UK

_______________________________________________

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: Luca Martini <[email-masked]>
Date: Mon, 21 Mar 2005 14:40:45 -0700

Nurit Sprecher wrote:

> Isn't it par
> of the solution drafts?
Nurit,

This document does not express requirements for PW, but only for 
inter-domain/AS PWs. I believe that the requirement you are referring 
to, simply states that all current kinds of PWs should be supported. 
This does not mean that we cannot come up with yet another PW setup and 
maintenance protocol, and then support that one as well.

> be required to signal the required QoS class (diffserv information).
why ? a configuration with a central provisioning server is perfectly 
acceptable. This is what is used in the transmission world today.
Whether we need to signal QoS or not will depend on the specific solution.

> Diffserv-TE class. This TE class should be signaled as well in 
> addition to the BW requirements. The routers should support the 
> extensions for Diffserv-TE.
>
again this is a solution, not a requirement. There might not even be a 
protocol to signal BW requirements ....

> 2. It is written: "A per PW/QoS class setup priority should be provided"
>
I will add it.

> based on this traffic priorities.
??? are you talking about something different then traffic class ?

> 3. In the TE requirements I miss the requirements for administratively 
> setting and signaling of explicit routes for the MS PWs. It may be 
> required for the PW to traverse certain S-PEs (for security or other 
> purposes).
>
the first part , is a solution, while the second part is a requirement. 
I'll add it as follows :
It may be required for the PW to traverse a specific S-PE to enforce 
security, or administrative policies.

> i. Defining the explicit routes for the PWs may help in this.
>
> ii. In order to guarantee that the pw is protected, it may be required 
> to setup a disjoint path for the backup end-to-end PW, and to set it 
> in advance.
>
> b. It is defined: "When a MS-PW is tunneled over PSN tunnels with fast 
> reroute capability…"
>
> i. I think that this should be one of the requirements for the MS PW 
> as well, that traffic is not disturbed for more than 50ms in case of a 
> failure, that is the PSN tunnels that should be selected should be 
> protected by a FRR mechanism. This information should be signaled as well.
>
Note that PSN tunnels have fast-reroute capability not PWs.

Thanks.

Luca

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of [email-masked]
> While I believe the intent of this requirement is laudable I think 
> it's a bit strong. The requirement as it stands implies to me that 
> upto 12 signalling interworking combinations MUST be supported which 
> is quite a lot of work & additional complexity to 
> mandate/implement/deploy. How about making it a SHOULD or a MAY?
>
> intention is to minimise the amount of interworking perfromed at a 
> S-PE and therefore avoid using different PW OAM mechanisms either side 
> of a S-PE why not apply the same approach to the PW signalling 
> protocol and try and minimise the amount of signalling protocol 
> interworking required rather than mandating that any combination of 
> signalling protcol interworking MUST be supported (as is currently the 
> case)?
>
> Thanks
>
> Ben
>
> -- 
>
> Ben Niven-Jenkins
>
>------------------------------------------------------------------------
>

---

From: "Nurit Sprecher" <[email-masked]>
Date: Tue, 22 Mar 2005 12:08:07 +0200

Hi Luca,

Thanks for your response. 

Please see my comments in-line ([Nurit].....\[Nurit]).

Best regards,

Nurit.

-----Original Message-----
From: Luca Martini [mailto:[email-masked]] 
Sent: Monday, March 21, 2005 11:41 PM
To: Nurit Sprecher
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] Comments on
draft-martini-pwe3-mh-pw-requirements-01.txt

Nurit,

[Nurit]

Section 6.4 (MS-PW Setup Mechanisms) states that "There are four
different SS-PW signaling protocols that are defined to signal PWs:
........ Any combination of these signaling protocols MUST be
supported."

This is a requirement to support specific protocols for MH-PWs. If we
include requirements for specific protocols in the requirement
specification, then when coming up with a new protocol, the requirement
spec should be updated to support the new protocol as well. If the
requirement for the protocols is in the draft, I think that it should be
clarified for which case which protocol should be supported (for
example, for TE PW it may be that certain protocols are not appropriate,
etc.), and it should be specified that other protocols (that are
compliant to the requirement) are possible as  well. And when such a
protocol comes up, the requirement spec should be updated with the new
requirement for the new protocol.

\[Nurit]

Whether we need to signal QoS or not will depend on the specific
solution.

[Nurit]

We could use the provisioning server to configure the S-PEs with the
PWs' information in their entirety as well (e.g. the QoS parameters,
labels, etc.) and avoid the necessity to signal the PW at all. One of
the missions of the control plane is to minimize the required
configuration throughout the network and limit it to the edges as much
as possible. Even for TE tunnels we have Diffserv Object to signal this
information as well and a configuration server is not used for it. Each
emulated service may have requirement for specific diffserv/diffserv-TE
class. Especially for L-LSP service this information should signaled.

\[Nurit]

[Nurit]

I agree about the solution part, but as we have requirements for QoS
parameters (like guaranteed BW, etc.), there may be requirements for
specific Diffserv-TE class.

\[Nurit]

provided"

I will add it.

[Nurit]

Thanks.

\[Nurit]

[Nurit]

I am talking about holding priority for example. The PW can not transmit
a TE tunnel whose holding priority is smaller than the holding priority
defined for the PW (service), otherwise tunnel's pre-emption can violate
the service.

\[Nurit]

I'll add it as follows :

[Nurit]

I agree, Thanks.

\[Nurit]

> reroute capability..."

[Nurit]

You are right, but the service (i.e. the PW) has requirement for
resiliency. For example, the SLA for the service may state that upon a
failure the service must not be disturbed for more than 50 ms. In such a
case, this information should be signaled such the S-PEs can select a
tunnel which is protected by a FRR mechanism. Otherwise, what are the
criteria for the S-PEs to select a tunnel which is protected or not?  

\[Nurit]

[Nurit]

In addition, it may be that we need also requirements for resource
classes (with affinity attributes). This should be considered as well.
\[Nurit]

Thanks.

Luca

 

> Subject: [PWE3] Comments on
draft-martini-pwe3-mh-pw-requirements-01.txt

> "There are four different SS-PW signaling protocols that are defined 

> to signal PWs:

> "All PE routers along the MS-PW MUST agree on a common PW OAM 

> mechanism to use to the MS-PW."

> This is very similar to Section 6.6., requirement -vii in the -00 

> draft on which I commented:

> "I can see what this is trying to achieve and tend to agree (i.e. 

> let's try

functional

MH-PWs

but

is

on

> pp34/161 B81 Callisto House, Adastral Park, Martlesham, Ipswich IP5 

> 3RE, UK