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

["Adrian Farrel" <[e-mail]>]

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