Subject: [Mpls-interop] new slide

From: Loa Andersson <[email-masked]>
Date: Tue, 08 Apr 2008 19:51:36 +0200

All,

this is the replacment slide for slide 49 in slide deck version 11
I came up with after the discussion at the meeting today.

/Loa
-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]
_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: "KOMPELLA Vach" <[email-masked]>
Date: Tue, 8 Apr 2008 12:55:46 -0500

I agree, although, at C' there is a typo - it should be j-1.

-Vach  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: Tuesday, April 08, 2008 10:52 AM
> To: [email-masked]
> Subject: [Mpls-interop] new slide
> 
> 
> All,
> 
> this is the replacment slide for slide 49 in slide deck 
> version 11 I came up with after the discussion at the meeting today.
> 
> /Loa
> --
> Loa Andersson
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 8 Apr 2008 20:18:07 +0100

Well, personally I hate the "going into the pipe" terminology. I don't see 
any going into pipe being performed at node B, but you still show the stack.

Why can't we just show the label stack as carried on the wire between nodes?

I also think we would benefit from showing C/C' as a hybrid of interfaces 
and nodes. It is a single node in this figure.

That would lead to the attached...

Adrian
----- Original Message ----- 
From: "Loa Andersson" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, April 08, 2008 6:51 PM
Subject: [Mpls-interop] new slide

> I came up with after the discussion at the meeting today.

--------------------------------------------------------------------------------

---

From: "KOMPELLA Vach" <[email-masked]>
Date: Tue, 8 Apr 2008 19:12:03 -0500

Adrian,

Well, the difference between what you have and Loa's and mine is
primarily where the label stack is viewed.  It's fine to show what's on
the wire, but showing what's done on the node is also significant.

Having said that, I think C should decrement the TTL, not C', i.e.,
decrement at ingress and decide if the node wants to deal with this
packet or not - then the forwarding and label swapping comes in the next
phase.

Staring at the slide a little more, I realize another change also
occurred.  At some point, the notion of a PW got introduced.  I think
that change is signficant.  My original slide only said "Cascaded TTL
processing."  Finally, even though the slide says "Multi-segment PW",
this is not a Multi-Segment PW.  The TLDP session goes from A-D with no
switch points in the middle.

In my earlier RGBO (red-green-blue-orange label stack) picture of nested
LSPs, I didn't say what the relation of k to m or m to n was.  For
nested LSPs, and PWs nested in LSPs, there should be no relationship.
Likewise, for the cascaded TTL processing, there is no relation between
k and n.

So let's take a "proper" MS-PW case.  Say the TLDP session runs from A-C
and C-D, with C being an S-PE.  Would you decrement the TTL at C?  I
would assume so because the S-PE is a hop in the middle of a larger
entity (the MS-PW).  This is unlike the outer tunnel from A-C and C-D
where the TTLs are not related.

The question is, how do we distinguish the one from the other - i.e.,
back-to-back segments that are unrelated (the tunnel LSPs from A-B-C and
C-D) vs. the back-to-back segments that are related (the PW segments A-C
and C-D)?

-Vach  

> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Tuesday, April 08, 2008 12:18 PM
> To: Loa Andersson; [email-masked]
> Subject: Re: [Mpls-interop] new slide
> 
> Well, personally I hate the "going into the pipe" 
> terminology. I don't see any going into pipe being performed 
> at node B, but you still show the stack.
> 
> I also think we would benefit from showing C/C' as a hybrid 
> of interfaces and nodes. It is a single node in this figure.
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 09 Apr 2008 11:04:50 +0100

> the wire, but showing what's done on the node is also significant.
The problem that Loa and I had was that it was not clear what the TTL 
reference point was and so we did not understand the slides. We edited 
the slides to something that we understood and  then were asking if that 
was what was meant to show.

Now you are right that we also need to understand the processing in the 
nodes, but that needs to be combined with MEP, MIP and forwarding 
descriptions.
> packet or not - then the forwarding and label swapping comes in the next
OK
> switch points in the middle.
So what scenario are we trying to show here?
> Likewise, for the cascaded TTL processing, there is no relation between
Right there is no relationship between the outer TTLs, but I am 
concerned if there is no relationship between the inner TTLs as was 
shown on the original slide, because there is no loop suppression behaviour.
> and C-D, with C being an S-PE.  Would you decrement the TTL at C?
Yes, at the PW level the hardware just does a standard MPLS label swap 
and TTL decrement an check before pushing the tunnel label to get to the 
next xPE.
>   I
I agree.
> C-D) vs. the back-to-back segments that are related (the PW segments A-C
What is the real meaning / use of the first construct?

If you are joining two opaque LSPs (including PW/MPLS), the you are 
still doing an ordinary MPLS swap at the lowest common level.

Otherwise you are joining two real physical interfaces.

Are there any other cases we need to consider?

Stewart

---

From: David Ward <[email-masked]>
Date: Wed, 9 Apr 2008 11:24:03 -0500

Note that adding too many more scenarios may be over the top for an  
option 1 or 2 recommendation but, I'd like to think that the slideset  
removes vs adds confusion. Vach, et al can you split the scenarios as  
Stewart mentions? It would correct what we have documented and remove  
confusion.

To answer Stewart's last question with a question: Are there more  
scenarios we need to outline to make the option 1 or 2 recommendation  
or do we have any existing documented scenarios that are incorrect,  
overloaded or otherwise needing a split like the case we have found  
here? I don't think so and would like to believe that we could create  
a slide of additional use cases/scenarios that could be diagrammed  
during the design phase as they aren't necessary for an option 1 or 2  
recommendation. Thoughts?

Thanks

-DWard

---

From: "KOMPELLA Vach" <[email-masked]>
Date: Thu, 10 Apr 2008 17:32:44 -0500

I think there are two general cases of label stacks (and I'll limit this
to two labels for now).  In these cases, the bottom of stack label's TTL
needs to be decremented whenever it gets exposed, as Loa fixed my slide:

a) tunnel-in-tunnel: e.g., LDP over RSVP, where LDP is used to stitch
RSVP LSPs
b) PW-in-tunnel: the PWE architecture

These need to be differentiated from the two label case where a packet
finds it matches a FEC at some ingress node, and gets dropped into a
tunnel-in-tunnel (or PW).  When it reaches node C, the two tunnel labels
are popped, and some "completely unrelated" process decides to put the
packet in another tunnel-in-tunnel (or PW).  In this case, I'm not sure
how to handle the TTL.  I think the right thing is that the TTL be
re-generated.  In the uniform model for IP packets, you would have
pushed the TTL from the IP header into the MPLS label, and popped it
back into the IP header at the stitch point C, and pushed it from the IP
header onto the new label stack at C', and popped it back into the IP
header at D, thereby mitigating loops.

I'd say we are not addressing this second case architecturally - i.e.,
use the architecture and tie the segments together and you won't have
loops.

-Vach  

> [mailto:[email-masked]] On Behalf Of Stewart Bryant
> Sent: Wednesday, April 09, 2008 3:05 AM
> To: KOMPELLA Vach
> Cc: [email-masked]
> > primarily where the label stack is viewed.  It's fine to 
> show what's 
> > on the wire, but showing what's done on the node is also 
> significant.
> >   
> The problem that Loa and I had was that it was not clear what 
> the TTL reference point was and so we did not understand the 
> slides. We edited the slides to something that we understood 
> and  then were asking if that was what was meant to show.
> 
> Now you are right that we also need to understand the 
> processing in the nodes, but that needs to be combined with 
> MEP, MIP and forwarding descriptions.
> > packet or not - then the forwarding and label swapping comes in the 
> > next phase.
> >   
> OK
> > this is not a Multi-Segment PW.  The TLDP session goes from 
> A-D with 
> > no switch points in the middle.
> >   
> > In my earlier RGBO (red-green-blue-orange label stack) picture of 
> > nested LSPs, I didn't say what the relation of k to m or m 
> to n was.  
> > For nested LSPs, and PWs nested in LSPs, there should be no 
> relationship.
> > Likewise, for the cascaded TTL processing, there is no relation 
> > between k and n.
> >   
> Right there is no relationship between the outer TTLs, but I 
> am concerned if there is no relationship between the inner 
> TTLs as was shown on the original slide, because there is no 
> loop suppression behaviour.
> > So let's take a "proper" MS-PW case.  Say the TLDP session 
> runs from 
> > A-C and C-D, with C being an S-PE.  Would you decrement the 
> TTL at C?
> Yes, at the PW level the hardware just does a standard MPLS 
> label swap and TTL decrement an check before pushing the 
> tunnel label to get to the next xPE.
> >   I
> > back-to-back segments that are unrelated (the tunnel LSPs 
> from A-B-C 
> > and
> > C-D) vs. the back-to-back segments that are related (the PW 
> segments 
> > A-C and C-D)?
> >   
> If you are joining two opaque LSPs (including PW/MPLS), the 
> you are still doing an ordinary MPLS swap at the lowest common level.
>