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

From: Eric Osborne <[email-masked]>
Date: Wed, 5 Mar 2014 10:54:44 -0500

One tweak.  I had proposed

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

but having SHOULD/MUST doesn't make sense.  I'm about to post -03 (or
will post when it's allowed again), which instead has SHOULD/SHOULD:

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

All other comments have been accepted as per earlier discussion

eric

On Thu, Feb 6, 2014 at 2:06 PM, Eric Osborne <[email-masked]> wrote:
> 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
>
> On Thu, Feb 6, 2014 at 1:06 PM, Andrew G. Malis <[email-masked]> wrote:
>> 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
>>
>>
>> On Thu, Feb 6, 2014 at 12:49 PM, Tarek Saad (tsaad) <[email-masked]> wrote:
>>> 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
>>>
>>> On 2014-02-06 12:18 PM, "Andrew G. Malis" <[email-masked]> wrote:
>>>
>>>>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
>>>>
>>>>On Thu, Feb 6, 2014 at 11:35 AM, Tarek Saad (tsaad) <[email-masked]>
>>>>wrote:
>>>>> 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
>>>>>
>>>>> On 2014-02-04 12:54 AM, "Loa Andersson" <[email-masked]> wrote:
>>>>>
>>>>>>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
>>>>>>_______________________________________________
>>>>>>mpls mailing list
>>>>>>[email-masked]
>>>>>>https://www.ietf.org/mailman/listinfo/mpls
>>>>>
>>>>> _______________________________________________
>>>>> mpls mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>> _______________________________________________
>> mpls mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Wed, 5 Mar 2014 16:59:51 +0000

Thanks Eric, that sounds good.

Regards,
Tarek