Subject: [mpls] working group last call for draft-ietf-mpls-extended-admin-group

From: Loa Andersson <[email-masked]>
Date: Tue, 04 Feb 2014 13:54:13 +0800

Working Group,

This is to initiate a working group last call on
draft-ietf-mpls-extended-admin-group-02.

There are no IPR disclosures against this document. The author has
stated that he is unaware of any IPRs that relate to this document.

Please send your comments to the mpls wg mailing list ([email-masked]).

This working group last call ends Feb 18, 2014.

/Loa
for the MPLS wg chairs
-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 4 Feb 2014 14:39:23 -0500

I was asked by the WG chairs for a WG LC review of this draft. In
general, the draft is ready for publication, but I do have a few
comments.

[Editorial] Section 1: There are several unbracketed RFC references
that are in the actual list of references, and thus should be in
brackets in the text.

[Technical] Section 2.2: The numbering of the EAG's first word of bits
is discussed, but the numbering of the bits in subsequent words is not
described. It can be implied that the bit numbering will continue at
32 with the LSB of the second word of the EAG, but that is not
actually stated.

[Technical] Section 2.3.1: It is easy to predict that routers or
software loads that implement the EAG will be deployed in the same
network as those that only implement the AG. It can be expected that
routers that do not implement the EAG will simply ignore that
particular sub-TLG. Thus, those routers, upon receipt of both the AG
and EAG sub-TLVs, will ignore the EAG and use the AG. Thus, for
improved backwards compatibility, if the AG and EAG co-exist and the
AG is inconsistent with the first word of the EAG, it would seem that
the AG should take precedence. This is the opposite of what is stated
in the draft.

Of course, once all of the routers in a network support the EAG, the
AG will be unnecessary and only the EAG will be used.

[Technical] Section 2.3.2: I'm personally hard-pressed to find
usefulness in the flexibility in this section. For maximum
interoperability and simplicity of implementations, I would prefer
that the third paragraph be modified to say:

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

and also completely remove the following paragraph.

[Technical] Section 3 contains a lot of unattributed hand-waving. I
would prefer that is simply say:

   Signaling EAG in RVSP is not addressed in this document. Addressing
this in the future is not precluded.

[Technical] Section 4: While the existing text is strictly true,
having available a virtually unlimited set of AGs does make it more
important for network administrations that want their traffic
engineering to operate correctly to be careful with their AG
allocation and usage, to avoid unintended side-effects of
unconstrained AG usage or router misconfiguration. What may have been
a relatively easy task with 32 AGs may be more difficult with 128, or
1000, or 1,000,000 attributes. Previously manual processes may need to
be automated to ensure correctness. Feel free to add text to this
effect to this section, or not, as you prefer.

Thanks,
Andy

On Tue, Feb 4, 2014 at 12:54 AM, Loa Andersson <[email-masked]> wrote:
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 6 Feb 2014 14:20:10 +0000

Hi, Loa,

I think that this document is almost ready for publication moving forward. It addresses a focused problem in a direct way.

I only have one technical comment:

Section 2.3.1 addresses "coexistence" giving preference to the EAG over the AG. That is fine, however it does not address "backwards compatibility" in the case in which both are advertised in an IGP, but a node understands only AG and not EAG. In that case, if the first 32 bits differ, then the node that advertises and the node that receives it (and does not understand EAG) have different views of the decision. This should be anomalous and an error condition.

Also some nits regarding citations in the Abstract and a downref Normative that should be noted.

Thanks!

Carlos.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 6 Feb 2014 10:28:52 -0500

Carlos,

Regarding your technical comment, if a receiver only understands the
AG and not the EAG, then it should silently ignore the EAG, and there
is no way for it to detect the case where they are in disagreement.
Thus there is no way to report this as an error condition.

Also see my comment on section 2.3.1 backwards compatibility in my
previous email.

Cheers,
Andy

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 6 Feb 2014 15:44:19 +0000

Hi Andy,

> Thus there is no way to report this as an error condition.

Yes, exactly. My call out was only that two routers will have a separate view of the coloring, and cannot be detected by the router that does not understand EAG. Just something that needs perhaps to he spelled out in the doc.

> Also see my comment on section 2.3.1 backwards compatibility in my

I fully agree with that comment. That would cover it. Thanks!

Carlos.

---

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Thu, 6 Feb 2014 16:35:25 +0000

Hi,

This document looks good, and addresses a real limitation with existing
AGs. I think it is ready for publication. Few comments:
- section 2.3.1: prefer rewording to explicitly spell the behaviour on a
receiving node that supports EAG.. example, "... EAG MUST take priority on
a receiving node that supports it."

minor edit comments:
- section 1, might want to define LSA, MTU before use
- section 2.3.2 equally applicable to AG too; maybe re-title as "Desire
for unadvertised bits for AG/EAG"?
- typo in Section 2.3.2, "... assumption is than" -> "assumption is that"

Regards,

Tarek

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 6 Feb 2014 12:18:16 -0500

Tarek,

In my earlier review, I argued the opposite for section 2.3.1, that AG
MUST take priority over EAG for backwards compatibility. See my email
for my reasoning.

Cheers,
Andy

---

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Thu, 6 Feb 2014 17:49:42 +0000

In case of inconsistency, see 3 options:
1. use AG and discard EAG, i.e. ignore subsequent bits in (EAG)
2. use AG for first word and subsequent bits from EAG bits
3. use EAG and discard AG

The way the draft puts it is EAG is a "superset" of AG.

I'm in favour of 3) when router speaks/understands EAG. Just as it is true
that for routers that speak/understand only AG, they'd use AG.
Note, my understanding is AG at sometime will become obsolete and
eventually most (if not all) routers will be speaking EAG.

Regards,
Tarek

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 6 Feb 2014 13:06:13 -0500

Tarek,

Imagine that you have a network that has been using AG and is
transitioning to EAG. Since not all routers can be updated
simultaneously, there will be a period where some will support both AG
and EAG and others will only support AG. As long as AG and the first
word of EAG are consistent, everything works well. But if a
provisioning or software bug leads to the case where the two are
inconsistent, option (2) will operate better than option (3), since
with option (2), both old and new routers will be using a consistent
set of bits 0-31.

Cheers,
Andy

---

From: Eric Osborne <[email-masked]>
Date: Thu, 6 Feb 2014 14:06:52 -0500

Hi Andy-

  So the concern is around how to handle the case where AG doesn't
match the first 32 bits of EAG.  The current text in 2.3.1 says:

"If a node
   advertises both AG and EAG then the first 32 bits of the EAG MUST be
   identical to the advertised AG.  If the AG and EAG advertised for a
   link differ, the EAG MUST take priority."

I think I can fix this by changing the second sentence to:

"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 MUST indicate this mismatch to
the operator."

I very deliberately used 'SHOULD' because there is at least one
implementation already in production with the current logic and I
don't want to obsolete it to cover a corner case that's already
illegal and clearly a bug.

Does that work?
Tarek, does that break anything in what's shipping?

eric

---

From: Eric Osborne <[email-masked]>
Date: Thu, 6 Feb 2014 14:14:05 -0500

Hi Andy-

  Inline with EO#

> that are in the actual list of references, and thus should be in

EO#  ACK, will fix.

> 32 with the LSB of the second word of the EAG, but that is not

EO#  ACK, will fix.

> AG will be unnecessary and only the EAG will be used.

EO#  I sent a separate email on this.

>    than an unadvertised bit is set to 0.

EO#  That works for me; you're basically doing s/SHOULD/MUST/.
Tarek?  Thoughts?

> this in the future is not precluded.

EO#  Yeah, there's a lot of history there.  I used to get blasted for
not having enough justification for doing certain things in this draft
and now it looks like I'm in trouble for having too much. :)  I don't
much care what that section says - if nobody else cares to take a
position opposite yours then I'll change it.

> effect to this section, or not, as you prefer.

EO#  IMO it doesn't belong.  Reminding operators that they may need to
manage things carefully as they scale seems awfully nanny-state-ish
and not unique to EAG.

thanks!

eric

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 6 Feb 2014 11:24:20 -0800

Was asked by WG chairs to review the document as part of LC.
The document is concise and clear. Would like the comments below addressed prior to publication.
Some/all of the comments might be a repeat of what others might have already raised (I didn’t read any of those). So, bear with me.

 -Please add Terminology section and identify terms there.
- Not all RFC’s referenced are not bracketed. 
- In section 2.3.1, it says, for eventual migration away from AG. Does that mean, at some point a node will stop advertising AG? If so, when and how? i.e. how does a one know the network has fully migrated to EAG, so nodes could stop advertising AG. A little more clarity to section should help.
- When this new sub-TLV is received on a node and it doesn’t understand, what does it do? safely ignore or report its incompatibility?
- Typo "as the assumption is
   than an unadvertised bit is set to 0”
- In sec 3. concludes that this work may happen in future if necessary. Hence, I would like the following sentence to be removed/reworded, "It is thus likely that signaling EAG in a
   SESSION_ATTRIBUTE would see virtually no deployment.”

cheers
-sam

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 6 Feb 2014 14:56:53 -0500

Eric,

I'm fine with your responses, thanks!

Cheers,
Andy

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 6 Feb 2014 14:55:22 -0500

Eric,

Yes, that will work for me.

Thanks,
Andy

---

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Fri, 7 Feb 2014 17:39:53 +0000

Hi Eric,

>Tarek, does that break anything in what's shipping?
[TS]: yes, that would be a change of the current implementation-- which is
as per the current version of the draft.

Regards,
Tarek

>>>>> receiving node that supports EAG.. example, "... EAG MUST take
>>>>>priority
>>>>>on

---

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Fri, 7 Feb 2014 17:43:30 +0000

Inline..

>EO#  That works for me; you're basically doing s/SHOULD/MUST/.
[TS]: yes, this is acceptable. BTW, I'd s/encourage/allow/ if MUST is what
we'll have.

Regards,
Tarek

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 8 Feb 2014 10:54:13 -0500

s/encourage/allow/ looks good to me as well.

Cheers,
Andy

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 8 Feb 2014 10:56:27 -0500

Tarek,

SHOULD will still allow the current implementation (while encouraging
you to update it to the final text).

Cheers,
Andy

---

From: Loa Andersson <[email-masked]>
Date: Wed, 19 Feb 2014 13:29:05 +0100

Working Group,

This working group last call is closed.

There have been comments. Could the author please address the comments
and post a new version as necessary.

/Loa

--