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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Gregory Mirsky writes:
> > Curtis
> > > Greg

I fixed this for consistent quoting.

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

Thanks.  See inline.

Curtis

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

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?

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

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.

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

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

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.

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