Re: [mpls] AD review of draft-ietf-mpls-extended-admin-group

[Eric Osborne <[e-mail]>]

HI Adrian-

  I'm ccing Les as well; he had some comments around section 2.3.1 (as
did everyone else, and rightly so).
Inline with EO#.  Since the thread is rather large and it's easy to
lose the changes, I have attached the candidate-05 draft to this
email.   It can be compared to draft-04, which is the latest posted
version.

Summary: most of the changes are no big deal, but I'm wrestling with
how to exclude PCE cleanly.

On Tue, Apr 1, 2014 at 5:39 PM, Adrian Farrel <[e-mail]> wrote:
> Hello,
>
> I have done my usual AD review of your document upon receiving the
> publication request. The purpose is to catch any issues that might
> otherwise show up during IETF last call or IESG review and to get the
> document into good shape so that those later reviews have a clearer
> run.
>
> There are a few comments below that I would like you to look at. The
> I-D is very short and simple, so there is not much to comment on, but
> I have a few concerns, clarifications, and editorial points that I
> hope you will look at. You are, of course, welcome to dispute any of
> these points and discuss them with me on the WG mailing list.
>
> While you are working on this I will put the document into "Revised
> I-D Needed" state and I will ask the WG chairs to send a notice about
> this I-D to the OSPF, ISIS, and CCAMP mailing lists so that they are
> aware of the draft and can comment immediately or during IETF last call
> if they have any concerns.
>
> Thanks for the work,
> Adrian
>
> ===
>
> This document adds a sub-TLV. I think it is your intention that this is
> a sub-TLV of the Link TLV and not of the Administrative Group sub-TLV,
> itself. That seems pretty important, so it needs to be stated clearly.
>

EO#  Fixed.

Old:
---

2.  Extended Administrative Groups sub-TLV

   The Extended Administrative Groups sub-TLV is used...
---


New:
----
2.  Extended Administrative Groups sub-TLV

   This document defines a sub-TLV of the Link TLV for both OSPF
   [RFC3630] and ISIS [RFC5305] called the Extended Administrative
   Groups (EAG) sub-TLV.  The EAG sub-TLV is used...
----

OK?

> ---
>
> The use case in para 2 of Section 1 is, of course, predicated on using
> a single IGP domain (area/level) to cover the whole network that is
> being discussed.  That is OK, but the text should note this caveat lest
> people think that admin colours are somehow globally unique.
>

EO#   I agree that the use case you cite is probably a single-level
case.  But that doesn't mean EAG must be constrained to only a single
level.  An implementation that signals AG in RSVP can use it across
multiple areas (that's really the point of signaling AG at all).  I
don't want to preclude that happening with EAG should someone decide
to implement signaling of EAG in RSVP.

To address your comment I have added a sentence to section 3.  In its entirety:

--- OLD ----
3.  Signaling Extended Administrative Groups in RSVP

   RSVP provides the ability to signal link affinity via the
   SESSION_ATTRIBUTE object with C-Type 1 in RFC 3209 [RFC3209].
   Signaling EAG in RSVP is not addressed in this document.  This
   document does not preclude addressing this in the future should it be
   deemed necessary
----

---- NEW ----
3.  Signaling Extended Administrative Groups in RSVP

   RSVP provides the ability to signal link affinity via the
   SESSION_ATTRIBUTE object with C-Type 1 in RFC 3209 [RFC3209].
   Signaling EAG in RSVP is not addressed in this document.  This
   document does not preclude addressing this in the future should it be
   deemed necessary.

   Note that signaling EAG is RSVP is likely to be necessary to expand
   the use of EAG outside a single area/level, just as it is with AG
---

but please see my comments later in this mail about PCEP.

> ---
>
> Section 2.1
>
>   The EAG may
>    be of any length, but MUST be a multiple of 4 bytes.
>
> Is a zero-length TLV allowed?
>

EO#  I'm not sure what it would actually *do*.  Making clear that a
TLV must actually contain some information in order to be useful is
probably more necessary than I'd like to think.  I live in a country
where we have to say "this plastic bag is not a toy, do not give to
infants" just in case someone thought otherwise...it is for those
people that I propose the following text:

--- OLD ---

The EAG may
   be of any length, but MUST be a multiple of 4 bytes.
----


--- NEW ----

The EAG may be of any non-zero length, but MUST be a multiple of 4 bytes
-----

OK?



> ---
>
> 2.3.1
>

EO#  This section is rather confusing...multiple reviewers caught it.
The current text in its entirety is:

---- OLD ----
2.3.1.  AG and EAG coexistence

   If a node advertises EAG it MAY also advertise AG.

   If a node advertises both AG and EAG then the first 32 bits of the
   EAG MUST be identical to the advertised AG.  If a receiving node
   notices that the AG differs from the first 32 bits of the EAG, it
   SHOULD use the AG as the first 32 bits of the EAG, and SHOULD
   indicate this mismatch to the operator.

   If the AG and EAG advertised for a link differ, the EAG MUST take
   priority.  This allows nodes which do not support EAG to obtain some
   link color information from the network, but also allow for an
   eventual migration away from AG.
----

and it was worded that way after a discussion on the list with Andy
Malis and Tarek Saad.
The intent is straightforward: in the event of a mismatch, prefer AG.

>    If a receiving node
>    notices that the AG differs from the first 32 bits of the EAG, it
>    SHOULD use the AG as the first 32 bits of the EAG, and SHOULD
>    indicate this mismatch to the operator.
>
>    If the AG and EAG advertised for a link differ, the EAG MUST take
>    priority.
>
> Aren't these two statements contradictory?
> I suspect the final "EAG" is supposed to read "AG" to be consistent
> with the first paragraph and also to match the first motivation given
> immediately after.

EO#  Sort of.  There are a few options here in the event of a mismatch:

1) use only AG
2) overwrite the first 32 bits of EAG with AG, then use the entire EAG.
3) use only EAG


In the discussion with Andy and Tarek we came to agreement on #2.
That's what the text in section 2.3.1 needs to say.

I therefore propose the following for the entirety of section 2.3.1:

---- NEW ----

   If a node advertises EAG it MAY also advertise AG.

  If a node advertises both AG and EAG then the first 32 bits of the
   EAG MUST be identical to the advertised AG.  If a receiving node
   notices that the AG differs from the first 32 bits of the EAG, it
   SHOULD use the AG as the first 32 bits of the EAG, and SHOULD
   indicate this mismatch to the operator.  This allows nodes which do
not support EAG to obtain some
   link color information from the network, but also allow for an
   eventual migration away from AG.
---

all this does is drop the sentence "If the AG and EAG advertised for a
link differ, the EAG MUST take
   priority." as that clearly contradicted everything else in that section.


>
>    This allows nodes which do not support EAG to obtain some
>    link color information from the network, but also allow for an
>    eventual migration away from AG.
>
> OTOH...
>
> 1. The second motivation seems to support EAG taking priority.
>
> 2. The first motivation seems to miss some really big issues concerning
>    non-support of EAG. You need to discuss this processing in relation
>    to signaling...
>
>    Suppose a link is advertised with EAG and a node that does not
>    support EAG signals an LSP?

EO#  I don't think this applies, since there is no support for
signaled EAG.  It's purely for headend calculation.

>
>    Suppose one end of a link supports EAG but the other does not and
>    a signaling message includes EAG and the upstream end of the link
>    ignores it?
>

EO#  The same is true of one end signaling AG and the other not
signaling anything; despite its widespread advertisement, AG is
optional.

I never thought there was any requirement for a TE link to have
identical properties in both directions.  Neither rfc3630 nor rfc5305
concern themselves with bidirectionality in any of the TE TLVs, nor
does rfc5307.  The implementations I'm familiar with perform a basic
two-way connectivity check, but that's it.

I would prefer to stay away from prescribing behavior here that is
more restrictive than what's specified in the base documents.

>    I think you have some edge conditions to describe in section 2.3
>

EO#  No such conditions are discussed in any other RFC which specifies
TE link properties, and we seem to have gotten along just fine.  If
you feel strongly about this then we can sort something out, but I'm
reluctant to make the EAG document the place where all sorts of
assumptions about CSPF get spelled out.

> ---
>
> I read section 4.7.4 of RFC 3209 to compare it with what you say in
> section 2.3.2 of this document.
>
> I read it to say:
> - a link can only be excluded if it advertises a specific color
> - a link can only be included if it advertises a specific color
> Thus, failure to include AG means a link cannot be excluded according
> to an exclusion requirement. But it also means that it cannot be
> included according to an include or include-any requirement.


EO#  Right.  It's a hole in 3209; that section assumes AG is always
advertised.  In my experience this is generally true in practice, and
the implementations I know best have some default they assume if AG is
not advertised.

....

> I think this is functionally equivalent to RFC 3209.
> That is, a link cannot be excluded on the basis of an unadvertised
> affinity because it is assumed to be 0.
> And a link cannot be included on the basis of an unadvertised affinity
> because it is assumed to be 0.
>
> So it all ends up right in the end, but it took a lot of words!

EO#  Yeah...I wanted to make clear what 4.7.4 meant without adding
some backdoor requirements to it.

>
> ---
>
> In Section 2.3.2 you have an "interesting" mix of advice and 2119 words.
>

....

Yes.
Yes I did.

I think s/MUST/SHOULD/ for the first MUST in 2.3.2, as well as some
tweaking, fixes it.  I propose:


---  OLD----

  Each implementation is free to choose its own method for handling
   this question.  However, to allow for maximum interoperability an
   implementation MUST treat desired but unadvertised EAG bits as if
   they are set to 0.  Consider the case where a node wants to only use
   links where the 127th bit of an EAG is set to 1.  If a link is only
   advertising 64 EAG bits, clearly the 127th EAG bit is not defined -
   that is, it is neither explicitly 0 nor 1.  The node which wants the
   127th EAG bit to be 1 MUST NOT use this link, as the assumption is
   than an unadvertised bit is set to 0.
----


--- NEW ---

  Each implementation is free to choose its own method for handling
   this question.  However, to allow for maximum interoperability an
   implementation SHOULD treat desired but unadvertised EAG bits as if
   they are set to 0.  Consider the case where a node wants to only use
   links where the 127th bit of an EAG is set to 1.  If a link is only
   advertising 64 EAG bits, clearly the 127th EAG bit is not defined -
   that is, it is neither explicitly 0 nor 1.  The node which wants the
   127th EAG bit to be 1 MUST NOT use this link when implementing the
recommended behavior, as the assumption is
   than an unadvertised bit is set to 0.
---


...

> But, one final question...
> Why do you want to allow other modes of operation?
> What is the benefit, and why didn't you call it out?


EO#  As with other uses of SHOULD (e.g., section 2.3.1) there is
already at least one implementation out there and while it hews in
large part to the document as written, I did not want to inadvertently
deprecate it.

>
> ---
>
> Section 3 deliberately sidesteps the use of EAG in signaling. That is
> "interesting"

EO#  You may recall from (Berlin?  Orlando?) that I had a much longer
section which wrestled with this.  I took it out and swept the whole
thing under the rug under direct advice of an AD at the mic. :)

> and makes me assume that the use of EAG you have in mind
> applies only at the point of explicit path selection (i.e. no loose
> hop selection).
>

EO#  Yes, that's the problem I'm trying to solve.  I don't see much
relevant to PCE (if the PCE is going to hand down an explicit path
then why does it need to include any AG/EAG information at all?) and
while I don't want to completely rule it out it seems like more than
needs to be solved in this document.


> I think that, in order to justify this work being limited to the IGPs
> you need to be a bit more explicit, up front, that *your* use case
> concerns pre-computation of paths.

EO#  well, no...not pre-computation.  Headend computation.
Pre-computation (at least the way I understand it) means
offline+config push or something PCE-ish like that.

>
> Now, there are two places where path selection will be done:
> 1. The head-end LSR
> 2. A PCE
>
> So, you should pick one or both of these as your use case and state it
> clearly. If you include PCE, you will need to look at the applicability
> to PCEP (see Section 7.11 of RFC 5440).

EO#  If I'm sidestepping RSVP I might as well sidestep PCEP too.  It
isn't necessary for the use case EAG was developed for, and I'm not
sure I see it being all that big of an issue.

However....rfc5440 section 7.11 provides an LSPA which is a copy of
the SESSION_ATTRIBUTE of C-Type 1 (that is, the one with the three
link attribute tests).  I did not see anything in 5440 which provided
a copy of SESSION_ATTRIBUTE of C-Type 7 (with setup/holding prio but
no attribute tests).

This means that, as far as I can tell, it's not possible to emulate
C-Type 7 in PCEP.  This is really quite far outside the scope of the
EAG document, but sweeping it under the rug gets ugly.

I propose the following:

- retitle section to "Signaling Extended Administrative Groups in RSVP
 and PCEP"
- making the entirety of section 3 into:

----
3.  Signaling Extended Administrative Groups in RSVP and PCEP

   RSVP provides the ability to signal link affinity via the
   SESSION_ATTRIBUTE object with C-Type 1 in RFC 3209 [RFC3209].
   Signaling EAG in RSVP is not addressed in this document.  This
   document does not preclude addressing this in the future should it be
   deemed necessary.Note that signaling EAG is RSVP is likely to be
   necessary to expand the use of EAG outside a single area/level, just
   as it is with AG.

   The PCE Communication Protocol, or PCEP ( [RFC5440]) specifies an
   LSPA object which is essentially a copy of RFC3209's
   SESSION_ATTRIBUTE with C-Type 1.  It does not provide a copy of the
   SESSION_ATTRIBUTE with C-Type 7.  Thus, the only way to indicate
   setup/holding priority in PCEP is to also signal 32-bit AG values for
   Exclude-any, Include-any and Include-all.

   If a node which implements both EAG and PCEP wishes to signal setup
   and holding priorities in PCEP's LSPA, it has no choice but to use
   the LSPA with affinity constraints.  A node which sends an LSPA in
   PCEP MUST populate the affinity constraint fields (Exclude-any,
   Include-any, Include-all) with the lower 32 bits of the relevant EAG.

   This document does not preclude addressing this in the future should
   it be deemed necessary.  One possible approach is to standardize a
   PCEP object which is a mirror of the SESSION_ATTRIBUTE of C-Type 7.
   Another is to standardize a PCEP object which directly contains
   support for EAG.  There may be other approaches.  Any and all such
   approaches are outside the scope of this document

----------

I'm not sure I like it all that much but I can't think of a better
approach that doesn't involve wrestling with the whole signaling
question again.


>
> ---
>
> Section 5 could be made clearer by breaking the text out into separate
> paragraphs or even separate sections. It would also be helpful to IANA
> if you made little tables showing the exact information you want
> recorded in each registry.
>

EO#
I put in some paragraph breaks and cleaned the text up a bit..  If
those aren't clear enough it's easy enough to work with IANA when they
get around to allocating the codepoint.



eric