Subject: [mpls] Resolving wrinkles in the P2MP TE MIB

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 18 Dec 2008 09:55:47 -0000

Hi,

Although this I-D is past WG last call, a couple of interesting wrinkles 
have been raised by Nic Neate and Subodh Kumar.

I plan to pick these off one at a time and fire emails to the list in case 
anyone wants to object.

Probably, by the time we are done, we will need a further WG last call, but 
the chairs will judge.

Cheers,
Adrian

===

Issue 1
How to find the entries in the mplsXCTable corresponding to the 
cross-connects for a P2MP LSP.

According to RFC3813, the mplsXCTable has three indexes:
      mplsXCIndex                  MplsIndexType,
      mplsXCInSegmentIndex         MplsIndexType,
      mplsXCOutSegmentIndex        MplsIndexType,

In the P2MP TE MIB we currently have the ruling that all values of 
mplsXCIndex for the same LSP MUST be the same.

However, the only way to navigate from the LSP to the XC is using 
mplsTunnelXCPointer in the entry in mplsTunnelTable. Since this is a 
RowPointer, it is not clear that it will always point to the first XC entry 
for the LSP. That makes walking the MIB a bit of a mess.

I propose to fix this as follows:
- mplsTunnelXCPointer is not used for p2mp LSPs and,
  if present, MUST return 0.0
- Restate that entries in mplsXCTable for the same P2MP LSP
   MUST have the same value of mplsXCIndex
- Add a new object to mplsTeP2mpTunnelTable called
   mplsTeP2mpTunnelP2mpXcIndex. The value of this object
   gives the value of mplsXCIndex for all cross-connect entries
   for this LSP

Thus one can walk the XC entries for a particular P2MP LSP by doing 
GetOrGetNext (followed by GetNext) for the index values:
   mplsXCIndex            = the value of mplsTeP2mpTunnelP2mpXcIndex
   mplsXCInSegmentIndex   = 0x0
   mplsXCOutSegmentIndex  = 0x0

Does this work for everyone?

Thanks,
Adrian 

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

---

From: Nic Neate <[email-masked]>
Date: Fri, 19 Dec 2008 09:30:52 +0000

Looks like a good idea to me.

One minor point: I think this change means that at a fast reroute merge point you lose information about which in segment is protected and which are merging backups.  (It's still possible to work out which out segments are protected using the mplsTeP2mpTunnelDestBranchOutSegment.)

I wondered if that could be remedied by also adding an mplsTeP2mpTunnelInSegmentIndex, but that would be tricky to define at re-merge nodes (which although undesirable, can exist).  Extensions to the LSR MIB might be a better way to detail protected and backup in segments, out segments and XCs.

Nic

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Aria - Adrian Farrel Personal
Sent: 18 December 2008 09:56
To: [email-masked]
Cc: Ross Callon
Subject: [mpls] Resolving wrinkles in the P2MP TE MIB

Hi,

Although this I-D is past WG last call, a couple of interesting wrinkles have been raised by Nic Neate and Subodh Kumar.

I plan to pick these off one at a time and fire emails to the list in case anyone wants to object.

Probably, by the time we are done, we will need a further WG last call, but the chairs will judge.

Cheers,
Adrian

===

Issue 1
How to find the entries in the mplsXCTable corresponding to the cross-connects for a P2MP LSP.

In the P2MP TE MIB we currently have the ruling that all values of mplsXCIndex for the same LSP MUST be the same.

However, the only way to navigate from the LSP to the XC is using mplsTunnelXCPointer in the entry in mplsTunnelTable. Since this is a RowPointer, it is not clear that it will always point to the first XC entry for the LSP. That makes walking the MIB a bit of a mess.

Thus one can walk the XC entries for a particular P2MP LSP by doing GetOrGetNext (followed by GetNext) for the index values:
   mplsXCIndex            = the value of mplsTeP2mpTunnelP2mpXcIndex
   mplsXCInSegmentIndex   = 0x0
   mplsXCOutSegmentIndex  = 0x0

Thanks,
Adrian

---

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

Hi Nic,

I'm not familiar with the FRR MIB module, and AFAIK nothing has been done to 
extend that module for P2MP FRR, but shouldn't the information you're 
looking for come from there?

For FRR, isn't the "bypass tunnel" a different LSP? I think that means it 
will point to a new mplsXCTable index to cover its own XCs (which may share 
segments with the XCs for the protected LSP).

The hardware doesn't care about whether it is branching or merging for one 
reason or another, so the mplsXCTable should simply contain XC information 
and no indication of why the XCs exist.

OTOH, the mplsTunnelTable (and hence the mplsTeP2mpTunnelTable) has one 
entry for each instance (i.e., LSP-ID) of the tunnel. This covers mb4b (with 
the exception of group-ID-based changes that you raised before and I plan to 
address next).

Cheers,
Adrian

(May your festive season be everything you ever wanted it to be)

----- Original Message ----- 
From: "Nic Neate" <[email-masked]>
To: "Aria - Adrian Farrel Personal" <[email-masked]>; 
"[email-masked]" <[email-masked]>
Cc: "Ross Callon" <[email-masked]>
Sent: Friday, December 19, 2008 9:30 AM
Subject: RE: [mpls] Resolving wrinkles in the P2MP TE MIB

One minor point: I think this change means that at a fast reroute merge 
point you lose information about which in segment is protected and which are 
merging backups.  (It's still possible to work out which out segments are 
protected using the mplsTeP2mpTunnelDestBranchOutSegment.)

I wondered if that could be remedied by also adding an 
mplsTeP2mpTunnelInSegmentIndex, but that would be tricky to define at 
re-merge nodes (which although undesirable, can exist).  Extensions to the 
LSR MIB might be a better way to detail protected and backup in segments, 
out segments and XCs.

Nic

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Aria - Adrian Farrel Personal
Sent: 18 December 2008 09:56
To: [email-masked]
Cc: Ross Callon
Subject: [mpls] Resolving wrinkles in the P2MP TE MIB

Hi,

Cheers,
Adrian

===

Issue 1

Thanks,
Adrian

---

From: Nic Neate <[email-masked]>
Date: Fri, 19 Dec 2008 11:19:36 +0000

Hi Adrian,

Lets not worry about this for now.  However FRR XCs are modelled, I don't think it's a good enough reason not to make your proposed change to the P2MP MIB.

(FWIW, I agree with you on bypass tunnels.  I was thinking of detour LSPs for one-to-one backup, and also XCs at facility PLRs and merge points for data being tunneled into and out of bypass LSPs.  IMO, they need to share the mplsXCIndex of the protected LSP.)

My best wishes for your Christmas period also.  May all your hopes and dreams come true,

Nic

-----Original Message-----
From: Aria - Adrian Farrel Personal 
Sent: 19 December 2008 10:45
To: Nic Neate; [email-masked]
Subject: Re: [mpls] Resolving wrinkles in the P2MP TE MIB

Hi Nic,

I'm not familiar with the FRR MIB module, and AFAIK nothing has been done to extend that module for P2MP FRR, but shouldn't the information you're looking for come from there?

For FRR, isn't the "bypass tunnel" a different LSP? I think that means it will point to a new mplsXCTable index to cover its own XCs (which may share segments with the XCs for the protected LSP).

The hardware doesn't care about whether it is branching or merging for one reason or another, so the mplsXCTable should simply contain XC information and no indication of why the XCs exist.

OTOH, the mplsTunnelTable (and hence the mplsTeP2mpTunnelTable) has one entry for each instance (i.e., LSP-ID) of the tunnel. This covers mb4b (with the exception of group-ID-based changes that you raised before and I plan to address next).

Cheers,
Adrian

----- Original Message -----
From: "Nic Neate" <[email-masked]>
To: "Aria - Adrian Farrel Personal" <[email-masked]>; "[email-masked]" <[email-masked]>
Cc: "Ross Callon" <[email-masked]>
Sent: Friday, December 19, 2008 9:30 AM
Subject: RE: [mpls] Resolving wrinkles in the P2MP TE MIB

Nic

-----Original Message-----

Hi,

Cheers,
Adrian

===

Issue 1

Thanks,
Adrian

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 19 Dec 2008 07:49:57 -0500

> One minor point: I think this change means that at a fast reroute  
> merge point you lose information about which in segment is protected  
> and which are merging backups.  (It's still possible to work out  
> which out segments are protected using the  
> mplsTeP2mpTunnelDestBranchOutSegment.)
>
> mplsTeP2mpTunnelInSegmentIndex, but that would be tricky to define  
> at re-merge nodes (which although undesirable, can exist).   
> Extensions to the LSR MIB might be a better way to detail protected  
> and backup in segments, out segments and XCs.

	Why do you think the FRR MIB doens't reveal the LSP that is used for  
the bypass? That MIB points at the segment(s) being used for the  
bypass, regardless of how they are set up (p2mp or p2p).

	--Tom

> Although this I-D is past WG last call, a couple of interesting  
> wrinkles have been raised by Nic Neate and Subodh Kumar.
>
> RowPointer, it is not clear that it will always point to the first  
> XC entry for the LSP. That makes walking the MIB a bit of a mess.
>