Subject: [mpls] Comments on draft-ietf-mpls-forwarding-03

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Fri, 22 Nov 2013 16:04:00 +0000

Some overdue comments post-Vancouver:

Overall
=======
The document tries to walk a fine line between "here's things we've learned over time and which will bite you if you ignore them" and "here's how you MUST do things".  The former is great; the latter is a trap.  I think this doc would go over well if it was something like "The Hitchhiker's Guide To Not Getting Your MPLS Implementation Totally Wrong", but 'Forwarding and Performance Requirements' feels like too mcuh of an ITU-style mandatory equipment spec.  Is there any IETF precedent for requirements docs like this?

Also, I note that there's not much in the document talking about how you handle RA packets for MPLS-TE.  I hate to open up Yet Another Can Of Worms, but the ability to deal with RA at a reasonable rate, including some TE scale numbers, would be cool.  This sort of straddles the line between forwarding and control plane, so should at least be hinted at.

Section 1
=========
I appreciate section 1.2, but I'm not sure it'll hold.  As a vendor who's gotten RFPs for April Fools RFCS (yes...really), I doubt any self-indemnifying paragraph will do much.  In absence of that, I have two options:
	i) claim conformance when asked
	ii) ignore the question

(ii) doesn't always work

Section 1.2 says ' RFC 2119 keywords are used where explicitly noted that the
       keywords indicate that operator experiences indicate a
       requirement, but there are no existing RFC requirements.'

and

   'Advice provided by this document may be ignored by implementations.'

I don't get that.  I read it as "MUST means MUST if operators have a requirement and there are no existing requirements".  This seems to be a huge backdoor to set any requirements you want.

Section 1.3, I think most of what's in there belongs there.  The only thing I don't agree with is the inclusion of ACK-compression.  It's great stuff to talk about, but is it MPLS-specific?  If yes, that's not clear from the text.  If no, what is it doing in an MPLS-specific document?

Point 7 in Sec. 1.3 is one of those huge backdoor things I'm talking about:

" The implementer and system designer SHOULD support adding an MPLS
       entropy label [RFC6790].  Deployments MAY enable this feature.
       See Section 2.4.4."

'SHOULD' in uppercase means "really ought to unless you have a very good reason not to", and uppercase makes it normative.  This is where that line between "really ought to because we know people want it" and "mandatory per spec" gets blurred.  What does it mean to have 'SHOULD' in the face of the exculpatory disclaimer in 1.2?  If the intent is to provide good advice to naive implementors, why not just say 'should' and be done with it?  The doc has lots of places where I think s/SHOULD/should/ is appropriate.

Contrast this with text from section 2.1.3: " hardware should allow a
   timestamp to be placed in an outgoing packet at any specified byte
   position."

Why is the first normative and the second not?  What's the difference for the audience?

Section 2
=========
In line with my previous comment, I don't think Section 2.3 belongs in this documenet.  If you can hit sawtooth in IP-only networks (are there any of those left? :) ) then it's not MPLS-specific.

Section 2.4.5.1 is another one of those non-normative uppercase things.  
" If no ELI is encountered, and the first nibble of payload
       contains a 4 (IPv4) or 6 (IPv6), an implementation SHOULD support
       the ability to interpret the payload as IPv4 or IPv6 and extract
       and use appropriate fields from the IP headers."

Where does this SHOULD come from?  I didn't see anything similar in rfc6790.  Is this a normative requirement imposed on forwarding hardware?  Or is it intended as "here's something you ought to do if you want to ship a useful product".  The latter is good stuff, but I don't see why it warrants normative language.

Sections 3 and 4
================
I understand the intent of sections 3 and 4, but they make me nervous.  "here's a bunch of tests you ought to run" means that if someone fails the test they're held to account, and if the operator doesn't understand the questions they're asking or the impact on their network then you may end up with unnecessary confusion all around.  Could you add something to these sections along the lines of "Here are some common tings that operators may wish to verify with their network equipment.  The impact of a particular question or test on the network operator's architecture needs to be carefully considered, as not all negative answers have a negative impact on the network".  What I'm basically going for here is that the operator needs to understand _why_ they're asking the question and whether that question has any impact on their design.  My fear is that this becomes a pass/fail checklist regardless of impact to any particular network.

Section 4
=========
What's the overlap with rfc5695, particularly section 6?  

eric

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 24 Nov 2013 08:46:27 +0000

Eric,
You've asked (in the "Overall" section of your comment): 
<quote>
	Is there any IETF precedent for requirements docs like this?
<end quote>

IMHO and FWIW RFC 2544 comes pretty close. 

And, as for encountering questions about the April Fools' RFCs in RFPs - well, people could do much worse, IMO, then referring to RFC 1925...

Regards,
     Sasha

> -----Original Message-----
> From: mpls [mailto:[email-masked]] On Behalf Of Eric Osborne
> (eosborne)
> Sent: Friday, November 22, 2013 6:04 PM
> To: [email-masked]; [email-masked]
> Subject: [mpls] Comments on draft-ietf-mpls-forwarding-03
> 
> The document tries to walk a fine line between "here's things we've learned
> over time and which will bite you if you ignore them" and "here's how you
> MUST do things".  The former is great; the latter is a trap.  I think this doc would
> go over well if it was something like "The Hitchhiker's Guide To Not Getting
> Your MPLS Implementation Totally Wrong", but 'Forwarding and Performance
> Requirements' feels like too mcuh of an ITU-style mandatory equipment spec.
> Is there any IETF precedent for requirements docs like this?
> 
> Also, I note that there's not much in the document talking about how you
> handle RA packets for MPLS-TE.  I hate to open up Yet Another Can Of Worms,
> but the ability to deal with RA at a reasonable rate, including some TE scale
> numbers, would be cool.  This sort of straddles the line between forwarding and
> control plane, so should at least be hinted at.
> 
> 
> Section 1
> =========
> I appreciate section 1.2, but I'm not sure it'll hold.  As a vendor who's gotten
> RFPs for April Fools RFCS (yes...really), I doubt any self-indemnifying paragraph
> will do much.  In absence of that, I have two options:
> I don't get that.  I read it as "MUST means MUST if operators have a
> requirement and there are no existing requirements".  This seems to be a huge
> backdoor to set any requirements you want.
> 
> 
> Section 1.3, I think most of what's in there belongs there.  The only thing I don't
> agree with is the inclusion of ACK-compression.  It's great stuff to talk about,
> but is it MPLS-specific?  If yes, that's not clear from the text.  If no, what is it
> doing in an MPLS-specific document?
> 
> 'SHOULD' in uppercase means "really ought to unless you have a very good
> reason not to", and uppercase makes it normative.  This is where that line
> between "really ought to because we know people want it" and "mandatory per
> spec" gets blurred.  What does it mean to have 'SHOULD' in the face of the
> exculpatory disclaimer in 1.2?  If the intent is to provide good advice to naive
> implementors, why not just say 'should' and be done with it?  The doc has lots
> of places where I think s/SHOULD/should/ is appropriate.
> 
> In line with my previous comment, I don't think Section 2.3 belongs in this
> documenet.  If you can hit sawtooth in IP-only networks (are there any of those
> left? :) ) then it's not MPLS-specific.
> 
> Where does this SHOULD come from?  I didn't see anything similar in rfc6790.
> Is this a normative requirement imposed on forwarding hardware?  Or is it
> intended as "here's something you ought to do if you want to ship a useful
> product".  The latter is good stuff, but I don't see why it warrants normative
> language.
> 
> 
> 
> 
> 
> Sections 3 and 4
> ================
> I understand the intent of sections 3 and 4, but they make me nervous.  "here's
> a bunch of tests you ought to run" means that if someone fails the test they're
> held to account, and if the operator doesn't understand the questions they're
> asking or the impact on their network then you may end up with unnecessary
> confusion all around.  Could you add something to these sections along the
> lines of "Here are some common tings that operators may wish to verify with
> their network equipment.  The impact of a particular question or test on the
> network operator's architecture needs to be carefully considered, as not all
> negative answers have a negative impact on the network".  What I'm basically
> going for here is that the operator needs to understand _why_ they're asking
> the question and whether that question has any impact on their design.  My
> fear is that this becomes a pass/fail checklist regardless of impact to any
> particular network.
> 
> 
> 
> Section 4
> =========
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: "Stewart Bryant (stbryant)" <[email-masked]>
Date: Sun, 24 Nov 2013 09:45:29 +0000

Sasha

RFC1812 was a requirements document, but the IETF never maintained it.

Indeed now I remember it, I should take a look and see if it needs to be recommended be made obsolete.

Stewart

Sent from my iPad

> On 24 Nov 2013, at 08:46, "Alexander Vainshtein" <[email-masked]> wrote:
> 
> Eric,

---

From: Loa Andersson <[email-masked]>
Date: Mon, 25 Nov 2013 09:04:44 +0800

Folks,

trawling the T´RFC sea I alos come up with STD3 and RFC 5505, they are
requirement documents and maintained. Whether they are close enough to
to Eric's question about a precedence for  draft-ietf-mpls-forwarding
is a bit open. But I don't see that it really matters.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64