Re: [mpls] MPLS-RT review of draft-villamizar-mpls-forwarding

[Gregory Mirsky <[e-mail]>]

Hi Curtis,
I've snipped RT part. Please find my notes in-lined tagged by GIM>>

        Regards,
                Greg

[...]

> As I read the document I put some notes that you might consider as
> regular comments:
>
> Need to build list of acronyms

Will do.  I'll look to RFC 5513 for guidance.

> Section 1.2, bullet 5
> With definition of Control Channel Type 4 in PW VCCV "MUST" can be
> changed to "SHOULD". The last sentence might be reworded to
> "Deployments SHOULD allow enabling and disabling use of PW Control
> Word".

Please notice the phrase "if MPLS-TP is supported or if ACH is being used on a pseudowire [RFC5586]."  MPLS-TP and RFC5586 (G-ACh and GAL) are cited as the reason for this requirement being a MUST.

In rereading this I notice that we should add "The implementor and system designer SHOULD support pseudowire control word if MPLS-TP and
RFC5586 are not used [RFC5085]."
GIM>> Even though RFC 5586 excluded GAL from being used on MPLS -TP PWs, I believe that there's rough agreement in PWE3 WG that PW VCCV Control Channel Type 4 will be applicable to MPLS-TP PWs when Type 1 (ACH) not in use. Hence was my suggestion to change from "MUST" to "SHOULD". Then, since PW CW is SHOULD, we need to say something about GAL, PW VCCV Control Channel Type 4. I'd put it at SHOULD too with addition of "deployments SHOULD be able to use Type 4 Control Channel is use of PW CW is not mandatory".

That should make it more clear (SHOULD if RFC5085 compliant only, MUST if using MPLS-TP and/or RFC5586 compliant).

> Section 1.3, bullet 4
> Can these tests or any subset of them be viewed as MPLS forwarding
> performance benchmarking tests (BMWG)?

Al Morton (BMWG chair) is aware of this work and has forwarded a pointer to BMWG.  Jay Karthik commented on BMWG.  Work is to continue in MPLS, but when things have settled down, BMWG may apply the level of rigor they normally apply to assure consistent testing where there is sufficient interest in standardizing test procedures.

> Section 2.1.1
> Reference to Extended Special Purpose MPLS Labels in the section?

If and when it becomes a WG document.  There is no dependency on that draft and it is best to not refer to work that may not advance.  Keep in mind that draft-kompella-mpls-special-purpose-labels changes the use of reserved labels, by assigning new meaning to label 15.

BTW- I think draft-kompella-mpls-special-purpose-label is good work and IMO it should go through this WG RT process and a call should be made to make it a WG document.

> Section 2.1.3
> First sentence: I think that "MPLS LSP may be used to carry NTP or PTP
> and synchronize clocks ..." might be closer to the goal of
> 1588overmpls document.

I'm not sure what your objection is.  Here is the paragraph sentence by sentence with annotation.

   PTP or NTP may be carried over MPLS [I-D.ietf-tictoc-1588overmpls].

GIM>> I think of "carried over" as Ethernet carried over MPLS in PW. The purpose of 1588overMPLS is not only carry NTP or PTP over MPLS domain but to distribute clock synchronization according to capabilities of LSRs.

      That is exactly as you pointed out.  I'm a little concerned that
      this work may have stalled.

   Generally NTP will be carried within IP with IP carried in MPLS
   [RFC5905].

      That says that NTP has traditionally gone over IP with IP
      carried over MPLS.  I don't think there is an argument there.

   Both PTP and NTP benefit from accurate time stamping of incoming
   packets and the ability to insert accurate time stamps in outgoing
   packets.

      I don't think anyone would argue this point.

Could you point out what you think needs to be changed?  Is it some other paragraph?

GIM>> Don't think that these are my notes. I had only one comment to section 2.1.3

> Section 2.1.7
> Could the section be named "MPLS-TE Local Protection" or "MPLS-TE Fast
> Reroute" as RFC 4090 is applicable only to RSVP-TE signaled LSP.

RFC4090 has always been known within the IETF as MPLS Fast Reroute or MPLS FRR.  If at some point there is acceptance of IPFRR and extensions to IPFRR to support LDP, then mpls-forwarding-bis can rename these sections.

[...]

> Section 2.4
> The last paragraph seams repetitive of third paragraph. Perhaps the
> last one can be merged into the third as:
>
>    In order to support an adequately balanced load distribution across
>    multiple links, IP header information must be used.  Common
>    practice today is to reinspect the IP headers at each LSR and use
>    the label stack and IP header information in a hash performed at
>    each LSR in the network, combined with a hash seed that is selected
>    by each LSR.  Where flow labels or entropy labels are used, a hash
>    seed must be used. Further details are provided in Section 2.4.5.

The last paragraph is about the hash seed.  It could be shortenned to get rid of the redundancy yet keep discussion of the hash seed separate.

   Common practice today is to reinspect the packet at each LSR and
   use information from the packet combined with a hash seed that is
   selected by each LSR.  Where flow labels or entropy labels are
   used, a hash seed must be used when creating these labels.

Is that OK with you?
GIM>> Thank you, it works.

> Section 2.4.5.1
> bullet 3: Following on draft-kompella-mpls-special-purpose-labels-
>   would suggest changing "reserved labels" to "special purpose labels"
>   with note that these might be of one MPLS label element length or
>   two elements (extension label + extended special purpose label).

For now we are not citing draft-kompella-mpls-special-purpose-labels
When (if) it becomes draft-ietf-mpls-special-purpose-labels, we'll make changes.

Note that Kireeti is a co-author of this document and is OK with that.
GIM>> Clearly it is up to authors how to select terminology. I just noticed that "special purpose labels" becomes
more and more used vs. "reserved labels".

> bullet 5: I believe it is possible that first nibble of MAC is
>   either 4 or 6. If that is the case, then use of the first nibble of
>   the payload to determine its type and apply casting might cause
>   re-ordering for Ethernet PWs. Perhaps it can be provided as
>   rationale to control whether node performs first nibble
>   interpretation or not.

Note the wording "an implementation SHOULD support the ability", and the statement "If supported, there MUST be a way to disable it (if, for example, PW without CW are used)."

The "MUST be able to disable it" (sic) covers the case where a MAC starts with 4 or 6 in the first nibble.

Also note that the xml has the following comment:

   <!--
   draft-ietf-pwe3-vccv-impl-survey-results recommends that the
   control word always be used.  Some service providers require
   control word support for all encapsulations, and always use it.
   -->

We didn't cite draft-ietf-pwe3-vccv-impl-survey-results because the draft seems to be stuck.  Andy is co-author and PWE3 chair and he's OK with this.  If it gets unstuck we'll add a sentence.

> Section 2.6.4 or 2.6.5
> Whether in discussing MPLS-TP OAM or MPLS OAM and Layer 2 OAM
> interworking might discuss issue of MPLS-TP CC interval matching CCM
> intervals in IEEE 802.1ag/Y.1731 and difference in determining Loss of
> Connectivity between BFD-based CC and Ethernet OAM.

I think that is too much detail on OAM.  If there is an OAM interworking document that we can cite, then please point it out.  For now, we cite the documents that exist:

  RFC6670, RFC6310, draft-ietf-pwe3-mpls-eth-oam-iwk (just about out
  of the IESG, so an RFC soon).

In IETF there is only one MPLS-TP OAM.  We are not going to fight that battle in this document.

If 802.1ag/Y.1731 is a server layer, then MPLS-TP timers have to be set a half decimal order of magnitude or more longer.  If PW is a server layer, then 802.1ag/Y.1731 timers have to be set a half decimal order of magnitude or more longer.  But this level of detail does not belong here.

[...]