Subject: Re: [mpls] Small bug fix in the P2MP MIB

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 19 Dec 2008 19:40:13 -0000

Hi Nic,

Way back in August you raised an important issue with the MPLS-TE P2MP MIB.

Sorry to have taken so long to get around to working on this.

> I'd like to fix what I believe to be a bug in the P2MP MIB.  While
> it has passed WG last call, I don't think it has yet completed AD
> review, so that should provide a window in which to make this
> change if people agree with it.

Yup.
We pulled the I-D back from the AD to have another look at it.
As it turns out, Subodh also found an issue and we have been able to fix 
that at the same time.

You wrote...

> The mplsTeP2mpTunnelTable contains three fields for reporting the
> upstream sub-group IDs received on Path messages for a P2MP LSP.
> -  mplsTeP2mpTunnelSubGroupOriginType
> -  mplsTeP2mpTunnelSubGroupOrigin
> -  mplsTeP2mpTunnelSubGroupID
>
> However, an LSR may receive multiple Path messages for a single P2MP
> LSP, each for a different sub-group.  See RFC 4875 section 4.3.  I would
> like to be able to report all of the upstream sub-groups for a P2MP LSP
> in the MIB, not just one of them.

Yes, you're right.

I know that the authors debated making these three objects indexes to the 
table. This would have meant that was effectively one entry for each 
sub-group received - that is, for each path message received for the LSP.

However, we traded this off for the sparse augments relationship that allows 
us to tell whether an LSP is a P2P or P2MP LSP.

> A single S2L sub-LSP will always be in a single Path message
> and sub-group (except during transient re-optimization conditions).

I'm not sure this is true.
In the process of moving a destination from one sub-group to another, won't 
it appear in both sub-groups?

> I think the upstream sub-group fields should therefore be moved
> to the mplsTeP2mpTunnelDestTable, so that the upstream sub-
> group for each S2L sub-LSP can be reported.

This is an option, but it seems to mean that we would end up repeating 
rather a lot of data. Perhaps we can do that because the presence of the 
data in the MIB objects does not imply any duplication in storage at the 
agent - just duplication on the wire and in the NMS.

> The mplsTeP2mpTunnelDestTable already contains fields for the
> downstream sub-group IDs, so the moved fields would also have
> to be renamed as follows.
> -  mplsTeP2mpTunnelDestUpSubGroupOriginType
> -  mplsTeP2mpTunnelDestUpSubGroupOrigin
> -  mplsTeP2mpTunnelDestUpSubGroupID

I heard no-one disagree with this on the list.

I have been playing with some other options to make a larger change to the 
tables to more closely model the relationships between data objects and to 
avoid duplicating data, but this would really be a large change. The smaller 
change proposed by Nic seems less disruptive.

So I propose to pick up Nic's ideas and roll them into a new revision (he 
was kind enough to send me some revised text).

I'll post a new version shortly including changes for Subodh and Nic, and 
I'll also do a diff so that folk can see what has changed.

Then we will ask the WG chairs if they want to do another WG last call.

Thanks,
Adrian

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 19 Dec 2008 21:54:10 -0000

Hi again Nic,

Thinking further about this issue (when I came to write the ASN.1)...

Your proposal is to move the source sub-group information from the 
mplsTeP2mptable to the mplsTeP2mpTunnelDestTable as follows...

<ascii-art>

mplsTunnelTable
  | Index    {tunnel-index,
  |           tunnel-inst,
  |           ingress,
  |           P2MP-ID (=egress)}
  v
  mplsTeP2mpTunnelTable
    | Index    {tunnel-index,
    |           tunnel-inst,
    |           ingress,
    |           P2MP-ID (=egress)}
    |
    |-->
    |--> mplsTeP2mpTunnelDestTable
             Index    {tunnel-index,
                       tunnel-inst,
                       ingress,
                       P2MP-ID (=egress),
                       dest-subgroup-source,
                       dest-subgroup-ID,
                       destination}
             Contains {source-subgroup-source,
                       source-subgroup-ID}

</ascii-art>

The problem with this is that one destination may be in two received 
sub-groups during transition from one sub-group to another. This is not 
captured in your proposal because a destination can only be in two 
source-subgroups if it is also in two destination sub-groups.

We can fix this one of two ways.

1. source-subgroup-source and source-subgroup-ID become
   indexes to mplsTeP2mpTunnelDestTable. This is not so
   hard, but it is unclear how we would walk the MIB.
   For example, if we put dest-subgroup-source and
   dest-subgroup-ID first then it is easy to walk to find
   all of the destinations to go on one outgoing Path, but
   it is hard to walk to find all of the destinations
   received on one incoming Path. And vice versa.

2. Add a new table to reflect the existence of the
   incoming (i.e., upstream) sub-group.

<ascii-art>

   mplsTunnelTable
     | Index    {tunnel-index,
     |           tunnel-inst,
     |           ingress,
     |           P2MP-ID (=egress)}
     v
     mplsTeP2mpTunnelTable
       | Index    {tunnel-index,
       |           tunnel-inst,
       |           ingress,
       |           P2MP-ID (=egress)}
       |
       |-->
       |--> mplsTeP2mpIncomingSubgroupTable  (New)
              | Index    {tunnel-index,
              |           tunnel-inst,
              |           ingress,
              |           P2MP-ID (=egress),
              |           source-subgroup-source,
              |           source-subgroup-ID}
              |
              |-->
              |--> mplsTeP2mpTunnelDestTable
                       Index    {tunnel-index,
                                 tunnel-inst,
                                 ingress,
                                 P2MP-ID (=egress),
                                 dest-subgroup-source,
                                 dest-subgroup-ID,
                                 destination}
                       Contents unchanged from current I-D

</ascii-art>

Opinions?

Thanks,
Adrian

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: "Nic Neate" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 19, 2008 7:40 PM
Subject: Re: [mpls] Small bug fix in the P2MP MIB

> However, we traded this off for the sparse augments relationship that 
> allows us to tell whether an LSP is a P2P or P2MP LSP.
>
> In the process of moving a destination from one sub-group to another, 
> won't it appear in both sub-groups?
>
> avoid duplicating data, but this would really be a large change. The 
> smaller change proposed by Nic seems less disruptive.
>

---

From: Nic Neate <[email-masked]>
Date: Mon, 22 Dec 2008 18:21:40 +0000

Hi Adrian,

Thanks for picking this up.

The fix I originally proposed was intended to be a minimal change to allow reasonable function.  I agree it's not sufficient during sub-group-based re-optimization if the upstream sub-groups IDs change but downstream ones do not.  (Although I suspect that most implementations will choose to always change the downstream sub-group IDs whenever the upstream ones change, that's not mandated by the protocol.)

If folks are happy with making a more significant change to the MIB, then I think I favour your first suggestion (making the upstream sub-group IDs indices to the mplsTeP2mpTunnelDestTable).

In your second suggestion, I'm not clear what the relationship between the mplsTeP2mpIncomingSubgroupTable and mplsTeP2mpTunnelDestTable is.  How are multiple rows in the mplsTeP2mpTunnelDestTable with the same indices, but mapping to different mplsTeP2mpIncomingSubgroupTable rows allowed?

Cheers,

Nic

-----Original Message-----
From: Aria - Adrian Farrel Personal 
Sent: 19 December 2008 21:54
To: Nic Neate
Cc: [email-masked]
Subject: Thinking further about: Small bug fix in the P2MP MIB

Hi again Nic,

Your proposal is to move the source sub-group information from the mplsTeP2mptable to the mplsTeP2mpTunnelDestTable as follows...

<ascii-art>

mplsTunnelTable
  | Index    {tunnel-index,
  |           tunnel-inst,
  |           ingress,
  |           P2MP-ID (=egress)}
  v
  mplsTeP2mpTunnelTable
    | Index    {tunnel-index,
    |           tunnel-inst,
    |           ingress,
    |           P2MP-ID (=egress)}
    |
    |-->

</ascii-art>

The problem with this is that one destination may be in two received sub-groups during transition from one sub-group to another. This is not captured in your proposal because a destination can only be in two source-subgroups if it is also in two destination sub-groups.

<ascii-art>

   mplsTunnelTable
     | Index    {tunnel-index,
     |           tunnel-inst,
     |           ingress,
     |           P2MP-ID (=egress)}
     v
     mplsTeP2mpTunnelTable
       | Index    {tunnel-index,
       |           tunnel-inst,
       |           ingress,
       |           P2MP-ID (=egress)}
       |
       |-->

</ascii-art>

Opinions?

Thanks,
Adrian