[IPORPR] RE: [RPRWG] IPoRPR initial draft

George,

Thanks for the comments.

We need to clean up the identification of optional & mandatory in
section 1.2 as you suggest.

On the DSCP & EXP mapping to service classes, the intent of this
document is to define the default mapping.  Vendors can do what they
want -- but should use the mapping in this document if they want to be
'compliant and interoperable'.  We'll add some text to this effect.

On ringlet selection, there is no MPLS control of the direction in this
document per the charter.  To progress this, the plan is to lay out the
reasons for doing this in the next document.

Cheers,
Glenn.

________________________________

From: owner-stds-802-17@ieee.org [mailto:owner-stds-802-17@ieee.org] On
Behalf Of George Suwala (gsuwala)
Sent: Tuesday, July 19, 2005 2:30 PM
To: STDS-802-17@listserv.ieee.org
Subject: Re: [RPRWG] IPoRPR initial draft

Glenn, Marc,

Good and easy to read document. Some comments:

- 1.2 IEEE 802.17 MAC Service

I would specify  which 3 parameters are mandatory

- Table 3 DSCP Mapping

I would add a comment that this is a default mapping, but not the only
one possible, vendors could choose to add configuration commands to
re-map differently 

- Table 4 EXP mapping

Same comment as for Table 3

- 3.2. Should we say more about control of the ringlet selection? For
example a mechanism for MPLS TE backup tunnel (or any other diverse
routing path) placement through mapping into the opposite ringlet to the
one MAC would select?

thanks

George

________________________________

	From: owner-stds-802-17@ieee.org
[mailto:owner-stds-802-17@ieee.org] On Behalf Of Ghanwani, Anoop
	Sent: Monday, July 18, 2005 10:41 AM
	To: STDS-802-17@listserv.ieee.org
	Subject: Re: [RPRWG] IPoRPR initial draft

	Hi Glenn,

	I think it would really help readability if you can find a
	way to put the PHB names in...just maybe in parenthesis
	or even on the line following the DSCP.  All that is
	needed is something like:

	110000 - EF
	xxxxxxx - AF11, etc.

	Otherwise, the reader would be forced to have a copy of 
	the DiffServ RFC handy in order to understand this table.

	Yes, a clarification with respect to what the table
	applies to is needed.  In fact, you might need a second
	table to talk about L-LSPs since they encode 3 levels
	of drop precedence in the EXP bits for AF which then 
	need to be mapped to the 2-levels supported in 802.17.

	I think it would be better to reword the security section
	as follows.
	"This draft does not introduce any new security concerns
	for IEEE 802.17 networks. Some of the existing vulnerabilities
	of IEEE 802.17 networks include: ...".

	Anoop

________________________________

	From: owner-stds-802-17@ieee.org
[mailto:owner-stds-802-17@ieee.org] On Behalf Of Glenn Parsons
	Sent: Monday, July 18, 2005 9:38 AM
	To: STDS-802-17@listserv.ieee.org
	Subject: Re: [RPRWG] IPoRPR initial draft

	Anoop,

	On Table 3 we could not really fit the PHB in the ASCII table
without making it look too squished, so it was left out.

	On LSPs, do you simply want to note that mapping applies to
E-LSPs?

	And the security section is intentionally thick since we cannot
say there are no risks.  But perhaps the line you are looking for is the
second sentence in item 4 which should be the closing paragraph of
section 7.

	Cheers,
	Glenn

________________________________

	From: Ghanwani, Anoop [mailto:anoop.ghanwani@hp.com] 
	Sent: Thursday, July 14, 2005 4:57 PM
	To: Parsons, Glenn [CAR:1A14:EXCH];
STDS-802-17@listserv.ieee.org
	Subject: RE: [RPRWG] IPoRPR initial draft

	Hi Glenn, Mark,

	In Table 3, I think it would be useful to also have 
	the PHB name alongwith the DSCP since the
	DSCP values are hard to remember...e.g.
	000000 (BE), xxxxxx (AF11) ,etc., in the first
	column of the table.

	In Sec 5.1.1, I think a distinction needs to be made
	for E-LSP and L-LSP.  With L-LSPs only the drop
	precedence is encoded in the EXP bits.  

	I'm curious as to why the draft has such a detailed
	security considerations section even though by itself
	the draft doesn't introduce any new security concerns.
	At a minimum, I think a statement to that effect should 
	appear in the security section.

	Anoop

________________________________

	From: owner-stds-802-17@ieee.org
[mailto:owner-stds-802-17@ieee.org] On Behalf Of Glenn Parsons
	Sent: Tuesday, July 12, 2005 6:16 PM
	To: STDS-802-17@listserv.ieee.org
	Subject: Re: [RPRWG] IPoRPR initial draft

	Thanks David,

	We can fix most of these I think.

	Some of them though (e.g., the sections with no section numbers)
are part of the IETF front/back matter and cannot be changed (without
changing their style).

	Cheers,
	Glenn.

________________________________

	From: David V James [mailto:dvj@alum.mit.edu] 
	Sent: Tuesday, July 12, 2005 7:36 PM
	To: Parsons, Glenn [CAR:1A14:EXCH]
	Cc: STDS-802-17@listserv.ieee.org
	Subject: RE: [RPRWG] IPoRPR initial draft

	Glen,

	I got of a few of the excessive capitalization, but I suspect
	not all.

	The 802.3 environment seems very hazardous: everyone there seems
	to get a sticky caps key(:>).

	Its on the attached pdf. Feel free to discuss, call me into the
	meeting, or forward as appropriate.

	DVJ

	David V. James
	3180 South Ct
	Palo Alto, CA 94306
	Home: +1.650.494.0926
	      +1.650.856.9801
	Cell: +1.650.954.6906
	Fax:  +1.360.242.5508
	Base: dvj@alum.mit.edu 

		-----Original Message-----
		From: owner-stds-802-17@ieee.org
[mailto:owner-stds-802-17@ieee.org]On Behalf Of Glenn Parsons
		Sent: Tuesday, July 12, 2005 1:36 PM
		To: STDS-802-17@listserv.ieee.org
		Subject: [RPRWG] IPoRPR initial draft

		Folks, 

		The first draft of the IPoRPR basic mapping is attached.

		This version is slightly different from the IETF
officially posted version <draft-ietf-iporpr-basic-00.txt> -- there are
some minor corrections to tables 2 & 3.  As a result, I'd prefer the
group reviews this version.

		Note that the primary review mechanism to submit
comments to the IETF IPoRPR mailing list -- and you must be a member to
post (and get past the spam filter :-).

		There is currently no plan for an IPoRPR WG meeting at
IETF 63 in Paris.  

		However, there is agenda time at the IEEE 802.17 meeting
in San Francisco next week to discuss this draft.  

		Cheers, 
		Glenn 

		<<draft-ietf-iporpr-basic-00a.html>>
<<draft-ietf-iporpr-basic-00a.txt>> 