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

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Wed, 14 Oct 2015 20:02:29 +0000

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-pals-mpls-tp-mac-wd-02, "MAC Address Withdrawal over Static Pseudowire"
Reviewer: Ralph Droms
Review Date: 2015-10-14
IETF LC End Date: 2015-10-19
IESG Telechat date: (if known) N/A

Summary:

This draft is on the right track but has open issues, described in the review.

Major issues:

While this document is describing a straightforward adaptation of previously defined standards to statically provisioned PWs, in my opinion an implementor would not necessarily be able to construct a fully interoperable implementation from this document.  There are several sections of the document that are not clear in their description of how to use mechanisms from referenced documents in this standard.

If it appears that some of my comments are overly finicky, I'll agree that the correct implementation could probably be deduced from the text in most cases.  That is, I didn't find many outright errors or inconsistencies.  Many of my comments took a lot of paging back and forth, reading of referenced documents and head-scratching, which, in my experience, can lead to implementations that don't interoperate.

Section 1:

  When the number of MAC addresses to be
  removed is large, the empty MAC List TLV may be used.  The empty MAC
  List TLV signifies wildcard MAC Address withdrawl.

This text seems to be the only reference to the processing of an empty MAC List TLV.  Specification of how the protocol works doesn't belong in the Introduction, and "wildcard MAC Address withdrawal" could certainly use some more explanation.

Section 3:

  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.

  a MAC address withdraw OAM message MUST contain a
  "Sequence Number TLV" otherwise the entire message is dropped.

Is the "Sequence Number TLV" required to be the first TLV in the message?  Are the TLVs required to appear in any particular order?

  A single bit (called A-bit) is set to indicate if a MAC withdraw
  message is for ACK.  Also, ACK does not include MAC TLV(s).

Does this mean that the message is an ACK if the A-bit is set?  Can an ACK contain a "Sequence Number" TLV?

  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.

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.

Section 4.1:

  Each PW is associated with a counter to keep track of the sequence
  number of the transmitted MAC withdrawal messages.  Whenever a node
  sends a new set of MAC TLVs, it increments the transmitted sequence
  number counter, and include the new sequence number in the message.
  The transmit sequence number is initialized to 1 at the onset.

I'm pretty sure this is supposed to mean that the sequence number in the first message is 1.  The text could be interpreted to mean that the counter is initialized to 1 and then incremented to 2 when sending the first message.

  The retransmission MUST be
  ceased anytime when ACK is received or after three retries.  This
  avoids unended retransmissions in the absence of acknowledgements.
  Since retransmission time interval and the maximum number of retries
  is local configuration of the sender node, it is up to the
  implementers to pick a discipline.

Is the maximum number of retransmissions 3 or is it locally configured?  Is the default 3?

  The 'R' reset bit is set in the first MAC withdraw
  to notify the remote peer to reset the send and receive sequence
  numbers.  The 'R' bit must be cleared in subsequent MAC withdraw
  messages after the acknowledgement is received

"First" as in "first message after reset or restart or ???  Would it be better to say "The R-bit is set in a message when one peer needs to force the remote peer to reset its send and receive sequence numbers"?  Does the device sending the message with the R-bit use a sequence number of 1 in that message, and expect the next message from the peer to have a sequence number of 1?  It would be helpful to state explicitly that a receiver does not compare the contents Sequence Number TLV against the expected sequence number if the R-bit is set in a message.

  The exact processing on how to handle the
  sequence number overflow is described in [RFC4385]

If this sentence refers to section 4 in RFC 4385, then it describes similar processing for a 16 bit sequence number, not "the exact processing".  I know I'm being finicky again, but it's crucial that implementors get this sequence number processing right.

Minor issues: (none)

Nits/editorial issues:

Is there a reason this document does not use RFC 2119 terminology?

In the Introduction, I think it would be clearer to explain the general problem first, and then refer back to RFC 4762 and RFC 6478 as the standards on which this document draws.

Section 2:

s/Provide/Provider/ in the definition of PE?

Section 3:

In general, I think it's better to specify protocol behavior once and only onc.  As an example, this text:

  the sender re-transmits the message for
  a configured number of times in the absence of an ACK response for
  the sequence numbered message.

is somewhat redundant with the text describing retransmission in the following section.  In fact, much of the entire first paragraph of section 3 describes protocol behavior rather than message format, and might better be combined with the corresponding text in section 4.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 15 Oct 2015 19:44:34 -0400

Hi Ralph -
Thanks for your thorough review.

Let me first address your major concern.

As you point out, this draft builds on existing standards.
We (authors and WG) had to carefully balance between the right amount of information
and wanting to describe details of methods described in other RFCs.

This is frustrating to implementer (including myself) having to go back and forth
between the documents. So I share that concern.

But we would like to refrain from indulging in beefing up the doc and risk deviating
from other base standards. However, for certain, if there is any conflict or lack of
clarity, we would prefer to rectify.

To that end, I would rather prefer, trimming by removing conflicting/confusing text.
For example, sequence number processing - I rather would ask reader to get all details
from relevant RFC, and point to only delta (which is to apply same logic that is used
for 16-bit sequence number field to 32-bit field sequence number field that is used in
this document).

More comments in line.. and I look forward to your further guidance so we can wrap this 
up in time.

As a data point, there are two implementations of this draft deployed in a Telco network 
in Asia.

Thanks,
Himanshu

-----Original Message-----
From: Ralph Droms (rdroms) [mailto:[email-masked]] 
Sent: Wednesday, October 14, 2015 4:02 PM
To: A. Jean Mahoney; General Area Review Team; [email-masked]
Subject: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

Summary:

Major issues:

[Himanshu>] Please see above for the justification of this approach.

Section 1:

[Himanshu>] I would prefer taking the text out if its mention in "Introduction" section is not desirable.
Wildcard MAC withdraw is a very well-known concept in VPLS architecture and needs no more description to L2VPNers, IMO.
So absence of its reference in subsequent sections does not dilute the purpose of this document. 

Section 3:

[Himanshu>] I agree with you. This is statement is used loosely.
The PW OAM message header is meant to apply only to first 4 bytes.

Perhaps -
"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"

[Himanshu>] Yes. It is important to determine the "newness" of the message first for processing eligibility and should not require
hunting through entire message to find that TLV. My hope is that this is obvious to the reader who 'follows' the concepts in the draft.

If you feel, that such an explicit mention is necessary, I do not mind.

[Himanshu>] I do not quite follow. ACK HAS TO INCLUDE THE SEQ NO TLV, how else receiver know what is ACK of 
what seq# message is of? I think this falls into commonsense category BUT, the text explicitly says that ONLY
MAC TLVs are not required.

[Himanshu>] OK.
[Himanshu>] How about this paragraph -

The lack of reliable transport protocol for the in-band OAM necessitates a presence of 
sequencing scheme so that the receiver can recognize newer message from retransmitted
older messages. The [RFC4385] describes details of sequence number handling which include
overflow detection. This document leverages the same scheme, with the exception of overflow
detection which is simplified here such that sequence number exceed 2,147,483,647 (0x7fffffff) is 
considered overflow and reset to 1.

Section 4.1:

I'm pretty sure this is supposed to mean that the sequence number in the first message is 1.  The text could be interpreted to mean that the counter is initialized to 1 and then incremented to 2 when sending the first message

[Himanshu>] 
[Himanshu>] No. The text is correct. Each endpoint keeps the record of send and receive sequence number. These values are initialized to 1.
If the sender sends the first MAC withdraw with sequence number 1, then receiver will ignore because it does not think that received MAC withdraw
is new. So starting MAC withdraw send seq# is in fact 2. Do note that the purpose of the seq# logic is ONLY to detect the received message as NEWER than what was ack'ed
before or re-transmits due to in-transits.

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Fri, 16 Oct 2015 20:21:35 +0000

Hi, Himanshu - responses in line...

> On Oct 15, 2015, at 7:44 PM 10/15/15, Shah, Himanshu <[email-masked]> wrote:
> 
> Hi Ralph -

I agree that, in general, duplicating specifications from other documents increases the possibility that the respective documents unintentionally conflict with each other or are not updated in parallel.
> To that end, I would rather prefer, trimming by removing conflicting/confusing text.

I wasn't clear in my review - I think making the references to other documents concise and clear, along with trimming unnecessary text from draft-ietf-pals-mpls-tp-mac-wd, will result in the best document.

> for 16-bit sequence number field to 32-bit field sequence number field that is used in

This example is sort of an interesting one to consider, as I was thinking more of the examples in which the format and semantics of the MAC TLVs are exactly the same as in the cited defining documents.

> As a data point, there are two implementations of this draft deployed in a Telco network

Noted.

> [Himanshu>] Please see above for the justification of this approach.

Again, I wasn't clear in my review - my paging back and forth was both within draft-ietf-pals-mpls-tp-mac-wd and between draft-ietf-pals-mpls-tp-mac-wd and cited documents.  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.

> So absence of its reference in subsequent sections does not dilute the purpose of this document.

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.

> If you feel, that such an explicit mention is necessary, I do not mind.

I think it would be helpful to state explicitly that the Sequence Number TLV MUST be the first TLV in the message.

> MAC TLVs are not required.

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.
  The acknowledgment message contains a Sequence Number TLV to indicate which
  message is being acknowledged.

...which raises a question about error handling: does the acknowledgment indicate simple receipt of the MAC Address Withdraw OAM message or does it also include successful processing?  Are there any error conditions that should be signaled?  If not, perhaps that should be made explicit in the specification.

> considered overflow and reset to 1.

Again not meaning to be finicky, the term "overflow" is not used anywhere in RFC 4385, so RFC 4385 doesn't define "overflow detection".  I think what you mean is that the sequence number mechanism is treated as a 31-bit number space, instead of a 16-bit number space as in RFC 4385, which means:

* the expected sequence number that follows 2^31-1 (maximum unsigned 31-bit number) is one, and
* if the packet sequence number is greater than the expected sequence number, and the packet sequence number minus the expected sequence number is less than 2^30

In my opinion, it would be clearer to just call out those specific changes and otherwise refer to the text in section 4.2 of RFC 4385.

> before or re-transmits due to in-transits.

OK.  Might be helpful to add a phrase "and the sequence number of the first transmitted message is therefore 2"

(Himanshu - your e-mail to me is truncated at this point in my mail reader)

- Ralph

---

From: Jari Arkko <[email-masked]>
Date: Thu, 22 Oct 2015 10:44:37 +0100

Ralph, many thanks for your in-depth review! And thanks for being on the Gen-ART team. And than you Himanshu for suggesting ways to deal with the issues.

I agree with Ralph that there are points where this document could be clearer. The one case that I felt personally strongly about was the part about what number the sequence numbers must start from. The text makes the reader wonder if one should read it literally, or if the starting number is handled differently. It would be better to be explicit.

I have balloted no-obj for this document, but would very much like to see the discussion with Ralph continue and some changes based on the comments adopted.

Jari

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Thu, 22 Oct 2015 15:19:38 +0000

(originally sent 10/16)

Noted.

- Ralph

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 22 Oct 2015 11:22:08 -0400

Can not see your message content.
PLEASE send without MIME...

Thanks,
Himanshu

From: Ralph Droms (rdroms) [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 11:20 AM
To: Shah, Himanshu
Cc: A. Jean Mahoney; General Area Review Team; [email-masked]; The IESG
Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Thu, 22 Oct 2015 15:26:36 +0000

The archived message in the gen-art list is available here: http://www.ietf.org/mail-archive/web/gen-art/current/msg12413.html

> On Oct 22, 2015, at 11:22 AM 10/22/15, Shah, Himanshu <[email-masked]> wrote:
> 
> PLEASE send without MIME…
> 
> Thanks,
> Himanshu
>

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Thu, 22 Oct 2015 15:29:04 +0000

(originally sent 10/16; second try)

Noted.

- Ralph

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 22 Oct 2015 11:29:28 -0400

Still no luck. No message content.

Andy Malis – is it possible for you to send Ralph’s email?

Thanks,
Himanshu

From: Ralph Droms (rdroms) [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 11:27 AM
To: Shah, Himanshu
Cc: A. Jean Mahoney; General Area Review Team; [email-masked]; The IESG
Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 22 Oct 2015 11:31:08 -0400

Aahh! Finally got it with content!!..

Let me go through your email..

Thanks,
Himanshu

-----Original Message-----
From: Ralph Droms (rdroms) [mailto:[email-masked]] 
Sent: Thursday, October 22, 2015 11:29 AM
To: Shah, Himanshu
Cc: A. Jean Mahoney; General Area Review Team; [email-masked]; The IESG
Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

> We (authors and WG) had to carefully balance between the right amount 
> of information and wanting to describe details of methods described in other RFCs.
> 
> This is frustrating to implementer (including myself) having to go 
> back and forth between the documents. So I share that concern.
> 
> But we would like to refrain from indulging in beefing up the doc and 
> risk deviating from other base standards. However, for certain, if 
> there is any conflict or lack of clarity, we would prefer to rectify.

> For example, sequence number processing - I rather would ask reader to 
> get all details from relevant RFC, and point to only delta (which is 
> to apply same logic that is used for 16-bit sequence number field to 
> 32-bit field sequence number field that is used in this document).

> 
> More comments in line.. and I look forward to your further guidance so 
> we can wrap this up in time.
> 
> As a data point, there are two implementations of this draft deployed 
> in a Telco network in Asia.

Noted.

> To: A. Jean Mahoney; General Area Review Team; 
> [email-masked]

> 
> Section 1:
> 
> When the number of MAC addresses to be removed is large, the empty MAC 
> List TLV may be used.  The empty MAC List TLV signifies wildcard MAC 
> Address withdrawl.
> 

> 
> Section 3:
> 
> The PW OAM message header is exactly the same as what is defined in 
> [RFC6478].
> 
> "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"
> 
> 
> 
> a MAC address withdraw OAM message MUST contain a "Sequence Number 
> TLV" otherwise the entire message is dropped.
> 
> [Himanshu>] Yes. It is important to determine the "newness" of the 
> message first for processing eligibility and should not require hunting through entire message to find that TLV. My hope is that this is obvious to the reader who 'follows' the concepts in the draft.
> 

> [Himanshu>] I do not quite follow. ACK HAS TO INCLUDE THE SEQ NO TLV, 
> how else receiver know what is ACK of what seq# message is of? I think 
> this falls into commonsense category BUT, the text explicitly says that ONLY MAC TLVs are not required.

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

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Thu, 22 Oct 2015 20:13:34 +0000

Himanshu - I have one clarification to my review: I should have written "Is there a reason this document does not use RFC 2119 terminology throughout?"

...and even that is likely an unfair assessment, as RFC 2119 language more or less everywhere needed for clarity.

My apologies for the inaccuracy.

- Ralph

> On Oct 22, 2015, at 11:31 AM 10/22/15, Shah, Himanshu <[email-masked]> wrote:
>

---

From: "Shah, Himanshu" <[email-masked]>
Date: Sat, 24 Oct 2015 15:59:59 -0400

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]

[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] 

[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:

[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:[email-masked]] 
Sent: Thursday, October 22, 2015 11:29 AM
To: Shah, Himanshu
Cc: A. Jean Mahoney; General Area Review Team; [email-masked]; The IESG
Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

Noted.

---

From: "Shah, Himanshu" <[email-masked]>
Date: Sat, 24 Oct 2015 16:03:48 -0400

Hi Ralph -

The document is going by the guidance of RFC2119 that imperatives should be used with care and sparingly for interoperation (e.g. section 4). 

If clarity is needed on other sentences in the document, can you identify?

Thanks,
Himanshu

-----Original Message-----
From: Ralph Droms (rdroms) [mailto:[email-masked]] 
Sent: Thursday, October 22, 2015 4:14 PM
To: Shah, Himanshu
Cc: General Area Review Team; [email-masked]; The IESG
Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

- Ralph

> Cc: A. Jean Mahoney; General Area Review Team; 
> [email-masked]; The IESG
>> For example, sequence number processing - I rather would ask reader 
>> to get all details from relevant RFC, and point to only delta (which 
>> is to apply same logic that is used for 16-bit sequence number field 
>> to 32-bit field sequence number field that is used in this document).
> 
>> More comments in line.. and I look forward to your further guidance 
>> so we can wrap this up in time.
>> 
>> When the number of MAC addresses to be removed is large, the empty 
>> MAC List TLV may be used.  The empty MAC List TLV signifies wildcard 
>> MAC Address withdrawl.
>> 
>> how else receiver know what is ACK of what seq# message is of? I 
>> think this falls into commonsense category BUT, the text explicitly says that ONLY MAC TLVs are not required.
> 
> 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
>

---

From: "Shah, Himanshu" <[email-masked]>
Date: Sat, 24 Oct 2015 17:52:21 -0400

One more update that was discussed in previous emails but not included in your last email -

Original text: 

[Ralph]

[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 (0x7FFFFFFF) 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; [email-masked]; The IESG
Subject: RE: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

---

----
[ralph]

[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]

[Himanshu] added.
----

---

Thanks,
Himanshu

-----Original Message-----
From: Ralph Droms (rdroms) [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 11:29 AM
To: Shah, Himanshu
Cc: A. Jean Mahoney; General Area Review Team; [email-masked]; The IESG
Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

Noted.

---

From: "Shah, Himanshu" <[email-masked]>
Date: Sat, 24 Oct 2015 17:55:41 -0400

Here is the updated draft.
Please review..

The draft addresses the comments received from the reviewers.
Once review is complete and IETF submission opens up, I will post the updated 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'; [email-masked]'; 'The IESG'
Subject: RE: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

Original text: 

[Ralph]

[Himanshu>] 

New text:

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; [email-masked]; The IESG
Subject: RE: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

---

----
[ralph]

-----
[ralph]

[Himanshu] added.
----

---

Thanks,
Himanshu

-----Original Message-----
From: Ralph Droms (rdroms) [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 11:29 AM
To: Shah, Himanshu
Cc: A. Jean Mahoney; General Area Review Team; [email-masked]; The IESG
Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

Noted.

---

From: "Shah, Himanshu" <[email-masked]>
Date: Sat, 24 Oct 2015 17:56:22 -0400

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'; [email-masked]'; 'The IESG'
Subject: RE: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

Original text: 

[Ralph]

[Himanshu>] 

New text:

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; [email-masked]; The IESG
Subject: RE: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

---

----
[ralph]

-----
[ralph]

[Himanshu] added.
----

---

Thanks,
Himanshu

-----Original Message-----
From: Ralph Droms (rdroms) [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 11:29 AM
To: Shah, Himanshu
Cc: A. Jean Mahoney; General Area Review Team; [email-masked]; The IESG
Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

Noted.

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Mon, 26 Oct 2015 17:02:29 +0000

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 <[email-masked]> wrote:
> 
> Now with the draft..
> 
> Thanks,
> Himanshu
> 
> 
> <draft-ietf-pals-mpls-tp-mac-wd-03.txt>

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Mon, 26 Oct 2015 17:10:35 +0000

- Ralph

---

From: "Shah, Himanshu" <[email-masked]>
Date: Mon, 26 Oct 2015 13:04:31 -0400

Can you send the email without MIME signature?

Thanks,
Himanshu

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

---

From: "Shah, Himanshu" <[email-masked]>
Date: Mon, 26 Oct 2015 14:07:36 -0400

Thanks Ralph..

Himanshu

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

- Ralph

> Withdraw OAM message <draft-ietf-pals-mpls-tp-mac-wd-03.txt>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 26 Oct 2015 14:07:47 -0400

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 <[email-masked]> wrote:

> *Can you send the email without MIME signature?*
>
>
>
> *Thanks,*
>
> *Himanshu*
>
>
>
> *From:* Ralph Droms (rdroms) [mailto:[email-masked]]
> *Sent:* Monday, October 26, 2015 1:02 PM
> *To:* Shah, Himanshu
> *Cc:* A. Jean Mahoney; General Area Review Team;
> *Subject:* Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
>
>
>
>
>

---

From: "Shah, Himanshu" <[email-masked]>
Date: Mon, 26 Oct 2015 14:09:19 -0400

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:[email-masked]]
Sent: Monday, October 26, 2015 2:08 PM
To: Shah, Himanshu
Cc: Ralph Droms (rdroms); A. Jean Mahoney; General Area Review Team; [email-masked]; The IESG
Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

Himanshu,

Ralph said:

- Ralph

On Mon, Oct 26, 2015 at 1:04 PM, Shah, Himanshu <[email-masked]<mailto:[email-masked]>> wrote:
Can you send the email without MIME signature?

Thanks,
Himanshu

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

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Mon, 26 Oct 2015 19:12:53 +0000

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 <[email-masked]> wrote:
> 
> Thanks Andy.

---

From: "Shah, Himanshu" <[email-masked]>
Date: Mon, 26 Oct 2015 19:04:54 -0400

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:[email-masked]] 
Sent: Monday, October 26, 2015 3:13 PM
To: Shah, Himanshu
Cc: Andrew G. Malis; A. Jean Mahoney; General Area Review Team; [email-masked]; The IESG
Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

- Ralph