Subject: [mpls] Genart last call review of draft-ietf-mpls-rfc6374-sfl-08

From: Elwyn Davies via Datatracker <[email-masked]>
Date: Tue, 02 Feb 2021 07:27:30 -0800

Reviewer: Elwyn Davies
Review result: Not Ready

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-mpls-rfc6374-sfl-??
Reviewer: Elwyn Davies
Review Date: 2021-02-02
IETF LC End Date: 2021-01-26
IESG Telechat date: Not scheduled for a telechat

Summary:  Not Ready.  Apologies that this review is rather late, but I found this 
document extremely hard to work with.  There appear to be a number of areas where 
the work is rather too much in progress rather than ready for publication as an RFC.  
I also found it very difficult, not just as someone who is not at all familiar with this
area of work, but at a basic technical level to work out what the protocol was going 
to be able to achieve and whether a LSR would garner the information it appeared 
to need to deliver what was clamed.  Part of this appeared to be due to multiple 
names being used for the same thing and being used with other than their natural 
meaning particulaly in sections 7.1 and 7,2. 

Major Issues:

s7, What is being standardized?:

>     A number of methods are described.  The expectation is that the MPLS
>     WG possibly with the assistance of the IPPM WG will select one or
>     maybe more than one of these methods for standardization.
>
I find this statement very confusing.  This document is intended for
standards track, so if it goes ahead as is, the three methods are
standardised and implementors would be expected to provide support for
all of them unless there are to be words to indicate that not all need
to be supported.   Is this the intention? Or is it that this document
should only support the methods chosen by the MPLS working group?  In
the latter case, this document is definitely not ready for
standardization; I assume the unused method(s) would be removed in this
case.  Otherwise the second sentence is speculative and should be removed.

s7, Title, purpose and general method:

Note that I have very limited knowledge of this area of performance
measurement so there may be misunderstandings here. However, given that
caveat, I did not find the document very helpful in enlightening me and
a considerable amount of background reading was needed to try and
determine what was going on.

Firstly, I assume that this section covers the 'additional techniques'
mentioned in the Abstract  and described as 'more sophisticated
measurements' in s1. [Perhaps common phraseology would be desirable
between the two cases.]  I suggest a sentence to make this clear would
be desirable.

Secondly, AFAICS these techniques are basically about measuring and
communicating  delay jitter in various ways.  It might be helpful to
link what is being offered here with RFC 5481 and the discussion of
delay variation measurement in RFC 6374.  Section 7.1 is, as I
understand it, covering IPDV measurement using (in general) normal
service packets rather than just specialised RFC 6374 packets and
working primarily on one LSR.  I assume that the technique in s7.2 is
primarily a means for reporting measurements derived from s7.1 and/or
s7.4, but given that actual delays are mentioned rather than
inter-packet gaps, the

s7.1: After the first sentence, the first paragraph talks about delay. 
Since the receiving LSR has no knowledge of the transmission time of
each individual packet, it is not possible for the LSR to calculate
actual delays without additional information - I take it that the
packets are not intended to be RFC 6374 Delay Measurement Packets as
these would require corresponding responses which would contravene the
query interval setting  and there does not appear to be a way for the
LSR doing the measurements to be told the inter-packet transmission
interval.  Should this be written in terms of inter-packet gaps rather
than delays throughout?  Further, The first paragraph describes two
methods of operation without saying which one should be standardised or
AFAICS providing a selection flag to allow either to be used.

It seems to me that an outline of how this facility might be used is
pretty much essential.  Would I be right in thinking that to measure the
delay jitter between a source LSR (S) and destination LSR (D), the
operator decides to send a set of packets at equally spaced intervals
from S to D and decides on the interval and the number of packets.  S
then issues a Query setting the query interval to a time greater than
that needed to send the  set of packets and using the Bucket Jitter
Measurement Message to set the bucket delay intervals around the
sending  interval according to the Operator's expectations of the
network.  D then sets up to measure the inter-packet delays up until the
next Bucket Jitter Measurement message arrives after the elapse of the
query interval when D returns  the profile of inter-packet delays.

Does the arrival of this second Bucket Jitter Measurement Message
trigger a further set of measurements?  And if so, how is the sequence
ended?

s9.1: This section is headed by an Editor's Note saying that the section
needs review which may alter the format of the TLV.  It is thus
impossible to say if this section is ready.

Minor Issues:

s7.2: As with s7.1, there seems to be some confusion bettween delay and
inter-packet gap.

Nits/editorial comments:

Abstract:  The primary purpose of this document, as set out in s1, is to
extend RFC 6374 to cover general MPLS networks rather than primarily
MPLS-TP networks and in particular to add support for
multi-point-to-point LSPs.  I think that it would be helpful for the
casual reader to make this somewhat clearer in the abstract.  I suggest:

OLD:

   This document describes a method of making RFC6374 performance
   measurements on flows carried over an MPLS Label Switched path.  This
   allows loss and delay measurements to be made on multi-point to point
   LSPs and allows the measurement of flows within an MPLS construct
   using RFC6374.
NEW:

   RFC 6374 describes methods of making loss and delay measurements on
   Label Switched Paths (LSPs) primarily as used in MPLS TransportProfile (MPLS-TP)
   networks.  This document describes a method of making RFC6374 performance
   measurements on flows carried over general  MPLS LSPs.  In particular, it extends
   the technique to  allow loss and delay measurements to be made on multi-point to point
   LSPs and introduces some additional techniques to allow more sophisticated
   measurements to be made in both MPLS-TP and general MPLS networks.

ENDS

s1, bullet 4:  Would it be helpful to refer to RFC  7190 with respect to
aggregation?

s1, bullet 5: s/counter again/counter, again/

s3, last sentence: s/co-responding/corresponding/ [co-responding means
responding together rather than matching.  Look up co-respondent in
cases of adultery in the divorce courts!]

s3, last sentence: s/packet/packets/

s4, para 1: Expand TC: s/TC/Trafic Class (TC)/

s5, para 1: s/proxy data service packets Section 4./proxy data service
packets (see Section 4)./

s5, para 2: s/This it is/Thus it is/

s5, para 2: s/are relatively independent/are made relatively independent/

s5, para 3: s/arises for the potential/arises from the potential/

s5, para after Figure 1: s/were/where/

s5, next to last para: s/which ever/whichever/

s6, para 1: s/measurement type/measurement types/;
s/combination/combinations/

s7: I assume these are the additional facilities mentioned in the
Introduction.  It would be helpful to make this clear.

s7.1, para after Figure 2:  The acrronyms QTF, RTF, RPTF and DS should
be expanded.  There is no section 3.7 in RFC 6374.  These items are
defined in Section 3.2.

s7.1: The formats of the various numerical fields are not specified.  I
assume they are unsigned integers.

s7.1, Number of Buckets:  I assume that an LSR is likely to have a limit
for this value.  If the query requests an unsupported amount should
there be a specific error code?

s7.3: s/In other that exception/In other than exceptional/

s7.4: The formats for the time fields in the and the Sum of Timestamps
field are not specified.

s8, first sentence: I am unable to parse 'a delay measurement interval
defined by an SL of constant colour' before being introduced to RFC
8321.   Even then I don't know what SL stands for - it is not used in
RFC 8321 or RFC 6374.

s9: Expand GAL on first use.

s9.1: Expand FEC on first use.

s9.1, para 2: Where is the concept of well-defined array of SFLs defined?

s9.1, Specification of FEC field: 'This is encoded as per Section 3.4.1
of TBD'...  Er, there doesn't seem to be a reference for TBD.

s10: 'A future version of the *this document*...'  Is this a sign of
unfinishedness or an indication that further documents will address this
issue? (apart from the 'the this'.)

s13: I am not sure I can identify the relevant issue in s5.

s14.2: s/request/requested/

s14.2, RFC Editor note:  I presume the RFC Editor should be asked to
delete two lines - the ones before and after the request.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 10 Feb 2021 16:26:04 +0000

> On 2 Feb 2021, at 15:27, Elwyn Davies via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Elwyn Davies
> Review result: Not Ready
> 

That was some old text from an early version that was missed.

> to need to deliver what was clamed.  

This is a document where you need to understand MPLS, coloured marking and  packet delay characteristics, but I think anyone seeking to deploy this would already be familiar with that.

> Part of this appeared to be due to multiple 

I have changed this text in response to other comments received:

It now says 

A number of methods are described. Each of these methods has different
characteristics and different processing demands on the packet forwader.
The choice of method will depend on the type of diagnostic that the operator seeks. 

> determine what was going on.

It is always difficult to get the balance right between a concise document for subject matter experts and a detailed description.

> mentioned in the Abstract

That term does not seem to be in the abstract.

>  and described as 'more sophisticated

I am afraid I cannot see the conflict that you are concerned about.

> communicating  delay jitter in various ways.  

SB> No, Method 1 is measuring jitter. Method 2 is measuring delay as is Method 3

> It might be helpful to
> delay variation measurement in RFC 6374.  

SB> I think we need to assume that the reader is familiar with RFC6374

> Section 7.1 is, as I

SB> All measurements take place on user service data using SFL to 
SB> indicate different groups of packets. We are using RFC6374 to
SB> trigger measurements and collective results.

> than delays throughout?  

SB> 7.1 is measuring the inter packet gaps so as you say is measuring
The variation in the delay rather than the absolute delay. However this
Is made clear in the text.

> Further, The first paragraph describes two

SB> We could do that but there is a need for the operator to configure 
SB> other characteristics of the measurement, for example the size of the 
SB> time increments that the buckets represent, so this would just be another
SB> such characteristic. The math in the analytics engine to convert one
SB> method into the other is trivial (the difference in the techniques is
SB> about collection hardware optimisation) so I don’t think we need to
SB> pick one,

> trigger a further set of measurements?  And if so, how is the sequence

SB> No, you send packets in one color then you change color and then
SB> send an Query message and the response refers to the set of packets
SB> before the colour changed.

SB> The hardware continuously makes the measurement and the 
SB> measurement system collects the results when it wants a test result.

> impossible to say if this section is ready.

SB> That is a note I had forgotten to remove

>   measurements to be made in both MPLS-TP and general MPLS networks.

SB> Thank you that is a good proposal
> s1, bullet 4:  Would it be helpful to refer to RFC  7190 with respect to

SB> Yes, I will add the ref.

> s1, bullet 5: s/counter again/counter, again/

SB> Fixed

> cases of adultery in the divorce courts!]
SB> Thanks. Co-responding seems like a good term to get into a protocol description.

> s3, last sentence: s/packet/packets/
SB> Fixed

> s4, para 1: Expand TC: s/TC/Trafic Class (TC)/
SB> Fixed

> packets (see Section 4)./
SB> fixed

> s5, para 2: s/This it is/Thus it is/

SB> Fixed

> s5, para 2: s/are relatively independent/are made relatively independent/
SB> Text fixed

> s5, para 3: s/arises for the potential/arises from the potential/
SB> Fixed

> s5, para after Figure 1: s/were/where/

SB> Fixed

> s5, next to last para: s/which ever/whichever/

SB> Fixed 

> s/combination/combinations/

SB> Fixed

> Introduction.  It would be helpful to make this clear.

SB> Text added

> be expanded.  There is no section 3.7 in RFC 6374.  These items are

SB> Sorry Typo - thanks - fixed.

> assume they are unsigned integers.

SB> Yes, note added

> there be a specific error code?

         0x1A: Error - Resource Unavailable.  Indicates that the
         operation failed because node resources were not available.

SB> Would be the normal error message

> s7.3: s/In other that exception/In other than exceptional/

SB> Fixed

> s7.4: The formats for the time fields in the and the Sum of Timestamps

SB> The subject of the various timestamp formats is discussed in RFC6374.

> 8321.   Even then I don't know what SL stands for - it is not used in

SB> That should be SFL

> s9: Expand GAL on first use.

SB> Done

> s9.1: Expand FEC on first use.

SB> Done
> s9.1, para 2: Where is the concept of well-defined array of SFLs defined?

SB> I have added the following text:

              Multiple SFLs can be assigned to a FEC each
	      with different actions. This index is an optional
	      convenience for use in mapping between the TLV
	      and the associated data structures in the LSRs.

> of TBD'...  Er, there doesn't seem to be a reference for TBD.

SB> Fixed

> issue? (apart from the 'the this'.)

SB> Text removed - it was old text

> s13: I am not sure I can identify the relevant issue in s5.
SB> It should have pointed to the privacy section - fixed.

> s14.2: s/request/requested/
SB> Done

> delete two lines - the ones before and after the request.

SB> I have changed it to para. It is a markdown device to include something referenced in a figure. 
> 
> 
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 24 Feb 2021 11:22:31 -0500

Elwyn, thanks for your review. Stewart, thanks for your response. I entered a No Objection ballot as it seems the major issues have been corrected or clarified. However, Elwyn, it would be good if you can reply to Stewart with any remaining comments.

Thanks,
Alissa

> On Feb 10, 2021, at 11:26 AM, Stewart Bryant <[email-masked]> wrote:
> 
> 
> 
>> On 2 Feb 2021, at 15:27, Elwyn Davies via Datatracker <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Reviewer: Elwyn Davies
>> Review result: Not Ready
>> 
>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>.
>> 
>> [email-masked] <mailto:[email-masked]>
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: elwynd <[email-masked]>
Date: Wed, 24 Feb 2021 19:53:29 +0000

Hi, Stewart and Alissa,It think the changes addess my comments pretty well.  The only remaining suggestion I have would be to avoid the use of delay in s7.1.  If I understand correctly, all measurements are of (inter-packet) gaps.  I think you could use gap instead of delay which woul avoid any confusion.Thanks for the rssponses.Cherers,ElwynSent from my Galaxy
-------- Original message --------From: Alissa Cooper <[email-masked]> Date: 24/02/2021  16:23  (GMT+00:00) To: Stewart Bryant <[email-masked]>, Elwyn Davies <[email-masked]> Cc: [email-masked], General Area Review Team <[email-masked]>, [email-masked], Last Call <[email-masked]> Subject: Re: [Gen-art] [mpls] Genart last call review of draft-ietf-mpls-rfc6374-sfl-08 Elwyn, thanks for your review. Stewart, thanks for your response. I entered a No Objection ballot as it seems the major issues have been corrected or clarified. However, Elwyn, it would be good if you can reply to Stewart with any remaining comments.Thanks,AlissaOn Feb 10, 2021, at 11:26 AM, Stewart Bryant <[email-masked]> wrote:On 2 Feb 2021, at 15:27, Elwyn Davies via Datatracker <[email-masked]> wrote:Reviewer: Elwyn DaviesReview result: Not ReadyI am the assigned Gen-ART reviewer for this draft. The General AreaReview Team (Gen-ART) reviews all IETF documents being processedby the IESG for the IETF Chair.  Please treat these comments justlike any other last call comments.For more information, please see the FAQ at<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.Document: draft-ietf-mpls-rfc6374-sfl-??Reviewer: Elwyn DaviesReview Date: 2021-02-02IETF LC End Date: 2021-01-26IESG Telechat date: Not scheduled for a telechatSummary:  Not Ready.  Apologies that this review is rather late, but I found this document extremely hard to work with.  There appear to be a number of areas where the work is rather too much in progress rather than ready for publication as an RFC.  That was some old text from an early version that was missed.I also found it very difficult, not just as someone who is not at all familiar with thisarea of work, but at a basic technical level to work out what the protocol was going to be able to achieve and whether a LSR would garner the information it appeared to need to deliver what was clamed.  This is a document where you need to understand MPLS, coloured marking and  packet delay characteristics, but I think anyone seeking to deploy this would already be familiar with that.Part of this appeared to be due to multiple names being used for the same thing and being used with other than their natural meaning particulaly in sections 7.1 and 7,2. Major Issues:s7, What is being standardized?:    A number of methods are described.  The expectation is that the MPLS    WG possibly with the assistance of the IPPM WG will select one or    maybe more than one of these methods for standardization.I find this statement very confusing.  This document is intended forstandards track, so if it goes ahead as is, the three methods arestandardised and implementors would be expected to provide support forall of them unless there are to be words to indicate that not all needto be supported.   Is this the intention? Or is it that this documentshould only support the methods chosen by the MPLS working group?  Inthe latter case, this document is definitely not ready forstandardization; I assume the unused method(s) would be removed in thiscase.  Otherwise the second sentence is speculative and should be removed.I have changed this text in response to other comments received:It now says A number of methods are described. Each of these methods has differentcharacteristics and different processing demands on the packet forwader.The choice of method will depend on the type of diagnostic that the operator seeks. s7, Title, purpose and general method:Note that I have very limited knowledge of this area of performancemeasurement so there may be misunderstandings here. However, given thatcaveat, I did not find the document very helpful in enlightening me anda considerable amount of background reading was needed to try anddetermine what was going on.It is always difficult to get the balance right between a concise document for subject matter experts and a detailed description.Firstly, I assume that this section covers the 'additional techniques'mentioned in the Abstract That term does not seem to be in the abstract. and described as 'more sophisticatedmeasurements' in s1. [Perhaps common phraseology would be desirablebetween the two cases.]  I suggest a sentence to make this clear wouldbe desirable.I am afraid I cannot see the conflict that you are concerned about.Secondly, AFAICS these techniques are basically about measuring andcommunicating  delay jitter in various ways.  SB> No, Method 1 is measuring jitter. Method 2 is measuring delay as is Method 3It might be helpful tolink what is being offered here with RFC 5481 and the discussion ofdelay variation measurement in RFC 6374.  SB> I think we need to assume that the reader is familiar with RFC6374Section 7.1 is, as Iunderstand it, covering IPDV measurement using (in general) normalservice packets rather than just specialised RFC 6374 packets andworking primarily on one LSR.  I assume that the technique in s7.2 isprimarily a means for reporting measurements derived from s7.1 and/ors7.4, but given that actual delays are mentioned rather thaninter-packet gaps, theSB> All measurements take place on user service data using SFL to SB> indicate different groups of packets. We are using RFC6374 toSB> trigger measurements and collective results.s7.1: After the first sentence, the first paragraph talks about delay. Since the receiving LSR has no knowledge of the transmission time ofeach individual packet, it is not possible for the LSR to calculateactual delays without additional information - I take it that thepackets are not intended to be RFC 6374 Delay Measurement Packets asthese would require corresponding responses which would contravene thequery interval setting  and there does not appear to be a way for theLSR doing the measurements to be told the inter-packet transmissioninterval.  Should this be written in terms of inter-packet gaps ratherthan delays throughout?  SB> 7.1 is measuring the inter packet gaps so as you say is measuringThe variation in the delay rather than the absolute delay. However thisIs made clear in the text.Further, The first paragraph describes twomethods of operation without saying which one should be standardised orAFAICS providing a selection flag to allow either to be used.SB> We could do that but there is a need for the operator to configure SB> other characteristics of the measurement, for example the size of the SB> time increments that the buckets represent, so this would just be anotherSB> such characteristic. The math in the analytics engine to convert oneSB> method into the other is trivial (the difference in the techniques isSB> about collection hardware optimisation) so I don’t think we need toSB> pick one,It seems to me that an outline of how this facility might be used ispretty much essential.  Would I be right in thinking that to measure thedelay jitter between a source LSR (S) and destination LSR (D), theoperator decides to send a set of packets at equally spaced intervalsfrom S to D and decides on the interval and the number of packets.  Sthen issues a Query setting the query interval to a time greater thanthat needed to send the  set of packets and using the Bucket JitterMeasurement Message to set the bucket delay intervals around thesending  interval according to the Operator's expectations of thenetwork.  D then sets up to measure the inter-packet delays up until thenext Bucket Jitter Measurement message arrives after the elapse of thequery interval when D returns  the profile of inter-packet delays.Does the arrival of this second Bucket Jitter Measurement Messagetrigger a further set of measurements?  And if so, how is the sequenceended?SB> No, you send packets in one color then you change color and thenSB> send an Query message and the response refers to the set of packetsSB> before the colour changed.SB> The hardware continuously makes the measurement and the SB> measurement system collects the results when it wants a test result.s9.1: This section is headed by an Editor's Note saying that the sectionneeds review which may alter the format of the TLV.  It is thusimpossible to say if this section is ready.SB> That is a note I had forgotten to removeMinor Issues:s7.2: As with s7.1, there seems to be some confusion bettween delay andinter-packet gap.Nits/editorial comments:Abstract:  The primary purpose of this document, as set out in s1, is toextend RFC 6374 to cover general MPLS networks rather than primarilyMPLS-TP networks and in particular to add support formulti-point-to-point LSPs.  I think that it would be helpful for thecasual reader to make this somewhat clearer in the abstract.  I suggest:OLD:   This document describes a method of making RFC6374 performance   measurements on flows carried over an MPLS Label Switched path.  This   allows loss and delay measurements to be made on multi-point to point   LSPs and allows the measurement of flows within an MPLS construct   using RFC6374.NEW:   RFC 6374 describes methods of making loss and delay measurements on   Label Switched Paths (LSPs) primarily as used in MPLS TransportProfile (MPLS-TP)   networks.  This document describes a method of making RFC6374 performance   measurements on flows carried over general  MPLS LSPs.  In particular, it extends   the technique to  allow loss and delay measurements to be made on multi-point to point   LSPs and introduces some additional techniques to allow more sophisticated   measurements to be made in both MPLS-TP and general MPLS networks.ENDSSB> Thank you that is a good proposals1, bullet 4:  Would it be helpful to refer to RFC  7190 with respect toaggregation?SB> Yes, I will add the ref.s1, bullet 5: s/counter again/counter, again/SB> Fixeds3, last sentence: s/co-responding/corresponding/ [co-responding meansresponding together rather than matching.  Look up co-respondent incases of adultery in the divorce courts!]SB> Thanks. Co-responding seems like a good term to get into a protocol description.s3, last sentence: s/packet/packets/SB> Fixeds4, para 1: Expand TC: s/TC/Trafic Class (TC)/SB> Fixeds5, para 1: s/proxy data service packets Section 4./proxy data servicepackets (see Section 4)./SB> fixeds5, para 2: s/This it is/Thus it is/SB> Fixeds5, para 2: s/are relatively independent/are made relatively independent/SB> Text fixeds5, para 3: s/arises for the potential/arises from the potential/SB> Fixeds5, para after Figure 1: s/were/where/SB> Fixeds5, next to last para: s/which ever/whichever/SB> Fixed s6, para 1: s/measurement type/measurement types/;s/combination/combinations/SB> Fixeds7: I assume these are the additional facilities mentioned in theIntroduction.  It would be helpful to make this clear.SB> Text addeds7.1, para after Figure 2:  The acrronyms QTF, RTF, RPTF and DS shouldbe expanded.  There is no section 3.7 in RFC 6374.  These items aredefined in Section 3.2.SB> Sorry Typo - thanks - fixed.s7.1: The formats of the various numerical fields are not specified.  Iassume they are unsigned integers.SB> Yes, note addeds7.1, Number of Buckets:  I assume that an LSR is likely to have a limitfor this value.  If the query requests an unsupported amount shouldthere be a specific error code?         0x1A: Error - Resource Unavailable.  Indicates that the
         operation failed because node resources were not available.SB> Would be the normal error messages7.3: s/In other that exception/In other than exceptional/SB> Fixeds7.4: The formats for the time fields in the and the Sum of Timestampsfield are not specified.SB> The subject of the various timestamp formats is discussed in RFC6374.s8, first sentence: I am unable to parse 'a delay measurement intervaldefined by an SL of constant colour' before being introduced to RFC8321.   Even then I don't know what SL stands for - it is not used inRFC 8321 or RFC 6374.SB> That should be SFLs9: Expand GAL on first use.SB> Dones9.1: Expand FEC on first use.SB> Dones9.1, para 2: Where is the concept of well-defined array of SFLs defined?SB> I have added the following text:              Multiple SFLs can be assigned to a FEC each	      with different actions. This index is an optional	      convenience for use in mapping between the TLV	      and the associated data structures in the LSRs.s9.1, Specification of FEC field: 'This is encoded as per Section 3.4.1of TBD'...  Er, there doesn't seem to be a reference for TBD.SB> Fixeds10: 'A future version of the *this document*...'  Is this a sign ofunfinishedness or an indication that further documents will address thisissue? (apart from the 'the this'.)SB> Text removed - it was old texts13: I am not sure I can identify the relevant issue in s5.SB> It should have pointed to the privacy section - fixed.s14.2: s/request/requested/SB> Dones14.2, RFC Editor note:  I presume the RFC Editor should be asked todelete two lines - the ones before and after the request.SB> I have changed it to para. It is a markdown device to include something referenced in a figure. _______________________________________________mpls mailing [email-masked]://www.ietf.org/mailman/listinfo/mpls_______________________________________________Gen-art mailing [email-masked]://www.ietf.org/mailman/listinfo/gen-art