Subject: [mpls-tp] FW: I-D Action:draft-ietf-mpls-tp-gach-dcn-05.txt

From: "ROTHKEGEL, Walter (Walter)" <[email-masked]>
Date: Fri, 4 Sep 2009 10:20:14 +0200

Hi Adrian,

Adrian Farrel wrote:
Hi,

This revision folds in comments from Ben and Francesco (for which thanks).

Most of Ben's points were in our email exchange. Ben's last questions were actually covered by Francesco's emails.

The main (only?) point I see remaining is whether it is appropriate to use ACH TLVs.

I think we must assume that ACH TLVs are acceptable in general. After all, RFC 5586 reached consensus and includes the definition of the concept and base definitions.

So the issue is whether the DCN should use an ACH TLV to encode the payload PID, or whether this should be hardwired into the DCN message format (for example, omitting the ACH TLV header, leaving out the ACH TLV type and length, and just including the PID bytes).

At one point in the discussion it was suggested that there is benefit in all ACH messages having a common form/structure. Others say that the messages should be tuned for their specific use.

At this point, I have heard debate about this with some saying that they thing one solution is nicer than the other, but I don't hear anyone saying strongly that they want a particular solution (perhaps my hearing is not good enough?)

At the moment, I have status quo ante and that is how it will stay unless there is a strong opinion the other way.

please find below a particular solution re the message format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1|Version|   Reserved    |         Channel Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         ACH TLV Header                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                      zero or more ACH TLVs                    ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |             PID               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         MCC/SCC Message                       |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This format still allows to add ACH TLVs if needed in the future - the ACH TLV
Header is mandatory, even if no ACH TLV will follow. The PID is put into the
last two octets of a 32bit field immediately followed by the MCC/SCC message.

The advantage is that the PID field can defined in this draft (no dependency
on other drafts that define the TLVs - these drafts may not be as advanced as
this DCN draft).
Moreover,if an implementation does not support TLV processing in the context
of the SCC/MCC Channel Types, it could just skip all TLVs and go directly to the
PID that provides the information of which PDU type the MCC or SCC message is.

Thanks,
Adrian

----- Original Message ----- From: <[email-masked]><mailto:[email-masked]>
To: <[email-masked]><mailto:[email-masked]>
Cc: <[email-masked]><mailto:[email-masked]>
Sent: Thursday, August 27, 2009 1:30 PM
Subject: I-D Action:draft-ietf-mpls-tp-gach-dcn-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

Title           : An Inband Data Communication Network For the MPLS Transport Profile
Author(s)       : D. Beller, A. Farrel
Filename        : draft-ietf-mpls-tp-gach-dcn-05.txt
Pages           : 9
Date            : 2009-08-27

The Generic Associated Channel (G-ACh) has been defined as a
generalization of the pseudowire (PW) associated control channel to
enable the realization of a control/communication channel associated
with Multiprotocol Label Switching (MPLS) Label Switched Paths
(LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between
adjacent MPLS-capable devices.

The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS
architecture that identifies elements of the MPLS toolkit that may be
combined to build a carrier grade packet transport network based on
MPLS packet switching technology.

This document describes how the G-ACh may be used to provide the
infrastructure that forms part of the Management Communication
Network (MCN) and a Signaling Communication Network (SCN).
Collectively, the MCN and SCN may be referred to as the Data
Communication Network (DCN). This document explains how MCN and SCN
messages are encapsulated, carried on the G-ACh, and demultiplexed

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-gach-dcn-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--------------------------------------------------------------------------------

_______________________________________________
I-D-Announce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
mpls-tp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls-tp

Regards

Walter
________________________________________________________________________
Walter Rothkegel
Alcatel-Lucent
CMTS
Carrier BG, Optics BD, CC PG, SE/A
Thurn-und-Taxis-Str. 10-14, 2/444
90411 Nuernberg, Germany
Email: [email-masked]
Phone: +49 911 526-4084
Fax:   +49 911 526-6299
Alcatel-Lucent Deutschland AG
Sitz der Gesellschaft: Stuttgart - Amtsgericht Stuttgart HRB 4026
Vorsitzender des Aufsichtsrats: Michael Oppenhoff
Vorstand: Alf Henryk Wulf (Vors.), Hans-Jörg Daub, Dr. Rainer Fechner, Peter Kury

---

From: [email-masked]
Date: Mon, 14 Sep 2009 10:28:24 +0800

Walter 
 I reviewed this follow e-mail, I have a question to ask you. there is a 
following part describles in the email:
  "Moreover,if an implementation does not support TLV processing in the 
context
of the SCC/MCC Channel Types, it could just skip all TLVs and go directly 
to the
PID that provides the information of which PDU type the MCC or SCC message 
is."
IMO, if an implementation can't support TLV processing in the context of 
the scc/mcc channel types. so how do it locates 
where the PID field is in the  MCC/SCC packet. whether to need PID offset 
field which will indicate the location of  PID field?

do my understanding be true?

best regards
liu

"ROTHKEGEL, Walter (Walter)" <[email-masked]> 
发件人:  [email-masked]
2009-09-04 16:20

收件人

抄送
"[email-masked]" <[email-masked]>
主题
[mpls-tp] FW:  I-D Action:draft-ietf-mpls-tp-gach-dcn-05.txt

Hi Adrian,

Adrian Farrel wrote: 
Hi, 

Most of Ben's points were in our email exchange. Ben's last questions were 
actually covered by Francesco's emails. 

The main (only?) point I see remaining is whether it is appropriate to use 
ACH TLVs. 

I think we must assume that ACH TLVs are acceptable in general. After all, 
RFC 5586 reached consensus and includes the definition of the concept and 
base definitions. 

So the issue is whether the DCN should use an ACH TLV to encode the 
payload PID, or whether this should be hardwired into the DCN message 
format (for example, omitting the ACH TLV header, leaving out the ACH TLV 
type and length, and just including the PID bytes). 

At one point in the discussion it was suggested that there is benefit in 
all ACH messages having a common form/structure. Others say that the 
messages should be tuned for their specific use. 

At this point, I have heard debate about this with some saying that they 
thing one solution is nicer than the other, but I don't hear anyone saying 
strongly that they want a particular solution (perhaps my hearing is not 
good enough?) 

At the moment, I have status quo ante and that is how it will stay unless 
there is a strong opinion the other way.  

    0                   1                   2                   3

This format still allows to add ACH TLVs if needed in the future - the ACH 
TLV
Header is mandatory, even if no ACH TLV will follow. The PID is put into 
the
last two octets of a 32bit field immediately followed by the MCC/SCC 
message.

The advantage is that the PID field can defined in this draft (no 
dependency
on other drafts that define the TLVs - these drafts may not be as advanced 
as
this DCN draft).
Moreover,if an implementation does not support TLV processing in the 
context
of the SCC/MCC Channel Types, it could just skip all TLVs and go directly 
to the
PID that provides the information of which PDU type the MCC or SCC message 
is.

Thanks, 
Adrian 

----- Original Message ----- From: <[email-masked]> 
To: <[email-masked]> 
Cc: <[email-masked]> 
Sent: Thursday, August 27, 2009 1:30 PM 
Subject: I-D Action:draft-ietf-mpls-tp-gach-dcn-05.txt 

A New Internet-Draft is available from the on-line Internet-Drafts 
directories. 
This draft is a work item of the Multiprotocol Label Switching Working 
Group of the IETF. 

Title           : An Inband Data Communication Network For the MPLS 
Transport Profile 
Author(s)       : D. Beller, A. Farrel 
Filename        : draft-ietf-mpls-tp-gach-dcn-05.txt 
Pages           : 9 
Date            : 2009-08-27 

[email-masked] 

[email-masked] 

Regards
 
Walter 
Vorstand: Alf Henryk Wulf (Vors.), Hans-Jörg Daub, Dr. Rainer Fechner, 
Peter Kury_______________________________________________
[email-masked]

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 14 Sep 2009 16:10:58 +0100

Hi Walter and Liu,

It could process the TLV header and so step over the TLVs. Not very 
satisfactory.

However, we now have a proposal on the table to completely remove TLVs from 
the GACH messages used for MCC and SCC, so the question would disappear.

Adrian
----- Original Message ----- 
From: <[email-masked]>
To: "ROTHKEGEL, Walter (Walter)" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, September 14, 2009 3:28 AM
Subject: Re: [mpls-tp] FW: I-D Action:draft-ietf-mpls-tp-gach-dcn-05.txt

> ZTE Information Security Notice: The information contained in this mail is 
> solely property of the sender's organization. This mail communication is 
> confidential. Recipients named above are obligated to maintain secrecy and 
> are not permitted to disclose the contents of this communication to 
> others.
> This email and any files transmitted with it are confidential and intended 
> solely for the use of the individual or entity to whom they are addressed. 
> If you have received this email in error please notify the originator of 
> the message. Any views expressed in this message are those of the 
> individual sender.