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

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 19 Sep 2009 18:17:49 +0100

All,

This revision (I believe) captures all of the points raised in WG last call 
as previously summarised in my email.

Loa, this is ready to progress.

Thanks,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, September 19, 2009 1:00 AM
Subject: I-D Action:draft-ietf-mpls-tp-gach-dcn-06.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-06.txt
> Pages           : 8
> Date            : 2009-09-18
>
> 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-06.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]
> 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
>

---

From: [email-masked]
Date: Mon, 21 Sep 2009 09:44:33 +0800

Adrian
according to the revison. maybe we revise RFC5586? or else ,both drafts 
will have different describles.
in additonal, if there is not any ACH TLV in the mcc/scc message,  how to 
extend other functions in the future? or it must be unnecessary to extend 
other functions
in the future for MCC/SCC message?

best regards
liu

"Adrian Farrel" <[email-masked]> 
发件人:  [email-masked]
2009-09-20 01:17
请答复 给
Adrian Farrel <[email-masked]>

收件人
<[email-masked]>
抄送
[email-masked]
主题
[mpls-tp] Fw: I-D Action:draft-ietf-mpls-tp-gach-dcn-06.txt

All,

This revision (I believe) captures all of the points raised in WG last 
call 
as previously summarised in my email.

Thanks,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, September 19, 2009 1:00 AM
Subject: I-D Action:draft-ietf-mpls-tp-gach-dcn-06.txt

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

--------------------------------------------------------
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, 21 Sep 2009 11:51:13 +0100

Hello Liu,

I think you are asking two questions.

1. Does draft-ietf-mpls-tp-gach-dcn change the
  format of the GACH, and if so how do we
  handle the change?

2. If there is no ACH TLV in the mcc/scc message,
  how will we extend the message if we need to?

> according to the revison. maybe we revise
> RFC5586? or else ,both drafts will have
> different describles.
> in additonal, if there is not any ACH TLV
> in the mcc/scc message,  how to extend
> other functions in the future? or it must
> be unnecessary to extend other functions

To answer question 1, first...

RFC 5586 defines that the GACH consist of:
- ACh identifier (4 bits 0x1)
- ACh version (4 bits 0x0)
- Reserved (8 bits 0x0)
- Channel Type (16 bits)
- ACH TLV header (16 bits - OPTIONAL depending
   on Channel Type)
- ACH TLVs (length depending on ACH TLV header,
   content depending on Channel Type)
- G-ACh message.

In draft-ietf-mpls-tp-gach-dcn we define as follows:
- ACH TLV header is absent
- ACH TLVs are absent
- G-ACh message consists of:
   - PID (16 bits - PPP value)
   - MCC/SCC message

I don't believe this changes the definition in RFC 5586 and nothing extra 
needs to be done.

And now the second question.
We have tried very hard to find any requirements to include TLVs in MCC/SCC 
G-ACh messages. We have failed to find any. If we include the ACH TLV header 
we could set the length to zero to indicate not TLVs. This would have the 
following disadvantages:
- Every message would contain 4 unnecessary bytes
- Every message would have to be parsed to check
  that the length was zero so increasing the
  processing.
- If TLVs are present, implementations will not
  know how to process them.
Given that we have no use for the TLVs, it seems best to avoid these issues.

However, if a use for TLVs is found in the future it is very easy to define 
new ACH Channel Types to represent "MCC with TLVs" and "SCC with TLVs."

Thanks,
Adrian

---

From: [email-masked]
Date: Tue, 22 Sep 2009 10:09:25 +0800

Adrian
thank you for replying quickly. your understanding to my problem is very 
true and your explaining is very precise. here I appreciate your 
answering. but I don't completely agree your opinions. specially, I don't 
accept your last section contents
" However, if a use for TLVs is found in the future it is very easy to 
define 
new ACH Channel Types to represent "MCC with TLVs" and "SCC with TLVs."

if it is easy to add new ACH Channel Types, it maybe unnecessary to need 
PID field in GACH message. we may use different ACH Channel Type value to 
indicate different type of MCC/SCC message. for example, we may use ACH 
Channel Type =1 to indicate IPv4/MCC, at the same time , we may use ACH 
Channel Type=2 to indicate IPv6/MCC. 
through this way, we may use ACH Channel Type (16bits) to indicate 2^16 
Types of MCC/SCC Messages. why to add PID fields in the GACH messages?

best regards
liu

2009-09-21 18:51

收件人
<[email-masked]>
抄送
<[email-masked]>, <[email-masked]>
主题
Re: [mpls-tp] Fw: I-D Action:draft-ietf-mpls-tp-gach-dcn-06.txt

Hello Liu,

And now the second question.
We have tried very hard to find any requirements to include TLVs in 
MCC/SCC 
G-ACh messages. We have failed to find any. If we include the ACH TLV 
header 
we could set the length to zero to indicate not TLVs. This would have the 
following disadvantages:
- Every message would contain 4 unnecessary bytes
- Every message would have to be parsed to check
  that the length was zero so increasing the
  processing.
- If TLVs are present, implementations will not
  know how to process them.
Given that we have no use for the TLVs, it seems best to avoid these 
issues.

However, if a use for TLVs is found in the future it is very easy to 
define 
new ACH Channel Types to represent "MCC with TLVs" and "SCC with TLVs."

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 22 Sep 2009 19:34:26 +0100

Hi Liu,

> thank you for replying quickly. your understanding to my
> problem is very true and your explaining is very precise.
> here I appreciate your answering. but I don't completely
> agree your opinions. specially, I don't accept your last
> section contents
>> However, if a use for TLVs is found in the future it is
>> very easy to define new ACH Channel Types to represent
>>"MCC with TLVs" and "SCC with TLVs."
>
> if it is easy to add new ACH Channel Types, it maybe
> unnecessary to need PID field in GACH message. we may
> use different ACH Channel Type value to indicate
> different type of MCC/SCC message. for example, we may
> use ACH Channel Type =1 to indicate IPv4/MCC, at the
> same time , we may use ACH Channel Type=2 to indicate
> IPv6/MCC.
> through this way, we may use ACH Channel Type (16bits)
> to indicate 2^16 Types of MCC/SCC Messages. why to add
> PID fields in the GACH messages?

Your proposal is perfectly possible. But it is just another solution to the 
same problem. Does it have any special reason to change to use it?

On the other hand, it would cause two issues:

1. It would be a change in granularity of the Channel Type as currently 
defined. Of course, this change could be made, but it would need to be 
discussed and agreed by a wide community.

2. We would need to keep updating the Channel Type registry every time a new 
protocol payload was considered. By using the existing PPP registry, we 
don't need to do this.

I think that going forward it would be helpful if, rather than suggesting 
other ways to solve this problem, you raised issues and concerns with the 
current solution that you feel need to be addressed.

Thanks,
Adrian