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

[Curtis Villamizar <[e-mail]>]

Carlos,

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.

In message <[e-mail]>
"Carlos Pignataro (cpignata)" writes:
 
> Hi Curtis,
>  
> Many thanks for these! Ack to all.
>  
> Reading through your proposed changes, please find one small request =
> inline:
>  
> On Jan 26, 2014, at 11:58 PM, Curtis Villamizar <[e-mail]> =
> wrote:
>  
> >=20
> > In message <005601cf1ac0$bc2ea410$348bec30$@olddog.co.uk>
> > "Adrian Farrel" writes:
> >>=20

[... big snip ...]

> >> ---
> >>
> >> Section 2.1
> >>
> >>   Tunneling encapsulations which may carry MPLS, such as MPLS in GRE,
> >>   L2TP, or LDP, are out of scope.
> >>
> >> I think s/LDP/UDP/
> >
> > Yes.  Thanks.
>  
> Could this be reworded as follows?
>  
> 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.

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.

In this case I listed a few examples so that the phrase "Tunneling
encapsulations carrying MPLS" was a bit more clear.

The references section is already quite large.

> And then for consistency below:
>  
> 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 =
> L2TPv3).
>        The use of tunneling header information is out of scope for this =
> document.

Same reasoning.  If we declare something out of scope we shouldn't
then describe it further and provide citations.

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.

> Thanks!
>  
> Carlos.

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.

One place were we don't do similar citations but maybe we should is:

   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.

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.

Curtis


[... big snip ...]