Re: [mpls] AD review of draft-ietf-mpls-forwarding

[Curtis Villamizar <[e-mail]>]

Carlos,

I gave this some thought and perhaps we should add citations.  I got
your change below.  I also took another look at the normative vs
informational references and promoted quite a few to normative.  The
bad news is we now have a dependency on a draft.

See inline ... but

I am going to summarize in my reply to Adrian so that we can maintain
one thread on this with Adrian's full set of comments.

So please reply on that thread if you need to.

Curtis


In message <[e-mail]>
"Carlos Pignataro (cpignata)" writes:
> 
> Hi Curtis,
>  
> On Jan 27, 2014, at 10:47 AM, Curtis Villamizar <[e-mail]> =
> wrote:
>  
> >=20
> > Carlos,
> >=20
> > Since your apple mailer setting scrambled the plain text version a
> > bit, I'm going to just snip out the relevent parts and reply inline.
>  
> Thanks :-)
>  
> >=20
> > In message <[e-mail]>
> > "Carlos Pignataro (cpignata)" writes:
> >=20
> >> Hi Curtis,
> >>=20
> >> Many thanks for these! Ack to all.
> >>=20
> >> Reading through your proposed changes, please find one small request =
> =3D
> >> inline:
> >>=20
> >> On Jan 26, 2014, at 11:58 PM, Curtis Villamizar =
> <[e-mail]> =3D
> >> wrote:
> >>=20
> >>> =3D20
> >>> In message <005601cf1ac0$bc2ea410$348bec30$@olddog.co.uk>
> >>> "Adrian Farrel" writes:
> >>>> =3D20
> >=20
> > [... big snip ...]
> >=20
> >>>> ---
> >>>>=20
> >>>> Section 2.1
> >>>>=20
> >>>>  Tunneling encapsulations which may carry MPLS, such as MPLS in =
> GRE,
> >>>>  L2TP, or LDP, are out of scope.
> >>>>=20
> >>>> I think s/LDP/UDP/
> >>>=20
> >>> Yes.  Thanks.
> >>=20
> >> Could this be reworded as follows?
> >>=20
> >> NEW:
> >>   Tunneling encapsulations carrying MPLS, such as MPLS in IP [RFC =
> 4023],
> >>   MPLS in GRE [RFC 4023], MPLS in L2TPv3 [RFC 4817], or MPLS in UDP
> >>   [draft-ietf-mpls-in-udp], are out of scope.
> >=20
> > I don't cite documents that define things that are declared out of
> > scope.  For example, I don't cite documents defining the various
> > flavors of PW AC that are declared out of scope.
> >=20
> > In this case I listed a few examples so that the phrase "Tunneling
> > encapsulations carrying MPLS" was a bit more clear.
> >=20
>  
> OK. Please note that there are a couple of (very small) changes besides =
> the citations:
> * Tunneling encapsulations which may carry MPLS -> Tunneling =
> encapsulations carrying MPLS
> * such as MPLS in GRE, L2TP, or LDP -> such as MPLS in IP, MPLS in GRE, =
> MPLS in L2TPv3, or MPLS in UDP

Got it.  With citations.

> > The references section is already quite large.
>  
> The document is not short :-)
>  
> Looking at it right now, the "Normative References" section is actually =
> not large for this document.
>  
> The "Informative References" is large, but I do not see that as an =
> issue. As you know, informative references only provide additional =
> contextual non-normative information. Only readers that are interested =
> in a specific tangent will go there. I see that adding these informative =
> references has no draw-back, but can help readers that would like to =
> understand more about "Tunneling encapsulations carrying MPLS". I;d =
> really add them.
>  
> That said, if you believe that the document gets worst (e.g., too large =
> and distractive) by adding these, or that it is inconsistent with other =
> references, it's OK.
>  
> >=20
> >> And then for consistency below:
> >>=20
> >> OLD:
> >>   7.  Some IP encapsulations support tunneling, such as IP-in-IP, =
> GRE,
> >>       L2TPv3, and IPSEC.  These provide a greater source of entropy
> >>       which some provider networks carrying large amounts of tunneled
> >>       traffic may need.  The use of tunneling header information is =
> out
> >>       of scope for this document.
> >> NEW:
> >>   7.  Some IP encapsulations support tunneling, such as IP-in-IP, =
> GRE,
> >>       L2TPv3, and IPSEC.  These provide a greater source of entropy
> >>       which some provider networks carrying large amounts of tunneled
> >>       traffic may need (e.g., as used in [RFC 5640] for GRE and =3D
> >> L2TPv3).
> >>       The use of tunneling header information is out of scope for =
> this =3D
> >> document.
> >=20
> > Same reasoning.  If we declare something out of scope we shouldn't
> > then describe it further and provide citations.
> >=20
>  
> It definitely is out of scope for the document. But if a reader's scope =
> is interested, it would help to be informational about it.
>  
> As per above, either way is fine. Thanks for considering it.

OK,  With citation as requested.

> > At one point Andy floated the idea of a PWE3 forwarding draft in the
> > relevant WG.  If you want to do a GRE forwarding draft, have at it,
> > but it might be in another WG with MPLS being only one of the things
> > that GRE can carry that might need entropy.
> >=20
>  
> Ack.
>  
> >> Thanks!
> >>=20
> >> Carlos.
> >=20
> > Good suggestions if we hadn't declared these things out of scope.  We
> > do have to limit the scope to avoid turning this into a complete "how
> > to build a router" document and I've tried to avoid scope creep into
> > realms outside of MPLS.
> >=20
> > One place were we don't do similar citations but maybe we should is:
> >=20
> >   Support for other protocols that share a common Layer-4 header such
> >   as RTP, UDP-lite, SCTP and DCCP SHOULD be provided, particularly
> >   for edge or access equipment where additional entropy may be
> >   needed.  Equipment SHOULD also use RTP, UDP-lite, SCTP and DCCP
> >   headers when creating an entropy label.
> >=20
> > I didn't add citations to each of these protocols to avoid further
> > reference section bloat and because they are well known and easy to
> > find in the rfc-index file.  This is creeping to the edge of the
> > defined document scope, but the WG raging discussion of UDP checksums
> > indicates that we really need the SHOULD for at least UDP-Lite and
> > probably for the others as well.
> >=20
>  
> :-)

Might as well add citations to RTP, UDP-lite, SCTP and DCCP.

> To me, the line is drawn at areas that directly touch MPLS. For example, =
> the UDP one is a good one to add, as we saw that discussion. Similarly, =
> encapsulating MPLS in other tunnels is of interest to folks, even if out =
> of scope for the doc (and hence, not Normative, as opposed to not =
> "Citable/Referenceable").
>  
> Thanks,
>  
> -- Carlos.
>  
> > Curtis
> >=20
> >=20
> > [... big snip ...]