Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

[Shah, Himanshu]

Hi Ralph -

You make a good point on the sub-TLV.
I have talked to my WG chairs and we are going to change the text based on your 
suggestion.
I will remove the MAC Withdraw sub-TLV registry for sequence number TLV and 
instead use the
Value from the LDP Type values (same as MAC List TLV).

As for combining text of section 3 and 4.1.

Section 3 described the packet fields, including the sequence number text.
The reason for sequence number text is - that it is applicable to both;
Sender (section 4.1) and Receiver (section 4.2).

I will explore to remove the overlap..

Thanks,
Himanshu


-Original Message-
From: Ralph Droms (rdroms) [mailto:rdr...@cisco.com] 
Sent: Monday, October 26, 2015 3:13 PM
To: Shah, Himanshu
Cc: Andrew G. Malis; A. Jean Mahoney; General Area Review Team; 
draft-ietf-pals-mpls-tp-mac-wd@ietf.org; The IESG
Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

Himanshu - I've been tied up in meetings most of the day today and am about to 
go into more meetings that will last until the end of the day.

I reviewed your revised draft briefly and it mostly looks OK.  I have one 
substantive comment, which is about an issue I didn't notice until now:

How is the Mac Withdraw sub-TLV registry from which the "Sequence Number" code 
point is taken differentiated from the LDP Parameters sub-TLV registry from 
which the "MAC List" and "MAC Flush Parameter" code points are taken?  In other 
words, how does the receciver know to interpret the code point on the Sequence 
Number TLV as a code point in the Mac Withdraw sub-TLV registry while the code 
points on the MAC List TLV and the MAC Flush Paramter TLV are interpreted as 
code points in the LDP Paramteres sub-TLV?  Shouldn't all the code points on 
the TLVs in this message come from a single registry?

I also have an editorial comment from my earlier review: the ifrst paragraph of 
section 3 is mostly redundant with section 4.1 and that text in section 3 
should be merged into the text in section 4.1

- Ralph

> On Oct 26, 2015, at 2:09 PM 10/26/15, Shah, Himanshu  wrote:
> 
> Thanks Andy.
> He did re-send the email without MIME and I was able to read and reply.
>  
> Thanks,
> Himanshu
>  
> From: Andrew G. Malis [mailto:agma...@gmail.com] 
> Sent: Monday, October 26, 2015 2:08 PM
> To: Shah, Himanshu
> Cc: Ralph Droms (rdroms); A. Jean Mahoney; General Area Review Team; 
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org; The IESG
> Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
>  
> Himanshu,
>  
> Ralph said:
>  
> Himanshu - I've received your revised draft.  I've been stuck in a variety of 
> meetings Monday and haven't had time to review it.  I should be able to look 
> at it before the end of the day.
> 
> - Ralph
>  
> On Mon, Oct 26, 2015 at 1:04 PM, Shah, Himanshu  wrote:
> Can you send the email without MIME signature?
>  
> Thanks,
> Himanshu
>  
> From: Ralph Droms (rdroms) [mailto:rdr...@cisco.com] 
> Sent: Monday, October 26, 2015 1:02 PM
> To: Shah, Himanshu
> Cc: A. Jean Mahoney; General Area Review Team; 
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org; The IESG
> Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

[Ralph Droms (rdroms)]

Himanshu - I've been tied up in meetings most of the day today and am about to 
go into more meetings that will last until the end of the day.

I reviewed your revised draft briefly and it mostly looks OK.  I have one 
substantive comment, which is about an issue I didn't notice until now:

How is the Mac Withdraw sub-TLV registry from which the "Sequence Number" code 
point is taken differentiated from the LDP Parameters sub-TLV registry from 
which the "MAC List" and "MAC Flush Parameter" code points are taken?  In other 
words, how does the receciver know to interpret the code point on the Sequence 
Number TLV as a code point in the Mac Withdraw sub-TLV registry while the code 
points on the MAC List TLV and the MAC Flush Paramter TLV are interpreted as 
code points in the LDP Paramteres sub-TLV?  Shouldn't all the code points on 
the TLVs in this message come from a single registry?

I also have an editorial comment from my earlier review: the ifrst paragraph of 
section 3 is mostly redundant with section 4.1 and that text in section 3 
should be merged into the text in section 4.1

- Ralph

> On Oct 26, 2015, at 2:09 PM 10/26/15, Shah, Himanshu  wrote:
> 
> Thanks Andy.
> He did re-send the email without MIME and I was able to read and reply.
>  
> Thanks,
> Himanshu
>  
> From: Andrew G. Malis [mailto:agma...@gmail.com] 
> Sent: Monday, October 26, 2015 2:08 PM
> To: Shah, Himanshu
> Cc: Ralph Droms (rdroms); A. Jean Mahoney; General Area Review Team; 
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org; The IESG
> Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
>  
> Himanshu,
>  
> Ralph said:
>  
> Himanshu - I've received your revised draft.  I've been stuck in a variety of 
> meetings Monday and haven't had time to review it.  I should be able to look 
> at it before the end of the day.
> 
> - Ralph
>  
> On Mon, Oct 26, 2015 at 1:04 PM, Shah, Himanshu  wrote:
> Can you send the email without MIME signature?
>  
> Thanks,
> Himanshu
>  
> From: Ralph Droms (rdroms) [mailto:rdr...@cisco.com] 
> Sent: Monday, October 26, 2015 1:02 PM
> To: Shah, Himanshu
> Cc: A. Jean Mahoney; General Area Review Team; 
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org; The IESG
> Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

[Shah, Himanshu]

Thanks Andy.
He did re-send the email without MIME and I was able to read and reply.

Thanks,
Himanshu

From: Andrew G. Malis [mailto:agma...@gmail.com]
Sent: Monday, October 26, 2015 2:08 PM
To: Shah, Himanshu
Cc: Ralph Droms (rdroms); A. Jean Mahoney; General Area Review Team; 
draft-ietf-pals-mpls-tp-mac-wd@ietf.org; The IESG
Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

Himanshu,

Ralph said:

Himanshu - I've received your revised draft.  I've been stuck in a variety of 
meetings Monday and haven't had time to review it.  I should be able to look at 
it before the end of the day.

- Ralph

On Mon, Oct 26, 2015 at 1:04 PM, Shah, Himanshu 
mailto:hs...@ciena.com>> wrote:
Can you send the email without MIME signature?

Thanks,
Himanshu

From: Ralph Droms (rdroms) [mailto:rdr...@cisco.com]
Sent: Monday, October 26, 2015 1:02 PM
To: Shah, Himanshu
Cc: A. Jean Mahoney; General Area Review Team; 
draft-ietf-pals-mpls-tp-mac-wd@ietf.org;
 The IESG
Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

[Andrew G. Malis]

Himanshu,

Ralph said:

Himanshu - I've received your revised draft.  I've been stuck in a variety
of meetings Monday and haven't had time to review it.  I should be able to
look at it before the end of the day.

- Ralph

On Mon, Oct 26, 2015 at 1:04 PM, Shah, Himanshu  wrote:

> *Can you send the email without MIME signature?*
>
>
>
> *Thanks,*
>
> *Himanshu*
>
>
>
> *From:* Ralph Droms (rdroms) [mailto:rdr...@cisco.com]
> *Sent:* Monday, October 26, 2015 1:02 PM
> *To:* Shah, Himanshu
> *Cc:* A. Jean Mahoney; General Area Review Team;
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org; The IESG
> *Subject:* Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
>
>
>
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

[Shah, Himanshu]

Thanks Ralph..

Himanshu


-Original Message-
From: Ralph Droms (rdroms) [mailto:rdr...@cisco.com] 
Sent: Monday, October 26, 2015 1:11 PM
To: Shah, Himanshu
Cc: A. Jean Mahoney; General Area Review Team; 
draft-ietf-pals-mpls-tp-mac-wd@ietf.org; The IESG
Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

Himanshu - I've received your revised draft.  I've been stuck in a variety of 
meetings Monday and haven't had time to review it.  I should be able to look at 
it before the end of the day.

- Ralph

> On Oct 24, 2015, at 5:56 PM 10/24/15, Shah, Himanshu  wrote:
> 
> Now with the draft..
> 
> Thanks,
> Himanshu
> 
> 
> -Original Message-
> From: Shah, Himanshu
> Sent: Saturday, October 24, 2015 5:52 PM
> To: 'Ralph Droms (rdroms)'
> Cc: 'A. Jean Mahoney'; 'General Area Review Team'; 
> 'draft-ietf-pals-mpls-tp-mac-wd@ietf.org'; 'The IESG'
> Subject: RE: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
> 
> One more update that was discussed in previous emails but not included 
> in your last email -
> 
> Original text: 
>  Only half of the sequence number space is used.  Modular arithmetic  
> is used to detect wrapping of sequence number.  When sequence number  
> wraps, all MAC addresses are flushed and the sequence number is  
> reset.  The 16-bit sequence number handling is described in  
> [RFC4385]. This document uses 32-bits sequence numbers and hence  
> sequence number in half the number space (i.e. 31-bits or ~2billion)  
> is considered in the valid receive range.
> 
> [Ralph]
> This paragraph is not at all clear to me. Reading section 4 of RFC 4385 
> helped but left me unsure about how my understanding of how to extend the 
> sequence number mechanism to 32 bits corresponds to the expectations of this 
> document.
> 
> 
> [Himanshu>]
> 
> New text:
> 
>   The lack of reliable transport protocol for the in-band OAM
>   necessitates a presence of sequencing and acknowledgement
>   scheme so that the receiver can recognize newer message from
>   retransmitted older messages. The [RFC4385] describes the details
>   of sequence number handling which includes overflow detection for
>   sequence number field of size 16-bits. This document leverages
>   the same scheme with the two exemptions
>   - sequence number field is of size 32-bits
>   - overflow detection is simplified such that sequence
> number exceed 2,147,483,647 (0x7FFF) is considered
>  overflow and reset to 1.
> 
> Thanks,
> Himanshu
> 
> 
> -Original Message-
> From: Shah, Himanshu
> Sent: Saturday, October 24, 2015 4:00 PM
> To: 'Ralph Droms (rdroms)'
> Cc: A. Jean Mahoney; General Area Review Team; 
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org; The IESG
> Subject: RE: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
> 
> I am updating the drafts to address your comments where relevant.
> 
> Since there is too many indentations below, I am bringing you latest comments 
> here, and respond.
> 
> ---
> [ralph] What I think would improve this specification is clarification that 
> trims redundant specification details from draft-ietf-pals-mpls-tp-mac-wd and 
> cites, concisely and exactly, the other documents from which the 
> specifications are copied.
> 
> [Himanshu] Trimming where relevant.
> ---
> 
> [ralph] It wasn't obvious to me what is intended as a protocol specification 
> and what is intended as a description of the protocol.  I see that RFC 4762 
> includes text that describes how to process an empty MAC List TLV, so perhaps 
> removal of the text altogether would be best.
> 
> [Himanshu] removed the reference to empty MAC List TLV
> 
> 
> [ralph]
>> The PW OAM message header is exactly the same as what is defined in 
>> [RFC6478].
>> 
> Is this statement really true?  The MAC Address Withdraw header seems to 
> replace the "Refresh Timer" field with a "Reserved" field, and adds a new "R" 
> flag.  The statement might be misleading to an implementor.
> 
> [Himanshu] replaced with following text:
> "The MAC withdraw PW OAM message follows the same guidelines used in  
> [RFC6478], whereby first 4-bytes of OAM message header is followed by  
> message specific field and a set of TLVs relevant for the message"
> 
> -
> [ralph]
> I think it would be helpful to state explicitly that the Sequence Number TLV 
> MUST be the first TLV in the message.
> 
> [Himanshu] added.
> 
> [Ralph] I apologize if I appear to be finicky, again, but the sentence I 
> quoted simply wasn't clear to me.  Common sense interpretation of 
> specifications is, of course, expected, but in my experience a simple 
> sentence like:
> 
> A MAC Address Withdraw OAM message with the A-bit set is sent by a 
> receiver to acknowledge receipt and processing of a MAC Address 
> Withdraw OAM message
> 
> [Himanshu]  Modified description of A-bit as follows -
> 
>   A single bit (called A-bit) is set by a receiver to acknowledge
>   receipt and processing of a MAC Address Withdraw OAM

Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

[Shah, Himanshu]

Can you send the email without MIME signature?

Thanks,
Himanshu

From: Ralph Droms (rdroms) [mailto:rdr...@cisco.com]
Sent: Monday, October 26, 2015 1:02 PM
To: Shah, Himanshu
Cc: A. Jean Mahoney; General Area Review Team; 
draft-ietf-pals-mpls-tp-mac-wd@ietf.org; The IESG
Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

[Ralph Droms (rdroms)]

Himanshu - I've received your revised draft.  I've been stuck in a variety of 
meetings Monday and haven't had time to review it.  I should be able to look at 
it before the end of the day.

- Ralph

> On Oct 24, 2015, at 5:56 PM 10/24/15, Shah, Himanshu  wrote:
> 
> Now with the draft..
> 
> Thanks,
> Himanshu
> 
> 
> -Original Message-
> From: Shah, Himanshu 
> Sent: Saturday, October 24, 2015 5:52 PM
> To: 'Ralph Droms (rdroms)'
> Cc: 'A. Jean Mahoney'; 'General Area Review Team'; 
> 'draft-ietf-pals-mpls-tp-mac-wd@ietf.org'; 'The IESG'
> Subject: RE: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
> 
> One more update that was discussed in previous emails but not included in 
> your last email -
> 
> Original text: 
>  Only half of the sequence number space is used.  Modular arithmetic
>  is used to detect wrapping of sequence number.  When sequence number
>  wraps, all MAC addresses are flushed and the sequence number is
>  reset.  The 16-bit sequence number handling is described in
>  [RFC4385]. This document uses 32-bits sequence numbers and hence
>  sequence number in half the number space (i.e. 31-bits or ~2billion)
>  is considered in the valid receive range.
> 
> [Ralph]
> This paragraph is not at all clear to me. Reading section 4 of RFC 4385 
> helped but left me unsure about how my understanding of how to extend the 
> sequence number mechanism to 32 bits corresponds to the expectations of this 
> document.
> 
> 
> [Himanshu>] 
> 
> New text:
> 
>   The lack of reliable transport protocol for the in-band OAM
>   necessitates a presence of sequencing and acknowledgement
>   scheme so that the receiver can recognize newer message from
>   retransmitted older messages. The [RFC4385] describes the details
>   of sequence number handling which includes overflow detection for
>   sequence number field of size 16-bits. This document leverages
>   the same scheme with the two exemptions
>   - sequence number field is of size 32-bits
>   - overflow detection is simplified such that sequence
> number exceed 2,147,483,647 (0x7FFF) is considered
>  overflow and reset to 1.
> 
> Thanks,
> Himanshu
> 
> 
> -Original Message-
> From: Shah, Himanshu
> Sent: Saturday, October 24, 2015 4:00 PM
> To: 'Ralph Droms (rdroms)'
> Cc: A. Jean Mahoney; General Area Review Team; 
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org; The IESG
> Subject: RE: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
> 
> I am updating the drafts to address your comments where relevant.
> 
> Since there is too many indentations below, I am bringing you latest comments 
> here, and respond.
> 
> ---
> [ralph] What I think would improve this specification is clarification that 
> trims redundant specification details from draft-ietf-pals-mpls-tp-mac-wd and 
> cites, concisely and exactly, the other documents from which the 
> specifications are copied.
> 
> [Himanshu] Trimming where relevant.
> ---
> 
> [ralph] It wasn't obvious to me what is intended as a protocol specification 
> and what is intended as a description of the protocol.  I see that RFC 4762 
> includes text that describes how to process an empty MAC List TLV, so perhaps 
> removal of the text altogether would be best.
> 
> [Himanshu] removed the reference to empty MAC List TLV
> 
> 
> [ralph]
>> The PW OAM message header is exactly the same as what is defined in 
>> [RFC6478].
>> 
> Is this statement really true?  The MAC Address Withdraw header seems to 
> replace the "Refresh Timer" field with a "Reserved" field, and adds a new "R" 
> flag.  The statement might be misleading to an implementor.
> 
> [Himanshu] replaced with following text:
> "The MAC withdraw PW OAM message follows the same guidelines used in  
> [RFC6478], whereby first 4-bytes of OAM message header is followed by  
> message specific field and a set of TLVs relevant for the message"
> 
> -
> [ralph]
> I think it would be helpful to state explicitly that the Sequence Number TLV 
> MUST be the first TLV in the message.
> 
> [Himanshu] added.
> 
> [Ralph] I apologize if I appear to be finicky, again, but the sentence I 
> quoted simply wasn't clear to me.  Common sense interpretation of 
> specifications is, of course, expected, but in my experience a simple 
> sentence like:
> 
> A MAC Address Withdraw OAM message with the A-bit set is sent by a receiver 
> to acknowledge receipt and processing of a MAC Address Withdraw OAM message
> 
> [Himanshu]  Modified description of A-bit as follows -
> 
>   A single bit (called A-bit) is set by a receiver to acknowledge
>   receipt and processing of a MAC Address Withdraw OAM message.
>   In the acknowledge message, with A-bit set, MAC TLV(s) is/are
>   excluded.
> 
> ---
> 
> 
> Will send out the updated draft shortly..
> 
> 
> Thanks,
> Himanshu
> 
> -Original Message-
> From: Ralph Droms (rdroms) [mailto:rdr...@cisco.com]
> Sent: Thursday, October 22, 2015 11:29 AM
> To: Shah, Himanshu
> Cc: A. J

Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

[Ralph Droms (rdroms)]

Himanshu - I've received your revised draft.  I've been stuck in a variety of 
meetings Monday and haven't had time to review it.  I should be able to look at 
it before the end of the day.

- Ralph

> On Oct 24, 2015, at 5:56 PM 10/24/15, Shah, Himanshu  wrote:
> 
> Now with the draft..
> 
> Thanks,
> Himanshu
> 
> 
> -Original Message-
> From: Shah, Himanshu
> Sent: Saturday, October 24, 2015 5:52 PM
> To: 'Ralph Droms (rdroms)'
> Cc: 'A. Jean Mahoney'; 'General Area Review Team'; 
> 'draft-ietf-pals-mpls-tp-mac-wd@ietf.org'; 'The IESG'
> Subject: RE: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
> 
> One more update that was discussed in previous emails but not included in 
> your last email -
> 
> Original text:
>  Only half of the sequence number space is used.  Modular arithmetic
>  is used to detect wrapping of sequence number.  When sequence number
>  wraps, all MAC addresses are flushed and the sequence number is
>  reset.  The 16-bit sequence number handling is described in
>  [RFC4385]. This document uses 32-bits sequence numbers and hence
>  sequence number in half the number space (i.e. 31-bits or ~2billion)
>  is considered in the valid receive range.
> 
> [Ralph]
> This paragraph is not at all clear to me. Reading section 4 of RFC 4385 
> helped but left me unsure about how my understanding of how to extend the 
> sequence number mechanism to 32 bits corresponds to the expectations of this 
> document.
> 
> 
> [Himanshu>]
> 
> New text:
> 
>   The lack of reliable transport protocol for the in-band OAM
>   necessitates a presence of sequencing and acknowledgement
>   scheme so that the receiver can recognize newer message from
>   retransmitted older messages. The [RFC4385] describes the details
>   of sequence number handling which includes overflow detection for
>   sequence number field of size 16-bits. This document leverages
>   the same scheme with the two exemptions
>   - sequence number field is of size 32-bits
>   - overflow detection is simplified such that sequence
> number exceed 2,147,483,647 (0x7FFF) is considered
>  overflow and reset to 1.
> 
> Thanks,
> Himanshu
> 
> 
> -Original Message-
> From: Shah, Himanshu
> Sent: Saturday, October 24, 2015 4:00 PM
> To: 'Ralph Droms (rdroms)'
> Cc: A. Jean Mahoney; General Area Review Team; 
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org; The IESG
> Subject: RE: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
> 
> I am updating the drafts to address your comments where relevant.
> 
> Since there is too many indentations below, I am bringing you latest comments 
> here, and respond.
> 
> ---
> [ralph] What I think would improve this specification is clarification that 
> trims redundant specification details from draft-ietf-pals-mpls-tp-mac-wd and 
> cites, concisely and exactly, the other documents from which the 
> specifications are copied.
> 
> [Himanshu] Trimming where relevant.
> ---
> 
> [ralph] It wasn't obvious to me what is intended as a protocol specification 
> and what is intended as a description of the protocol.  I see that RFC 4762 
> includes text that describes how to process an empty MAC List TLV, so perhaps 
> removal of the text altogether would be best.
> 
> [Himanshu] removed the reference to empty MAC List TLV
> 
> 
> [ralph]
>> The PW OAM message header is exactly the same as what is defined in
>> [RFC6478].
>> 
> Is this statement really true?  The MAC Address Withdraw header seems to 
> replace the "Refresh Timer" field with a "Reserved" field, and adds a new "R" 
> flag.  The statement might be misleading to an implementor.
> 
> [Himanshu] replaced with following text:
> "The MAC withdraw PW OAM message follows the same guidelines used in  
> [RFC6478], whereby first 4-bytes of OAM message header is followed by  
> message specific field and a set of TLVs relevant for the message"
> 
> -
> [ralph]
> I think it would be helpful to state explicitly that the Sequence Number TLV 
> MUST be the first TLV in the message.
> 
> [Himanshu] added.
> 
> [Ralph] I apologize if I appear to be finicky, again, but the sentence I 
> quoted simply wasn't clear to me.  Common sense interpretation of 
> specifications is, of course, expected, but in my experience a simple 
> sentence like:
> 
> A MAC Address Withdraw OAM message with the A-bit set is sent by a receiver 
> to acknowledge receipt and processing of a MAC Address Withdraw OAM message
> 
> [Himanshu]  Modified description of A-bit as follows -
> 
>   A single bit (called A-bit) is set by a receiver to acknowledge
>   receipt and processing of a MAC Address Withdraw OAM message.
>   In the acknowledge message, with A-bit set, MAC TLV(s) is/are
>   excluded.
> 
> ---
> 
> 
> Will send out the updated draft shortly..
> 
> 
> Thanks,
> Himanshu
> 
> -Original Message-
> From: Ralph Droms (rdroms) [mailto:rdr...@cisco.com]
> Sent: Thursday, October 22, 2015 11:29 AM
> To: Shah, Himanshu
> Cc: A. Jean