Subject: Adopt PW-MPLS MIB as PWE3 WG document

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 06 May 2002 20:37:03 -0400

Hi,

	I would like to ask that draft-zelig-pw-mpls-mib-01.txt
  be adopted as PWE3 working group draft. This draft fits into
the foundation for the PWE3 management architecture as described
in the PWE3 Framework, and forms the connection between the
abstract PW VC and the MPLS transport. Since this document
shows how to hook the PW VC layer into the existing MPLS MIBs
(MPLS-LDP/LSR/TE), it does not depend on the working
group coming to a consensus on the various service-layer
approaches, and so we feel that it is appropriate to adopted it
at this time.

	--Tom

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.

---

From: "tom k. johnson" <[email-masked]>
Date: Tue, 7 May 2002 16:59:57 -0400

I (of course) agree!

-Tom

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Monday, May 06, 2002 8:37 PM
> To: [email-masked]
> Cc: David Zelig; Dave Danenberg
> Subject: [PWE3] Adopt PW-MPLS MIB as PWE3 WG document
> 
> 
> 
> 	Hi,
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 07 May 2002 18:09:23 -0400

And I ....

Thanks,
Andy

------

---

From: Luca Martini <[email-masked]>
Date: Tue, 07 May 2002 17:30:28 -0600

I agree.
Luca

---

From: "Ron Cohen" <[email-masked]>
Date: Wed, 8 May 2002 09:19:58 +0200

I agree

Ron

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Thomas D. Nadeau
> Sent: Tuesday, May 07, 2002 2:37 AM
> To: [email-masked]
>   be adopted as PWE3 working group draft. This draft fits 
> into the foundation for the PWE3 management architecture as 
> described in the PWE3 Framework, and forms the connection 
> between the abstract PW VC and the MPLS transport. Since this 
> document shows how to hook the PW VC layer into the existing 
> MPLS MIBs (MPLS-LDP/LSR/TE), it does not depend on the 
> working group coming to a consensus on the various 
> service-layer approaches, and so we feel that it is 
> appropriate to adopted it at this time.
> 
> 	--Tom
> 
> 
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 8 May 2002 13:31:15 +0300

I understand the place of this document. What is less clear to me is how would be managed a PWE3 entity that runs a transport different than MPLS? Is the management data model for PWE3 defined in any document? Or do we expect different MIB modules to bring together somehow the individual pieces of the puzzle?

Thanks,

Dan

> From: Ron Cohen [mailto:[email-masked]]
> Sent: Wednesday, May 08, 2002 10:20 AM
> To: 'Thomas D. Nadeau'; [email-masked]
> Cc: 'David Zelig'; 'Dave Danenberg'
> Subject: RE: [PWE3] Adopt PW-MPLS MIB as PWE3 WG document
> 
> 
> 
> I agree
> 
> Ron
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 08 May 2002 09:29:28 -0400

>I understand the place of this document. What is less clear to me is how 
>would be managed a PWE3 entity that runs a transport different than MPLS? 
>Is the management data model for PWE3 defined in any document?

         Yes. Look in the framework for that.

>Or do we expect different MIB modules to bring together somehow the 
>individual pieces of the puzzle?

         The architecture allows for additional transports other than
MPLS or L2TP in the future, simply by adding additional "glue"
MIBs which translate the transport-specific MIBs into the
pwVcTable entries.  From there any service can be attached that
is currently defined.

         --Tom

---

From: "Khalid Ahmad"<[email-masked]>
Date: Wed, 8 May 2002 16:11:06 -0400

Hi Tom,

as you know from the discussions going on the list there is presently no
clear view concerning the applications for the various services over MPLS
and the related interworking protocols associated with them.

Considering this, it seems to me premature to adopt the pw-mpls MIB draft as
WG documents at this stage.

I think we first need to converge on some well defind applacability
statements and related encap protocols for the services re ATM, FR, CES,
etc. before we define the related MIBs, would you not agree.

I always thought MIBs were derived from the services and not vice versa.

Regards,
Khalid

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Wednesday, May 08, 2002 9:29 AM
To: Romascanu, Dan (Dan)
Cc: Ron Cohen; [email-masked]; David Zelig; Dave Danenberg
Subject: RE: [PWE3] Adopt PW-MPLS MIB as PWE3 WG document

         --Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 08 May 2002 16:23:24 -0400

>Considering this, it seems to me premature to adopt the pw-mpls MIB draft 
>as WG documents at this stage.
>

         I agree with you about service-layer MIBs, which is why we are not 
asking
to adopt any service-level glue MIBs at this time.  However, the MIBs that 
we are
asking to adopt glue generic PW VCs to the already defined service layers 
(MPLS
and L2TP). These parts are well defined in the MPLS and L2TP MIBs as well as
in the PWE3 Framework; therefore, I do think that it is appropriate to 
adopt the
three documents I proposed at this time.

         --Tom

---

From: Shahram Davari <[email-masked]>
Date: Wed, 8 May 2002 13:36:54 -0700

But you have based your work (as indicated by references) on
many non-WG drafts (e.g. Martini) in these documents.

-Shahram

> Sent: Wednesday, May 08, 2002 4:23 PM
> To: Khalid Ahmad
> Cc: [email-masked]

---

From: "Khalid Ahmad"<[email-masked]>
Date: Wed, 8 May 2002 17:21:38 -0400

Hi Tom and pwe3 colleagues,

I have some difficulty to understand how the MIB for the PW (i.e. the
interworking LSP) can be entirely independant of the specific service it is
transporting.  

In the cases with which I am familiar, it seems the attributes of the
interworking LSP are somewhat closely related to the service carried (e.g.
ATM cell or frame, port mode, FR, etc) since it carries the service specific
protocol control information.

Im not sure its efficient to specify the MIB now, and we may find later to
have to modify it because of stuff that may emerge from the applications
being discussed.

I appreciate you have done much work on this, but what is the urgency for
specifying MIBs at this stage, I'm not sure ?

Regards,
Khalid

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Wednesday, May 08, 2002 4:23 PM
To: Ahmad, Khalid [CAR:CS40:EXCH]
Cc: [email-masked]
Subject: RE: [PWE3] Adopt PW-MPLS MIB as PWE3 WG document

         --Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 08 May 2002 19:10:47 -0400

>interworking LSP) can be entirely independant of the specific service it 
>is transporting.
>
>interworking LSP are somewhat closely related to the service carried
>(e.g. ATM cell or frame, port mode, FR, etc) since it carries the service 
>specific protocol control information.

         Please read the Framework, but in short, there is a generic VC 
layer that maps the service-specific
"thing" to the transport-specific "thing". The service-layer "thing" is 
well known for MPLS (i.e.: LDP,
TE), and arguably, the generic VC is fairly well understood (see the 
Framework).  What is not
well understood or defined in PWE3 is the service-layers, so we are waiting 
for those drafts to
come out.

         The framework section that explains the management architecture 
that hasn't changed much
for about a year now.  As Sharam pointed out, it was originally based on 
the Martini work, but from
what I can tell, none of the existing draft proposals really violate that 
model, at least from a management
perspective.

>have to modify it because of stuff that may emerge
>from the applications being discussed.

         The architecture allows for future service and transport layer 
changes. In fact, it allows for
an any-to-any model for managing a service mapped to a transport. This is 
quite useful as has
been indicated to myself and the other co-authors by service providers and 
management
application vendors. All that we are asking is to adopt the basic (and 
generic) framework pieces plus
the MPLS service piece.  No one is saying that it cannot be altered 
thereafter either.

>specifying MIBs at this stage, I'm not sure ?

         I and others have customers that are asking for these things. We 
need to get on with it.

         --Tom

---

From: Skip Booth <[email-masked]>
Date: Wed, 8 May 2002 21:59:54 -0400

>          I and others have customers that are asking for these things. We 

I agree with Tom.  The MIBs specified in these drafts provide a nice
framework to work within and IMO follows the layering model outlined for
the PWE3 work.  It is well suited for adding new transports types or
different PSN tunneling methods.

As we start to see shipping implementations of Martini and L2TPv3, I'd very
much like to see standards based work for the MIBs as well.  The
zelig/nadeau drafts provide that framework and by accepting them as WG
documents, we can give them the focus that they need.  Since I haven't seen
any alternate proposals out there for how to structure the MIBs, I see no
reason not to accept these as WG documents.  MIBs are certainly listed as a
item in the charter and in the framework document, so we have to start
somewhere :)

-Skip

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 09 May 2002 10:11:50 +0200

> Khalid Ahmad wrote:
> interworking LSP are somewhat closely related to the service carried (e.g. ATM
> cell or frame, port mode, FR, etc) since it carries the service specific
> have to modify it because of stuff that may emerge from the applications being
> discussed.

Remember that just because we accept a WG document, doesn't mean that it cannot
change. I sometimes think that far too much emphasis is placed on this
administrative step.

> specifying MIBs at this stage, I'm not sure ?

Believe me, having a WG MIB doc does not necessarily equate to urgency for
getting the MIB finished (sad to say)! I've seen WG MIB documents sit around for
a long, long, long, time before being completed...

---

From: "Brian Hassink" <[email-masked]>
Date: Thu, 9 May 2002 07:13:50 -0400

It was pointed out a while back that the existing MIB framework did not appear to support the binding of a VC to more than one PSN type.
 
The specific example cited was where you may want to simultaneously bind a MPLS VC (i.e. inner tunnel) to a pair of outer tunnels with different encapsulations (i.e. MPLS and GRE), where the GRE outer tunnel provided a best-effort backup for the traffic engineered MPLS outer tunnel.
 
Will this be addressed by the MIBs, or is this type of functionality not in scope?
 
Regards,
Brian

	-----Original Message----- 
	From: Thomas D. Nadeau [mailto:[email-masked]] 
	Sent: Wed 5/8/2002 7:10 PM 
	To: Khalid Ahmad 
	Cc: [email-masked] 
	Subject: RE: [PWE3] Adopt PW-MPLS MIB as PWE3 WG document

	         --Tom

---

From: David Zelig <[email-masked]>
Date: Thu, 9 May 2002 14:47:06 +0200

Brian,
We feel that a better approach to have a best effort backup for MPLS TE is
outer tunnel based on LDP - this is supported in the MIB and you do not need
to signal another PW label in different technology. If the GRE key field
will be equal to the VC label signaled via LDP - this can be added easily to
the MPLS-PW MIB. But in this respect except for the use of L2TP as one case
for IP PSN there is no clear definition for other options to IP PSN (is it
GRE? MPLS in IP? etc.).

If one think however that another solution is required, once we will have an
i-d in hand we can easily change the MIB to reflect it, still without the
need to change the basic MIB structure. 
Eventually, the MIBs will cover exactly what will be defined by the WG.

Thanks
David

> From: Brian Hassink [mailto:[email-masked]]
> Sent: Thursday, May 09, 2002 1:14 PM
> To: Thomas D. Nadeau; Khalid Ahmad
> Cc: [email-masked]
> It was pointed out a while back that the existing MIB 
> framework did not appear to support the binding of a VC to 
> more than one PSN type.
>  
> The specific example cited was where you may want to 
> simultaneously bind a MPLS VC (i.e. inner tunnel) to a pair 
> of outer tunnels with different encapsulations (i.e. MPLS and 
> GRE), where the GRE outer tunnel provided a best-effort 
> backup for the traffic engineered MPLS outer tunnel.
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 09 May 2002 09:15:06 -0400

>It was pointed out a while back that the existing MIB framework did not 
>appear
>to support the binding of a VC to more than one PSN type.

         This will work with the current framework with some minor 
modifications,
but I honestly don't see why you would want to do this. I have first of all,
never heard of any customer requirements to do this. Second, if you have
an MPLS LDP/TE transport connection, and want an explicit primary
path and a dynamic (best effort) backup path, why not just set up 2 TE tunnel
path options? Maybe I am wrong, but I fail to see how having a mixed PSN
connection across the same network would buy you anything.

>The specific example cited was where you may want to simultaneously bind a 
>MPLS VC (i.e. inner tunnel)
>to a pair of outer tunnels with different encapsulations (i.e. MPLS and 
>GRE), where the GRE
>outer tunnel provided a best-effort backup for the traffic engineered MPLS 
>outer tunnel.
>

         This is currently not in the scope of what we are working on, and 
the coauthors
have discussed  this after the question you referenced was posed.  We 
decided to not add this
explicitly at this point given the reasoning above.

         Since these are individual drafts, I don't see anything wrong with 
that approach
since we can do anything we feel is correct given our personal requirements in
individual submissions. If these were working group drafts, then we would 
have to address
this if the WG thought it was a viable and acceptable option.  This is one 
of the reasons why
these MIBs should be accepted now to get the ball rolling. As Mark just 
pointed out, this
will just make them more visible (not set in stone), and hopefully others 
will start contributing
to them and the general approach we have put forth.

         --Tom

---

From: "Brian Hassink" <[email-masked]>
Date: Thu, 9 May 2002 10:02:21 -0400

I think we're overlooking the case where outer tunnels are not necessarily signaled.

Following the example below, the customer may have elected to set up MPLS-TE tunnels manually (i.e. they're static, not signaled), and the dynamically routed IP tunnel, be it GRE or otherwise, is a last resort best-effort backup.

Putting the merits of this specific scenario aside for the moment, is it not worthwhile to have a framework that accomodates this degree of flexibility, especially since there's no impact, rather than one that is potentially short-sighted and precludes it?

Regards,
Brian

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Thursday, May 09, 2002 9:15 AM
To: Brian Hassink
Cc: Khalid Ahmad; [email-masked]
Subject: RE: [PWE3] Adopt PW-MPLS MIB as PWE3 WG document

         --Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 09 May 2002 11:11:52 -0400

>Following the example below, the customer may have elected to set up 
>MPLS-TE tunnels manually (i.e. they're static, not signaled), and the 
>dynamically routed IP tunnel, be it GRE or otherwise, is a last resort 
>best-effort backup.

         Even in this case, why couldn't they set up a path option on that 
tunnel as dynamic?
This achieves the exact same behavior, so I don't see the benefit.

>Putting the merits of this specific scenario aside for the moment, is it 
>not worthwhile to
>have a framework that accomodates this degree of flexibility, especially 
>since there's no impact,
>rather than one that is potentially short-sighted and precludes it?

         As has been mentioned several times, the framework does not 
preclude it; we
just chose not to put that in explicitly now. Adding it in the future (if 
the WG
thinks it is a good idea) is an easy change.

         --Tom

---

From: Eric Rosen <[email-masked]>
Date: Thu, 09 May 2002 11:17:13 -0400

Shahram> But you have  based your work (as indicated  by references) on many
Shahram> non-WG drafts (e.g. Martini) in these documents. 

There is  no rule  against referencing  non-WG drafts in  a WG  draft.  It's
quite common to do so.

---

From: Shahram Davari <[email-masked]>
Date: Thu, 9 May 2002 08:20:49 -0700

Sure, but when there are competing non-WG drafts, it does not feel right
to adapt a draft as a WG document that references (or is based on) only one of those 
competing drafts.

-Shahram

> From: Eric Rosen [mailto:[email-masked]]
> Sent: Thursday, May 09, 2002 11:17 AM
> To: Shahram Davari
> Cc: 'Thomas D. Nadeau'; Khalid Ahmad; [email-masked]
> Subject: Re: [PWE3] Adopt PW-MPLS MIB as PWE3 WG document 
> 
> 
>

---

From: "Brian Hassink" <[email-masked]>
Date: Thu, 9 May 2002 11:25:42 -0400

Please see comments below...

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Thursday, May 09, 2002 11:12 AM
To: Brian Hassink
Cc: [email-masked]
Subject: RE: [PWE3] Adopt PW-MPLS MIB as PWE3 WG document

>dynamically routed IP tunnel, be it GRE or otherwise, is a last resort 

Even in this case, why couldn't they set up a path option on that tunnel as dynamic? This achieves the exact same behavior, so I don't see the benefit.

[BH] My company appears to have customers that do. In any event, let's not get hung up on this particular example, it's the flexibility to do something like this that we're after.

>rather than one that is potentially short-sighted and precludes it?

As has been mentioned several times, the framework does not preclude it; we just chose not to put that in explicitly now. Adding it in the future (if the WG thinks it is a good idea) is an easy change.

[BH] That's fine. I probably shouldn't have brought this up in the context of trying to adopt these documents. It's really a discussion for the group, when and if these documents are adopted.

Regards,
Brian

---

From: Eric Rosen <[email-masked]>
Date: Thu, 09 May 2002 11:32:39 -0400

Shahram> when there are  competing non-WG drafts, it does  not feel right to
Shahram> adapt a  draft as a  WG document that  references (or is  based on)
Shahram> only one of those competing drafts. 

If the content of the draft is  at odds with the content of some other draft
that you like, then the technical  issue should be discussed so that one can
determine whether  the draft is  or is not  a good starting point.   If it's
just that you  think additional docs should be referenced,  then you can ask
the authors to do that. 

I  think that  people who  are used  to working  in certain  other standards
organizations keep trying to cite procedural issues that just don't exist in
the IETF.  This wastes everyone's time  as the only thing really of interest
here is the content.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 09 May 2002 14:08:57 -0400

At 11:25 AM 5/9/2002 -0400, Brian Hassink wrote:
>Even in this case, why couldn't they set up a path option on that tunnel 
>as dynamic? This achieves the exact same behavior, so I don't see the benefit.
>
>[BH] My company appears to have customers that do. In any event, let's not 
>get hung up on this particular example, it's the flexibility to do 
>something like this that we're after.

         If there are customers willing to buy boxes with this capability, then
I am cool with changing the PW-VC MIB to handle that case.

>As has been mentioned several times, the framework does not preclude it; 
>we just chose not to put that in explicitly now. Adding it in the future 
>(if the WG thinks it is a good idea) is an easy change.
>
>[BH] That's fine. I probably shouldn't have brought this up in the context 
>of trying to adopt these documents. It's really a discussion for the 
>group, when and if these documents are adopted.

         Yes, once adopted, we can certainly add additional features that 
the WG
wants added.

         --Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 09 May 2002 14:06:49 -0400

There are no competing drafts on how to approach the management
framework.  This is defined in a WG document already. This is all
that the drafts we are asking to be adopted do.

         --Tom

---

From: Shahram Davari <[email-masked]>
Date: Tue, 14 May 2002 09:58:36 -0700

OK. The following MIB objects needs WG consensus: 

1) PwVcType has types such as atmTransparent and ethernet/VLAN, which are not
   agreed by the WG. 
2) pwVCPriority: QoS issue has not be resolved by the WG yet. For example if Diffserv is 
   used the priority has no meaning.
3) PwVCType: mplsOverIp and Ip are not defined or agreed by the WG.

Following are my technical comments:

1) What is Global VC label space? Do you mean per-platform? if so please correct. 
2) The MTU is not applicable to some VC types, so why is it in PW-MIB instead of service MIB?
3) Why is the size of the L2TP session ID different between the pwVcOutboundVcLabel and pwVcinboundVcLabel?
4) MPLS LSR is not a good name, because it does not convey the proper information. You could use MPLS-LDP or MPLS non-TE. 
5) In page 7 of pw-mpls-mib: what is MPLS-LSP? did you mean MPLS-LSR?
6) In page 8 of pw-mpls-mib: what do you mean by combination of LDP and MPLS-TE? do you mean backup LSP is LDP based?
7) What is "active conservative mode"? And why is the Inbound group mandatory for it?
8) Can you give an example of what signaling protocol for VC setup may be a candidate
for strict vc lookup? 
9) Since DU LDP (as defined in Martini) can't support strict mode, then why is LDP mentioned
in the pwVcmplsInboundEntry?

-Shahram  

> Sent: Thursday, May 09, 2002 11:33 AM
> To: Shahram Davari

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 14 May 2002 16:29:28 -0400

>OK. The following MIB objects needs WG consensus:

         Sharam, although you bring up some interesting technical
questions (which I will get to in another email), they deflect the
actual question at hand. Technically nothing in the PW MIB drafts
need working group consensus until they become working group drafts
other than an agreement that the stuff in the draft is a reasonable point from
which to work (they are still individual submissions after all).  As has been
mentioned by many folks already, the question at hand is not whether
the documents are perfect, but instead whether or not these documents are a
reasonable place to start from.  Once accepted, there is no question in my
mind that they will need additional modifications to fit in with the other 
items
being worked on by the working group.

         Can the chair please comment on whether or not
consensus has been reached on the question of whether to
adopt the PW-MIB, PW-TC-MIB and PW-MPLS-MIB?

         --Tom

>3) Why is the size of the L2TP session ID different between the 
>pwVcOutboundVcLabel and pwVcinboundVcLabel?
>4) MPLS LSR is not a good name, because it does not convey the proper 
>information. You could use MPLS-LDP or MPLS non-TE.
>6) In page 8 of pw-mpls-mib: what do you mean by combination of LDP and 
>MPLS-TE? do you mean backup LSP is LDP based?

---

From: Shahram Davari <[email-masked]>
Date: Tue, 14 May 2002 13:38:01 -0700

Thom,

I have no problem with your MIB drafts. However, in the first 3 bullets I tried to show 
that they are not totally independent of the services (although I agree the service dependency
is not huge). 

If the WG and authors are ready to accept the fact that they may need to change parts of these documents
based on the outcome of the service definitions. Then there is no problem with accepting it as a WG document.

Do you agree?

Yours,
-Shahram

> Sent: Tuesday, May 14, 2002 4:29 PM
> To: Shahram Davari
> Cc: [email-masked]
> >2) pwVCPriority: QoS issue has not be resolved by the WG 
> yet. For example 
> >if Diffserv is
> >1) What is Global VC label space? Do you mean per-platform? 
> if so please 
> >correct.
> >2) The MTU is not applicable to some VC types, so why is it 
> in PW-MIB 
> >instead of service MIB?
> >8) Can you give an example of what signaling protocol for VC 
> setup may be 
> >a candidate
> >for strict vc lookup?
> >9) Since DU LDP (as defined in Martini) can't support strict 
> mode, then 
> >why is LDP mentioned

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 14 May 2002 16:45:28 -0400

>with accepting it as a WG document.

         Yes.

         --Tom

---

From: "Prayson Pate" <[email-masked]>
Date: Tue, 14 May 2002 17:19:21 -0400

I would like to add my voice to those who have expressed support for
accepting these documents as WG drafts.  There are some technical issues to
address, but there seems to be consensus that they are a very good starting
point.

Prayson

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Thomas D. Nadeau
> Sent: Tuesday, May 14, 2002 4:45 PM
> To: Shahram Davari
> Cc: [email-masked]
> >I have no problem with your MIB drafts. However, in the first 3
> bullets I
> >tried to show
> >based on the outcome of the service definitions. Then there is
> no problem
> >with accepting it as a WG document.
> >
> >Do you agree?
>
>          Yes.
>
>          --Tom
>
>
>
> >Yours,
> >-Shahram
> >
> >

---

From: Danny McPherson <[email-masked]>
Date: Tue, 14 May 2002 16:37:19 -0600

> adopt the PW-MIB, PW-TC-MIB and PW-MPLS-MIB?

I believe consensus is obvious.

Folks, please remember that the point of making a document a
WG document in the IETF is to foster input from the larger 
WG (and IETF) before moving things forward.  Just because
a draft becomes a WG document doesn't mean it's now set in 
stone, quite the contrary, actually.  It means that the draft
is now a WG document and input from the entire WG, not just
the authors, needs to be considered.

A number of folks have mentioned that we've been to strict
in accepting documents as WG items and looking back I tend
to agree.  In order to move things forward we need to try 
being a bit more liberal wrt adopting documents as WG items,
getting them more visibility and input from the WG and 
community, and making some progress.

-danny

---

From: David Zelig <[email-masked]>
Date: Wed, 15 May 2002 19:20:25 +0200

Shahram,
Thanks for the detailed review, we need these kinds of inputs in order to
progress!

See inside.

David

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Tuesday, May 14, 2002 6:59 PM
> To: [email-masked]'

>    used the priority has no meaning.
This item relates for the priority in establishment of the VC compared to
other VCs, and is not related to the QOS of the VC. It enables you to
control the set up priority in a similar way as defined for MPLS LSPs if
there are competing resources between multiple VCs.

> 3) PwVCType: mplsOverIp and Ip are not defined or agreed by the WG.

For 1) and 3) - these items will be resolved as the service specific and
unresolved PSN specific items will progress till the available WG documents
will proceed. We should consider these items as preliminary and I'll add
text to reflect it.

> if so please correct. 
OK

> in PW-MIB instead of service MIB?

Just to keep all signaling parameters in one place for implementation ease
and readability.

> 3) Why is the size of the L2TP session ID different between 
> the pwVcOutboundVcLabel and pwVcinboundVcLabel?
Typo

> 4) MPLS LSR is not a good name, because it does not convey 
> the proper information. You could use MPLS-LDP or MPLS non-TE. 

The name came for the fact that MPLS-LSR-MIB is the MIB module that control
non-TE applications, while MPLS-TE control the TE tunnel creation.

> 5) In page 7 of pw-mpls-mib: what is MPLS-LSP? did you mean MPLS-LSR?
Yes

> 6) In page 8 of pw-mpls-mib: what do you mean by combination 
> of LDP and MPLS-TE? do you mean backup LSP is LDP based?

Yes, I'll clarify it.

> 7) What is "active conservative mode"? And why is the Inbound 
It should be "manually configured strict mode"

> setup may be a candidate

The suggested RSVP-TE extensions in one of the i-ds (and I do not want to
open this issue again here...). We should have said in general "strict" and
not refer to manually configured/signaled as these are either rare cases or
proprietary implementations. My opinion is that strict mode is useful mainly
for security reasons (and done manually), and this is the reason we have
such option in the MIB.

> mode, then why is LDP mentioned
You may configured it manually if security is required.

Thanks
David

---

From: Shahram Davari <[email-masked]>
Date: Wed, 15 May 2002 12:06:49 -0700

Hi David,

> From: David Zelig [mailto:[email-masked]]
> Sent: Wednesday, May 15, 2002 1:20 PM
> To: Shahram Davari
> Cc: [email-masked]

Any comments?
 
> there are competing resources between multiple VCs.

Oh, then may be you should make it clear by calling it preemption priority.
But then the problem is that there are 2 priorities assigned to each
LSP: Holding and preemption priority, which one is this?

> non-TE applications, while MPLS-TE control the TE tunnel creation.

I did guess that, but still MPLS-LSR does not convey the proper info.

> > 5) In page 7 of pw-mpls-mib: what is MPLS-LSP? did you mean 

Also there is another one in page 13 of pw-mpls-mib.
> for security reasons (and done manually), and this is the 

I agree strict mode is useful.

> You may configured it manually if security is required.

You mean configure the LDP manually or the PW manually?

Yours,
-Shahram

---

From: [email-masked]
Date: Thu, 16 May 2002 11:31:37 +0100

David, just 1 question...regards, Neil
<snipped>
> LSP: Holding and preemption priority, which one is this?
NH=>What is the relationship of this parameter for the client VC LSP
compared to the similar parameter for it's server tunnel LSP?

---

From: David Zelig <[email-masked]>
Date: Sun, 19 May 2002 10:40:28 +0200

Shahram,

See inside (snipped all agreed items)
> LSP: Holding and preemption priority, which one is this?
Good point - we probably need both. I'll also change the names to avoid
confusion.

> You mean configure the LDP manually or the PW manually?
I mean configure the association between the outer tunnel and the VC
manually. This is independent of the way the VC labels are known to the PE.

David

---

From: David Zelig <[email-masked]>
Date: Sun, 19 May 2002 10:54:23 +0200

Neil,

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, May 16, 2002 12:32 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]

I believe it depends on the model used for outer tunnel creation:
Fixed pre-configured tunnels (with BW, COS, etc...): In this case the outer
tunnels can be viewed as pipes to the destination PE, and the VC
setup/holding control which VCs to be created/pre-empted. 

On demand tunnels or one-to-one mapping between the PW and an outer tunnel:
Than there is no real meaning for the VC preemption, since it is covered by
the outer tunnel properties (unless internal PE resources may be an issue).

David

---

From: [email-masked]
Date: Mon, 20 May 2002 04:33:56 +0100

Thanks David.....please see minor further remarks below.

regards, Neil

David Zelig wrote 19 May 2002 09:54
> setup/holding control which VCs to be created/pre-empted.
NH=> Agreed.....that is exactly what the outer tunnels are, ie a server
layer trail whose clients inherit the survivability/QoS defined for that
tunnel.
> the outer tunnel properties (unless internal PE resources may 
NH=> Agreed....this was the point I wanted to see recognised.  Put another
way, the higher client LSPs only have context within the lower server tunnel
LSP, so any notion of pre-emption would have no relevance to the general
MPLS network and population of LSPs therein, ie only applies within the
constraint of the tunnel.