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

From: Gregory Mirsky <[email-masked]>
Date: Mon, 4 Mar 2013 17:32:36 +0000

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.

[...]

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 06 Mar 2013 12:14:24 -0500

In message <[email-masked]>
Gregory Mirsky writes:
> > Curtis

I fixed this for consistent quoting.

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

Thanks.  See inline.

Curtis

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

Some implementations predate RFC5586 but comply to RFC5085.  Those
implementations SHOULD support CW.  Those implementations using
MPLS-TP and RFC5586 MUST support CW.

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

The entire bullet would be changed to:

   5.  The implementor and system designer MUST support pseudowire
       control word if MPLS-TP is supported or if ACH is being used on
       a pseudowire [RFC5586].  Deployments SHOULD enable pseudowire
       control word.  See Section 2.4.1.  Implementations which
       predate [RFC5586] but comply to only [RFC5085] SHOULD support
       pseudowire control word.

Is that now sufficiently clear with the wording about predating
RFC5586 and supporting only RFC5085?

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

PTP is defined as independent of what it is carried over.  IEEE made
specific recommendations regarding carrying PTP over Ethernet and IP.
NTP was defined as running over IP.  draft-ietf-tictoc-1588overmpls
exists solely to allow either PTP or NTP to run directly over MPLS.

For example, draft-ietf-tictoc-1588overmpls would allow PTP over MPLS
over GFP over ODU4, where there is no Ethernet header or IP header
anywhere in the packet.

I don't think we have to say "carried over MPLS and something useful
done at the other end".  There is no purpose in carrying NTP or PTP
over MPLS and discarding the packet at the egress.  The "do something
useful" part should be obvious, and if not the reader can refer to the
cited draft.

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

Not they are not your notes.  See above where I stated "I'm not sure
what your objection is.  Here is the paragraph sentence by sentence
with annotation.  Also note the depth of quoting.

Since your followup was to the first sentence, I think that your
objection was to that sentence.  If you are OK with the notion that
"doing something useful at the other end" is implied, then we can move
on.

> > 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 is about the hash seed.  It could be shortenned to
> > get rid of the redundancy yet keep discussion of the hash seed
> > separate.
> >  
> 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".

There is no RFC that defines special purpose labels.  RFC3032 and
http://www.iana.org refer to "reserved labels".  Until there is at
least a WG doc defining special purpose labels this document will call
them reserved labels.  If/when there is a WG doc, then it is easy to
change.

> > 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)."
> >  
> > 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
> > 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:
> >  
> > 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.
> >  
> > [...]

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 27 Mar 2013 22:53:03 +0000

Hi Curtis,
back to our discussion on 1588overMPLS. I've attached slide from deck presented at TICTOC meeting in Orlando as illustration of what I mean by "PTP distribution through MPLS network".

PTP/NTP Transport over MPLS network can be done without any special PTP LSP (another slide from the same deck)

        Regards,
                Greg

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]]
Sent: Wednesday, March 06, 2013 9:14 AM
To: Gregory Mirsky
Cc: [email-masked]; [email-masked]; [email-masked]; Loa Andersson; [email-masked]; Martin Vigoureux; Eric Osborne (eosborne); Thomas Nadeau; Thomas Beckhaus
Subject: Re: MPLS-RT review of draft-villamizar-mpls-forwarding

Thanks.  See inline.

Curtis

> > used on a pseudowire [RFC5586]."  MPLS-TP and RFC5586 (G-ACh and
> > GAL) are cited as the reason for this requirement being a MUST.
> >

Some implementations predate RFC5586 but comply to RFC5085.  Those implementations SHOULD support CW.  Those implementations using MPLS-TP and RFC5586 MUST support CW.

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

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

PTP is defined as independent of what it is carried over.  IEEE made specific recommendations regarding carrying PTP over Ethernet and IP.
NTP was defined as running over IP.  draft-ietf-tictoc-1588overmpls exists solely to allow either PTP or NTP to run directly over MPLS.

For example, draft-ietf-tictoc-1588overmpls would allow PTP over MPLS over GFP over ODU4, where there is no Ethernet header or IP header anywhere in the packet.

I don't think we have to say "carried over MPLS and something useful done at the other end".  There is no purpose in carrying NTP or PTP over MPLS and discarding the packet at the egress.  The "do something useful" part should be obvious, and if not the reader can refer to the cited draft.

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

Not they are not your notes.  See above where I stated "I'm not sure what your objection is.  Here is the paragraph sentence by sentence with annotation.  Also note the depth of quoting.

Since your followup was to the first sentence, I think that your objection was to that sentence.  If you are OK with the notion that "doing something useful at the other end" is implied, then we can move on.

> > > 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
> > > The last paragraph seams repetitive of third paragraph. Perhaps
> > > the last one can be merged into the third as:
> > >
> > 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.
> >
> noticed that "special purpose labels" becomes more and more used vs.
> "reserved labels".

There is no RFC that defines special purpose labels.  RFC3032 and http://www.iana.org refer to "reserved labels".  Until there is at least a WG doc defining special purpose labels this document will call them reserved labels.  If/when there is a WG doc, then it is easy to change.

> > 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
> > > 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.
> >
> > interworking document that we can cite, then please point it out.
> > For now, we cite the documents that exist:
> >
> > 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.
> >
> > [...]

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 28 Mar 2013 16:32:31 -0400

In message <[email-masked]>
Gregory Mirsky writes:
 
> Hi Curtis,
>  
> back to our discussion on 1588overMPLS. I've attached slide from deck
> presented at TICTOC meeting in Orlando as illustration of what I mean
> by "PTP distribution through MPLS network".
>  
> PTP/NTP Transport over MPLS network can be done without any special
> PTP LSP (another slide from the same deck)
>  
>  
>         Regards,
>                 Greg

Greg,

Perhaps I am missing your point.  Unless the point it to marvel over
the artwork in the otherwise not very informative slides.

There are two encapsulations shown:

    LSP     LSP
    IP      PW
    UDP     CW
    PTP     Ethernet
            PTP

This just makes it a little hard for the midpoint LSR to do the PTP
correction field update, but otherwise ... so what.

If the LSP midpoint nodes make no corrections, then accuracy suffers.

The midpoint LSR must either: 1) know that the payload is IP or know
that the payload is PW (it doens't today), or guess based on CW or
lack of, and 2) know that the packet might contain PTP, and 3) look at
every packet in the LSP.

I mentioned in the draft that a timestamp has to be captured when a
packet is received and generated and inserted when a packet is sent.
I also mentioned that the offset is variable.  For example in the PW
case, the Ethernet header could have a VLAN ID.

The PTP forwarding correction requires updating a timestamp
compensation field based on the difference between packet arrival and
packet send times.  Perhaps what you are saying is that we don't call
out the need to support that difference plus offset (offset by the
existing compensation).  Of course, the offset and receive stamp can
be added together in software or in less critically time constrained
hardware, with the send stamp subtracted as close to packet transmit
time as possible.

If that is not what you meant, then what exactly is your point?

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 30 Mar 2013 16:35:37 -0400

Greg,

I've added the following (new text following "+" signs):

   PTP or NTP may be carried over MPLS
   <xref target="I-D.ietf-tictoc-1588overmpls" />.  Generally NTP will
   be carried within IP with IP carried in MPLS
   <xref target="RFC5905" />.  Both PTP and NTP benefit from accurate
   time stamping of incoming packets and the ability to insert
   accurate time stamps in outgoing packets.
+  PTP correction which occurs when forwarding requires updating a
+  timestamp compensation field based on the difference between packet
+  arrival at an LSR and packet transmit time at that same LSR.

Does this address any remaining PTP issues?

Curtis

In message <[email-masked]>
Curtis Villamizar writes:

Greg,

    LSP     LSP
    IP      PW
    UDP     CW
    PTP     Ethernet
            PTP

Curtis