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

[Eric Osborne <[e-mail]>]

Hi Les-

  Thanks for the review, glad those changes worked for you.
As far as the conflict, we went back and forth and this during initial
development.  There are probably good arguments on both sides, and as
long as a device is compliant none of this should matter.  The reason
we did what we did is that AG is widespread but optional, and if we
define EAG to start at bit 32 we then have to define what you do if a
node advertises EAG and not AG, and another node has desire for bits
in the AG space. It gets just as ugly, if not uglier; we'd have to say
something like "if there is EAG and no AG, assume AG == 0x0", and this
creates two problems:
   1) some implementations have default assumptions in the case of
missing AG, and they may not all be 0x0
   2) it mandates that 'undefined' == 0x0, which makes me feel all weird.

It *is* true that by defining EAG to start at bit 0 rather than bit 32
we can someday replace AG, but that's not the motivation.  The
motivation is simply to not _require_ AG in the face of EAG when AG by
itself is optional.

Tarek, please chime in if I missed anything.



eric



On Wed, Apr 16, 2014 at 11:45 AM, Les Ginsberg (ginsberg)
<[e-mail]> wrote:
> Eric -
>
> The revised text in Section 2.3.1 addresses my concern - thanx.
>
> But I had also asked why the potential conflict between AG and EAG could not be avoided altogether by defining EAG as representing the groups beyond the first 32 defined by AG. Could you respond to that?
>
> If the argument is that you would like someday to deprecate the use of AG I have to say that I don’t find that very compelling.
>
>    Les
>
>
>> -----Original Message-----
>> From: Eric Osborne [mailto:[e-mail]]
>> Sent: Wednesday, April 16, 2014 8:01 AM
>> To: Adrian Farrel
>> Cc: [e-mail]; [e-mail];
>> [e-mail]; Les Ginsberg (ginsberg)
>> Subject: Re: AD review of draft-ietf-mpls-extended-admin-group
>>
>> 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