Subject: [mpls] Return Path Specified

From: t.petch <[email-masked]>
Date: Mon, 1 Dec 2014 15:18:06 +0000

Mach

Some of the language in RFC7110 looks a little quirky.

s.4.3.1
"the recommended type value is 26"
looks like 'recommended' should have been elided post-IANA

s.4
"The Reply Path TLV contains one or more nested sub-TLVs that can be
used"

s.4.2 Reply Path (RP) TLV
"It is variable in length and can  contain zero, one or more Target FEC
sub-TLVs"

seem to be in conflict

s5.4
"When an echo reply is received, if the Reply Mode is "Reply via
   Specified Path" and the Reply Path return code is "The echo reply was
   sent successfully using the specified Reply Path", and if the return
   path is an MPLS LSP. "

I am left expecting a comma and a main clause (unless the remainder of
the paragraph is the main clause).

"When an echo reply is received with return code set to "Malformed
   echo request received" and the Subcode set to zero.  "

Ditto

And, since I am at it:-)

s.6
OLD
"whether the return path LSP has the destination to the initiator."
NEW
"whether the return path LSP has a destination of the initiator."

OLD
"That means, when sending echo request, the initiator
   should choose a proper source address according the specified return
   path LSP to help the receiver to make the decision."
NEW
"That means, when sending an echo request, the initiator
   should select a source address that helps the receiver to
   find a return path." [I think!]

Sorry that this is a year late:-(

Tom Petch

---

From: Mach Chen <[email-masked]>
Date: Tue, 2 Dec 2014 09:29:50 +0000

Hi Tom,

Thanks for your detail reading of the RFC.

> -----Original Message-----
> From: t.petch [mailto:[email-masked]]
> Sent: Monday, December 01, 2014 11:18 PM
> To: Mach Chen
> Cc: [email-masked]
> Subject: Return Path Specified
> 
> Mach
> 

Yes, indeed. 

> 
> s.4
> "The Reply Path TLV contains one or more nested sub-TLVs that can be used"
> 
> "It is variable in length and can  contain zero, one or more Target FEC sub-TLVs"
> 
> seem to be in conflict

The later is the intention and reflects final consensus, but failed to make the former align with this consensus. 

> I am left expecting a comma and a main clause (unless the remainder of the
> paragraph is the main clause).

Yes, there was a main clause, it was considered redundant and removed directly in a version but forgot to change the last period to a comma.  

>    echo request received" and the Subcode set to zero.  "

Same as above.

>    find a return path." [I think!]

I am OK with the above refinement. 

> Sorry that this is a year late:-(

Indeed. But maybe you could report corresponding erratum, that will be useful. 

I realize that above bugs will be reduced if there was language QA review at that time. 

Thanks,
Mach

---

From: t.petch <[email-masked]>
Date: Fri, 5 Dec 2014 11:58:18 +0000

Mach

Yes, that is clearer now.

I think that an Editorial Erratum would be in order, details below.  Do
you agree?

Section 4.3.1 says

"  the recommended type value is 26."

It should say

"  the type value is 26."

Section 4 says

It should say

"The Reply Path TLV contains zero or more nested sub-TLVs that can be
used"

Section 5.4 says

"When an echo reply is received, if the Reply Mode is "Reply via
   Specified Path" and the Reply Path return code is "The echo reply was
   sent successfully using the specified Reply Path", and if the return
   path is an MPLS LSP.  The ingress LSR MUST perform FEC validation"

It should say

"When an echo reply is received, if the Reply Mode is "Reply via
   Specified Path" and the Reply Path return code is "The echo reply was
   sent successfully using the specified Reply Path", and if the return
   path is an MPLS LSP, the ingress LSR MUST perform FEC validation"

Section 5.4 says

"When an echo reply is received with return code set to "Malformed
   echo request received" and the Subcode set to zero.  It is possible
   that the egress LSR may not know the "Reply via Specified Path" Reply
   Mode, the operator may choose to re-perform another LSP ping by using
   one of the four Reply Modes defined [RFC4379]."

It should say

"When an echo reply is received with return code set to "Malformed
   echo request received" and the Subcode set to zero, it is possible
   that the egress LSR may not know the "Reply via Specified Path" Reply
   Mode; the operator may choose to re-perform another LSP ping by using
   one of the four Reply Modes defined in [RFC4379]."

Notes:

The WG commended a value of 26 to IANA for the "IPv4 RSVP Tunnel sub-TLV
Type" which IANA confirmed. Leaving in the 'recommended' introduces a
element of uncertainty that is best avoided.

As section 4.2 correctly states, the Reply Path TLV can contain zero
sub-TLVs;
this brings section 4 inline.

In section 5.4, the conditional clauses and the main clause have been
separated
by periods, not commas, which creates uncertainty as to whether or not
text of the main clause has been elided.

</Notes>

The last two I raised do not seem worthy of an erratum.

Tom Petch

----- Original Message -----
From: "Mach Chen" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, December 02, 2014 9:29 AM

Hi Tom,

Yes, indeed.

used"
> "It is variable in length and can  contain zero, one or more Target
FEC sub-TLVs"

The later is the intention and reflects final consensus, but failed to
make the former align with this consensus.

> I am left expecting a comma and a main clause (unless the remainder of
the
> paragraph is the main clause).

Yes, there was a main clause, it was considered redundant and removed
directly in a version but forgot to change the last period to a comma.

Same as above.

> Sorry that this is a year late:-(

Indeed. But maybe you could report corresponding erratum, that will be
useful.

I realize that above bugs will be reduced if there was language QA
review at that time.

Thanks,
Mach

---

From: Mach Chen <[email-masked]>
Date: Mon, 8 Dec 2014 01:07:07 +0000

Hi Tom,

Yes, I agree with the proposal.

Thanks,
Mach

> From: mpls [mailto:[email-masked]] On Behalf Of t.petch
> Sent: Friday, December 05, 2014 7:58 PM
> To: Mach Chen
> Cc: mpls
> Subject: Re: [mpls] Return Path Specified
> 
> Mach
> 
> I think that an Editorial Erratum would be in order, details below.  Do you agree?
> 
> Section 4.3.1 says
> 
> "The Reply Path TLV contains zero or more nested sub-TLVs that can be used"
> 
> Section 5.4 says
> 
> As section 4.2 correctly states, the Reply Path TLV can contain zero sub-TLVs; this
> brings section 4 inline.
> 
> In section 5.4, the conditional clauses and the main clause have been separated
> by periods, not commas, which creates uncertainty as to whether or not text of
> the main clause has been elided.
> 
> </Notes>
> 
> Yes, there was a main clause, it was considered redundant and removed directly
> in a version but forgot to change the last period to a comma.
> 
> >
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: t.petch <[email-masked]>
Date: Tue, 9 Dec 2014 17:40:48 +0000

Mach

eeeeee .... I thought I knew how to submit an Erratum (memo to self -
read the I-D before it becomes an RFC).

I have submitted them but it became three separate Errata - I could not
find a way to stitch them together.

Tom

----- Original Message -----
From: "Mach Chen" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "mpls" <[email-masked]>
Sent: Monday, December 08, 2014 1:07 AM

Hi Tom,

Thanks,
Mach

used"
used"
> As section 4.2 correctly states, the Reply Path TLV can contain zero
sub-TLVs; this
separated
> by periods, not commas, which creates uncertainty as to whether or not
text of
> The later is the intention and reflects final consensus, but failed to
make the
> former align with this consensus.
>
> >
> > s5.4
directly
useful.
> I realize that above bugs will be reduced if there was language QA
review at that
> time.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 9 Dec 2014 19:34:03 -0000

Hi Tom,

Thanks for the work.
I just approved the three errata reports.

Actually, it is much nicer to have them as separate reports because it is
clearer what I am verifying and the notes are easier to read.

They should appear on the link from the datatracker page for the RFC once the
scripts have had a chance to turn.

Cheers,
Adrian

> Sent: 09 December 2014 17:41
> To: Mach Chen
> Cc: mpls

---

From: Mach Chen <[email-masked]>
Date: Wed, 10 Dec 2014 05:54:50 +0000

Thanks Adrian and Tom,

Yes, another way to see the Errata is to visit the htmlized version of the RFC, the link is on the right of header.

Best regards,
Mach

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Wednesday, December 10, 2014 3:34 AM
> To: 't.petch'; Mach Chen
> Cc: 'mpls'
> Subject: RE: [mpls] Return Path Specified
> 
> Hi Tom,
> 
> Thanks for the work.
> Actually, it is much nicer to have them as separate reports because it is clearer
> what I am verifying and the notes are easier to read.
> 
> > I have submitted them but it became three separate Errata - I could
> > not find a way to stitch them together.
> >
> > Tom
> >
> > > Type" which IANA confirmed. Leaving in the 'recommended' introduces
> > > a element of uncertainty that is best avoided.
> > >
> > > > "It is variable in length and can  contain zero, one or more
> > > > Target
> > > FEC sub-TLVs"
> > > >
> > > > seem to be in conflict
> > >
> > > >    Specified Path" and the Reply Path return code is "The echo
> > > > reply
> > > was
> > > > I am left expecting a comma and a main clause (unless the
> > > > remainder
> > of
> > > the