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

[[e-mail]]

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






"Adrian Farrel" <[e-mail]> 
2009-09-21 18:51
请答复 给
"Adrian Farrel" <[e-mail]>


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






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
> in the future for MCC/SCC message?

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 






--------------------------------------------------------
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.