Subject: [IPORPR] IPoRPR initial draft

From: "Glenn Parsons" <[email-masked]>
Date: Tue, 12 Jul 2005 17:35:33 -0400

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>> 
_______________________________________________
IPORPR mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iporpr

---

From: "Glenn Parsons" <[email-masked]>
Date: Mon, 18 Jul 2005 12:37:57 -0400

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:[email-masked]] 
Sent: Thursday, July 14, 2005 4:57 PM
To: Parsons, Glenn [CAR:1A14:EXCH]; [email-masked]
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: [email-masked] [mailto:[email-masked]] On
Behalf Of Glenn Parsons
Sent: Tuesday, July 12, 2005 6:16 PM
To: [email-masked]
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:[email-masked]] 
Sent: Tuesday, July 12, 2005 7:36 PM
To: Parsons, Glenn [CAR:1A14:EXCH]
Cc: [email-masked]
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: [email-masked] 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Glenn Parsons
Sent: Tuesday, July 12, 2005 1:36 PM
To: [email-masked]
Subject: [RPRWG] IPoRPR initial draft

Folks, 

Cheers, 
Glenn 

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

---

From: "Glenn Parsons" <[email-masked]>
Date: Tue, 19 Jul 2005 15:49:42 -0400

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: [email-masked] [mailto:[email-masked]] On
Behalf Of George Suwala (gsuwala)
Sent: Tuesday, July 19, 2005 2:30 PM
To: [email-masked]
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: [email-masked]
[mailto:[email-masked]] On Behalf Of Ghanwani, Anoop
	Sent: Monday, July 18, 2005 10:41 AM
	To: [email-masked]
	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: [email-masked]
[mailto:[email-masked]] On Behalf Of Glenn Parsons
	Sent: Monday, July 18, 2005 9:38 AM
	To: [email-masked]
	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:[email-masked]] 
	Sent: Thursday, July 14, 2005 4:57 PM
	To: Parsons, Glenn [CAR:1A14:EXCH];
[email-masked]
	Subject: RE: [RPRWG] IPoRPR initial draft

	Hi Glenn, Mark,

	 
	Anoop

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Glenn Parsons
	Sent: Tuesday, July 12, 2005 6:16 PM
	To: [email-masked]
	Subject: Re: [RPRWG] IPoRPR initial draft

	Thanks David,

	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.

________________________________

	Glen,

	 
	 
	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: [email-masked] 

		-----Original Message-----
		From: [email-masked]
[mailto:[email-masked]]On Behalf Of Glenn Parsons
		Sent: Tuesday, July 12, 2005 1:36 PM
		To: [email-masked]
		Subject: [RPRWG] IPoRPR initial draft

		Folks, 

		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