Subject: I-D ACTION:draft-allan-mpls-pid-00.txt

From: [email-masked]
Date: Fri, 04 Apr 2003 06:43:34 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: MPLS and IP PW Payload ID
	Author(s)	: D. Allan
	Filename	: draft-allan-mpls-pid-00.txt
	Pages		: 0
	Date		: 2003-4-3
	
This memo defines an MPLS and PW payload ID. It describes how an
MPLS payload ID may be used to address a number of issues associated
with proprietary ECMP deployments. It describes how when used with
PWs permits OAM and control protocols to be multiplexed with a PW.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-allan-mpls-pid-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-allan-mpls-pid-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-allan-mpls-pid-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Shahram Davari <[email-masked]>
Date: Fri, 4 Apr 2003 12:25:03 -0800

Hi Dave,

I have a few questions/comments:

1) Last sentence of section 2: It is not clear what the loopback address is. I assume it is not a 127/8 address.

2) Could you please explain bullet 2 of section 4 a bit more.

3) Section 6: I assume by no PHP you mean when there is only one label to be poped. right?
Also it might be possible to get a PPP PID for the extended Payload ID control-word. 

Yours,
Shahram 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Friday, April 04, 2003 6:44 AM
>Cc: [email-masked]; [email-masked]
>Subject: [PWE3] I-D ACTION:draft-allan-mpls-pid-00.txt
>
>

---

From: Shahram Davari <[email-masked]>
Date: Fri, 4 Apr 2003 12:28:29 -0800

Dave,

Also isn't it better to use '0000' instead of '1000' for the first nibble.
This way it won't interfere with any implementation.

-Shahram

>From: Shahram Davari 
>Sent: Friday, April 04, 2003 3:25 PM
>To: David Allan (E-mail)
>Cc: [email-masked]; [email-masked]
>Subject: RE: [PWE3] I-D ACTION:draft-allan-mpls-pid-00.txt
>
>
>Hi Dave,
>
>1) Last sentence of section 2: It is not clear what the 
>loopback address is. I assume it is not a 127/8 address.
>

---

From: "David Allan" <[email-masked]>
Date: Fri, 4 Apr 2003 15:42:41 -0500

> loopback address is. I assume it is not a 127/8 address.

Correct, it is the LSR/PEs own loopback address. not an internal link
loopback address. 

> 2) Could you please explain bullet 2 of section 4 a bit more.

Hmmmm, if an LSP of level 'n' transports other LSPs (carries MPLS payload),
and load spreading makes a descision for forwarding that includes those
other LSPs labels in its deliberations, then those other LSPs do not
necessarily forward consistently with the LSP that you tested at level 'n'. 

If the LSP of level 'n' only carries other payloads (IP, PW payloads etc.),
then you will have consistency. I'll try to come up with some better
wording.

> one label to be poped. right? 

Deployed PHP would then forward the Payload ID and subsequent payload.
Probably a good reason for using an unassigned version number.

> Also it might be possible to 
> get a PPP PID for the extended Payload ID control-word.

The more PID types we add, the more complex implementations will be. Lets
discuss.

cheers
Dave
 
> >This memo defines an MPLS and PW payload ID. It describes 
> how an MPLS 
> >payload ID may be used to address a number of issues associated with 
> >proprietary ECMP deployments. It describes how when used with PWs 
> >permits OAM and control protocols to be multiplexed with a PW.
> >
> >http://www.ietf.org/shadow.html or 
> >ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >

---

From: Shahram Davari <[email-masked]>
Date: Fri, 4 Apr 2003 12:49:12 -0800

Dave,
 
For the PHP, I didn't mean a new PID inside extended control word. What I meant was a link PID. For example if
the link is POS (packet over sonet) then a PPP PID for the PPP header that wraps the packet could identify the
payload as being of extended control word nature.
 
-Shahram

-----Original Message-----
From: David Allan [mailto:[email-masked]]
Sent: Friday, April 04, 2003 3:43 PM
To: Shahram Davari
Cc: [email-masked]; [email-masked]
Subject: RE: [PWE3] I-D ACTION:draft-allan-mpls-pid-00.txt

> loopback address is. I assume it is not a 127/8 address. 

Correct, it is the LSR/PEs own loopback address. not an internal link loopback address. 

> 2) Could you please explain bullet 2 of section 4 a bit more. 

Hmmmm, if an LSP of level 'n' transports other LSPs (carries MPLS payload), and load spreading makes a descision for forwarding that includes those other LSPs labels in its deliberations, then those other LSPs do not necessarily forward consistently with the LSP that you tested at level 'n'. 

If the LSP of level 'n' only carries other payloads (IP, PW payloads etc.), then you will have consistency. I'll try to come up with some better wording.

> one label to be poped. right? 

Deployed PHP would then forward the Payload ID and subsequent payload. Probably a good reason for using an unassigned version number.

> get a PPP PID for the extended Payload ID control-word. 

The more PID types we add, the more complex implementations will be. Lets discuss. 

cheers 
Dave 
  
> >From: [email-masked] [ mailto:[email-masked] <mailto:[email-masked]> ] 
> > http://www.ietf.org/internet-drafts/draft-allan-mpls-pid-00.txt <http://www.ietf.org/internet-drafts/draft-allan-mpls-pid-00.txt>  
> > 
> > http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>  or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>  
> > 
> >

---

From: "David Allan" <[email-masked]>
Date: Fri, 4 Apr 2003 15:54:04 -0500

Actually I suspect someone will suggest that 0000 will collide with deployed
stuff ;-)

1000 was chosen not to collide with stuff that after writing I found may not
be an issue. If we accept that existing PHP may lead to somthing trying to
interpret this stuff, then avoiding all assigned IP version numbers is
probably the best choice, which leaves 1-3 and 10-14, or 0 and 15 (the
explicitly reserved values). IMO I would lean towards 15, which cannot be
interpreted as a protocol at all and does not collide with IANA space.

Dave

> From: Shahram Davari [mailto:[email-masked]] 
> Sent: Friday, April 04, 2003 3:28 PM
> To: Shahram Davari; Allan, David [CAR:NS00:EXCH]
> Cc: [email-masked]'; [email-masked]'
> Also isn't it better to use '0000' instead of '1000' for the 
> first nibble. This way it won't interfere with any implementation.
> 
> -Shahram
>