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

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 1 Apr 2014 22:39:16 +0100

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.

---

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.

---

Section 2.1

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

Is a zero-length TLV allowed?

---

2.3.1

   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.

   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?

   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?

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

---

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.

Now, that is not how I read what you have said in 2.3.2. Here I see
you saying that if a node does not advertise AG the path selection 
cannot decide whether an affinity is set of not. I believe that is
subtly different from what 3209 says - I think that says that if an
AG is not present then the inclusion test must fail as if the 
affinity was not set.

Of course, you are right that a default advertisement of 0x0 is a
good way around this, and you are correct that this becomes confusing
with variable length EAGs. But it is important to note that a default
advertisement of 0x0 is still an explicit advertisement of no affinities
being set, and the default is being applied at the advertising node not
at the receiver of the advertisement. 

You go on to say...                   

   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.

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!

---

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

   Each implementation is free to choose its own method for handling
   this question.  

"Free to choose" is preparing me to not see any use of "MUST"
   
   However, to allow for maximum interoperability an
   implementation MUST treat desired but unadvertised EAG bits as if
   they are set to 0.  

Oh, so my implementation is not free to choose!   
   
   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.

   A node MAY provide other strategies for handling this case. 

Hello! I am now allowed to do something different from the "MUST"
   
   A
   strategy which deviates from the recommended behavior in this

Although this is a lower case "recommended" I associate that word with
"SHOULD" not the actual "MUST" that you used.

   document SHOULD be configurable, in order to provide maximum
   interoperability.

If it is only "SHOULD be configurable" then you allow "not configurable"
in which case you have a procedure that deviates from the "MUST" and is
not configurable.

Hmmmm.

I think you wanted to say:
- All implementations MUST support a mode of operation that assumes 
  absent affinities are set to 0
- Implementations MAY support other modes of operation
- Implementations that support other modes of operation MUST have allow
  configuration to select the mode of operation, and MUST default to 
  assume that absent affinities are 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?

---

Section 3 deliberately sidesteps the use of EAG in signaling. That is
"interesting" 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).

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.

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).

---

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.

---

From: Eric Osborne <[email-masked]>
Date: Wed, 16 Apr 2014 11:01:13 -0400

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.

> 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?

> 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.

> 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
----

--- NEW ----

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

OK?

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.

> with the first paragraph and also to match the first motivation given

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.

>    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.

>    a signaling message includes EAG and the upstream end of the link

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.

> 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.

....

> 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----

----

--- 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.
---

...

> 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.

> "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

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.

> 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.

> 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.

> 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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 16 Apr 2014 15:45:43 +0000

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:[email-masked]]
> Sent: Wednesday, April 16, 2014 8:01 AM
> To: Adrian Farrel
> Cc: [email-masked]; [email-masked];
> [email-masked]; Les Ginsberg (ginsberg)
> Subject: Re: AD review of draft-ietf-mpls-extended-admin-group
> 
> HI Adrian-
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 16 Apr 2014 21:34:37 +0100

Hi Eric,

Comments in line with appropriate snipping.

Update and post when ready.

Thanks,
Adrian

>    the use of EAG outside a single area/level, just as it is with AG

s/is RSVP/in RSVP/

This change helps.

But I think it slightly misses my point that the colors have meaning specific to an administrative domain. It is unclear how one administrative domain knows the meanings of the colors in another domain. And this is worse than an ERO: an ERO can be encoded (perhaps from the CLI) to span multiple domains because the addresses/labels/etc only have meaning at the point they are examined. The color is applied to the whole LSP not embedded in the ERO with the result that the domain boundary may have to translate the colors for use in the next domain.

I would argue that it is not practical for two domains to coordinate their use of colors.

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

Yes. (I'd hate for your code to crash in the field when my code sends it a 0-length EAG :-)

>    priority." as that clearly contradicted everything else in that section.

I feel the need to mutter :-)
Why the first SHOULD?
(And actually, why the need to compare the values?)

I'd suggest

    If a node advertises both AG and EAG then the first 32 bits of the
    EAG MUST be identical to the advertised AG.

    If both an AG and EAG are present, a receiving node MUST use the
    AG as the first 32 bits (0-31) of administrative color and use the EAG
    for bits 32 and higher if present.

    A receiving node that notices that the AG differs from the first 32
    bits of the EAG, SHOULD report this mismatch to the operator.  

    This process 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.

> >    non-support of EAG. You need to discuss this processing in relation

OK, I re-read Section 3. You are punting on signaling.
And in fact Section 3 is completely factually correct, while my review suffered from being written front-to-back as I read the draft.

> the implementations I know best have some default they assume if AG is

Oh, I don't think it is a hole at all!
The text is clear (to me) and works (IMHO) when AG is not advertised.
Recall, 3209 is about signaling not path computation.
We want to avoid: "I want chocolate ice cream." "Here is some ice cream, I have no idea what flavor it is."

However, you are saying that most implementations are saying "If you don't tell me, I will assume all ice cream is raspberry."

But this is a side-track...

> large part to the document as written, I did not want to inadvertently

I appreciate your sensitivity.
But tough! :-)
We are documenting how things should work according to WG consensus, not how we hope things work in the field already.

So I stick with my suggested summary...

|- All implementations MUST support a mode of operation that assumes
|  absent affinities are set to 0
|- Implementations MAY support other modes of operation
|- Implementations that support other modes of operation MUST have allow
|  configuration to select the mode of operation, and MUST default to
|  assume that absent affinities are set to 0

> offline+config push or something PCE-ish like that.

If you lived in a transit node, you would see "pre-computation" as the path was already computed when I received the signaling message.

Looking at all of this, I think the hole I fell into is found under the question "Why is AG present in signaling in RFC 3209?" The answer to that question, I believe, is to allow transit nodes to expand loose hops, and to allow transit nodes to verify that a signaled path conforms to the admin colors requested for the LSP (also applies to local repair).

What you are saying (and it is fine to say it, although it would be better to say it in the I-D :-) is that at the moment, all envisaged usage of EAG is achieved at the headend or in a PCE. That means that there is no perceived use of EAG in signaling just as (you presumably contend) AG is not used in signaling today.

> sure I see it being all that big of an issue.

This is OK. The use case you described in the document did not explain that the intent is headend computation of a full explicit path. Maybe just a few words in the Introduction would clean all this up.

> EAG document, but sweeping it under the rug gets ugly.

Well, look, that text is OK, but it seems unnecessary if your motivation is as you describe. In fact, Section 3 is unnecessary with your motivation. 

So don't go down that path if you don't want to. Just state your objective is to enable headend computation as described above.

---

From: Eric Osborne <[email-masked]>
Date: Thu, 17 Apr 2014 08:54:51 -0400

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

---

From: Eric Osborne <[email-masked]>
Date: Fri, 18 Apr 2014 09:30:12 -0400

Thanks!
Comments inline as well.  I will post later today.

...

> I would argue that it is not practical for two domains to coordinate their use of colors.

EO#
All of this is true.  But it's
  a) just as bad with AG as with EAG; EAG is simply a longer version of AG.
  b) moot.  Since we cannot signal EAG in either RSVP or PCEP, it
cannot cross domains (intra- or inter-AS) in signaling.

If we need to issue a document explaining the hazards of trying to
signal affinity across boundaries, we can do so, and it will apply
equally to AG and EAG.  But that's not what I'm trying to do, and it's
not something I've ever seen causing issues in the wild (YMMV, of
course).

Or I may still be missing the point entirely.

...

...
> I feel the need to mutter :-)

EO#  I have written and rewritten this comment two or three times.
On the one hand, I don't see the need to mandate a headend-only
behavior with a MUST.  It's not like a different interpretation of an
error case will cause an issue for anything other than the headend
which disregards the recommended behavior.

On the other hand, it *is* an error case.  And it makes no sense to
say "you MUST not advertise EAG != AG, but if you find that in the
wild then you MAY ignore the fact that it's an error and do something
special and proprietary with it".

After much back-and-forthing, I think the second point wins.

> (And actually, why the need to compare the values?)

EO#  I said 'If a receiving node notices", not "When a receiving node
notices"...it could be cleaner than that, of course.

>     eventual migration away from AG.

EO#  This is cleaner than the text I had, so I'll use it.

...
> The text is clear (to me) and works (IMHO) when AG is not advertised.

EO#  It's easy to conflate 'advertised' and 'defined'.  We generally
assume that if a node has AG defined that it will advertise it, and if
it's not advertising it it's because it's not defined.  If a node does
not define AG but it receives signaling indicating a desire for a
particular AG, it has to do one of three things:

   1) assume some system-wide, unadvertised, default AG
   2) reject the Path message on the grounds that it's asking for
something which does not exist
   3) ignore the AG bits entirely, as if what was sent was C-Type 7, not 1.

None of these seem particularly pleasant or intuitive.

> We want to avoid: "I want chocolate ice cream." "Here is some ice cream, I have no idea what flavor it is."

EO#  I view C-Type 1 as "I want chocolate ice cream" and an IGP TE LSA
with no AG as "here is my menu of things.  You will kindly notice that
it does not include ice cream of any kind."  A mismatch between
advertised AG and signaled AG is much closer to the "I have ice cream,
but no chocolate / I want chocolate" situation.

> But this is a side-track...

EO#  Yes.  An interesting philosophical discussion in a bar, but not
germane to getting EAG out the door.

...

> Looking at all of this, I think the hole I fell into is found under the question "Why is AG present in signaling in RFC 3209?" The answer to that question, I believe, is to allow transit nodes to e…

EO#  I agree with this answer; that's what I always thought AG was for.

> What you are saying (and it is fine to say it, although it would be better to say it in the I-D :-) is that at the moment, all envisaged usage of EAG is achieved at the headend or in a PCE. That me…

EO#  OK.  I feel compelled to at least point out exactly what this
means, as "there is no signaling" may not mean much to someone who
doesn't already have SESSION_ATTRIBUTE C-Type 1 or LSPA in mind.

I will add this to the Intro:

"   EAG's intended use case is within a single domain.  As such, this
   document provides no support for signaling EAG.  It provides no
   analog to either the SESSION_ATTRIBUTE of C-Type 1 defined in
   RFC3209, nor the LSPA object of the Path Computation Element
   Communication Protocol (PCEP) defined in [RFC5440]
"

and remove Section 3 in its entirety.  I debated also adding "Such
support can be added in a future document", but this seems
unnecessary.

I think this clears it up.  It's Friday as I write this, I'll let it
sit until Monday in case there are any last-minute objections to this
approach, and plan to post it Monday.

thanks!

eric

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 18 Apr 2014 14:06:33 +0000

Eric -

Thanx for the reply and explanation.

At the risk of beating a dead horse, if EAG were simply an addition/extension of AG I don’t see that this requires AG to be advertised when EAG is advertised. Having read Section 2.3.2 I see that this is an issue you are concerned with - you somewhat reluctantly suggest unadvertised bits can be assumed to be 0 - but doesn't this issue get exacerbated with EAG? What I mean by that is that if some routers need to advertise 128 bits you seem to be implying that it would be better if all routers advertised 128 bits even if they have no local links which require bits 33 - 128. But operationally this means that as soon as one router is configured to advertise 128 bits all routers SHOULD be advertised to advertise 128 bits - which seems unnecessarily onerous - as well as bloating the IGP LSDB.

I defer to your expertise - I only dabble in this space from the IGP perspective - so I am fine with whatever you decide - including the current definition - but now you have "all my thoughts" on the subject.

   Les

> Sent: Thursday, April 17, 2014 5:55 AM
> To: Les Ginsberg (ginsberg)
> Cc: Adrian Farrel; [email-masked];
> [email-masked]; [email-masked]
> > 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
> >
> >

---

From: Eric Osborne <[email-masked]>
Date: Mon, 21 Apr 2014 14:18:02 -0400

Hi Les-

  There is no clean way to do any of this.  With any approach we have
to deal with the face that AG and EAG are rather intertwined, yet both
are optional.

You say: "if EAG were simply an addition/extension of AG I don’t see
that this requires AG to be advertised when EAG is advertised." but
what happens if I advertise only EAG (bits 31+) and a node wants bit
17 to be set to 1?  We have to find some way to handle this - either a
recommended default, a mandatory default, or an error condition.

It's just about as ugly whether we go with the additive approach (AG
0-31, EAG 32+) or the superset approach that the draft is taking (AG
0-31, EAG 0-31+).  I can't find a terribly persuasive argument either
way.

I like the one the draft is taking because it means that I have
complete link attribute information in one place - it feels cleaner,
and yes, it allows me to deprecate AG.  'feels clean' is a squishy and
subjective thing at best, and deprecating AG is a side effect rather
than a design goal, but there's no more compelling reason.

eric