Subject: Next steps for draft-ietf-ccamp-mpls-graceful-shutdown-01.txt....

From: "Zafar Ali \(zali\)" <[email-masked]>
Date: Thu, 1 Mar 2007 18:41:34 -0500

Hi Adrian, Deborah, Dimitri, and campers-  
 
As we mentioned at the last IETF meeting,
http://www3.ietf.org/proceedings/06nov/slides/ccamp-17/sld1.htm, we have
addressed all outstanding comments, except the following comment from
Dimitri, related to this ID. Should you have any further comment, please
share. 
 
The only remaining comment that is not closed is "should this ID be
informational or standard track". IMO the ID defines a new error-subcode
and some specific behavior, and should be standard track. Can you please
comment on this. 
 
The ID has been stable for quite some time and following the closure of
the above, we would like to request last call. 
 
Thanks
 
Regards... Zafar

---

From: [email-masked]
Date: Thu, 8 Mar 2007 01:28:05 +0100

zafar -

o) would it be possible to sum'up changes you have been provided 
since so far ?

o) would it be possible to clarify the following statement

"- Graceful shutdown mechanisms are required to address TE LSPs 
   spanning multiple domains, as well as intra domain TE LSPs. "

afaik you don't shutdown LSPs but Links - right ?

thanks,
-d.

"Zafar Ali \(zali\)" <[email-masked]>
Sent by: [email-masked]
02/03/2007 00:41
 
        To:     "Adrian Farrel" <[email-masked]>, "Brungard, Deborah 
A, ALABS" <[email-masked]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[email-masked]>, "Jean Philippe Vasseur \(jvasseur\)" 
<[email-masked]>, "Anca Zamfir \(ancaz\)" <[email-masked]>
        Subject:        Next steps for 
draft-ietf-ccamp-mpls-graceful-shutdown-01.txt....

 

Thanks
 
Regards... Zafar

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 8 Mar 2007 13:11:42 -0800 (PST)

Dimitri,
   I have a couple questions wrt the draft-dimitri-ccamp-gmpls-ason-routing-ospf draft.
  
In 5.2 a TE Link sub-TLV is introduced for the purpose of advertising local and remote TE Router ID:

  0                   1                   2                   3 

     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

    |              17               |             Length            | 

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

    |                 Local TE Router Identifier                    | 

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

    |                Remote TE Router Identifier                    | 

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Although I do understand why there is a need for advertising the Local TE Router ID, I don’t understand why the Remote Te Router ID? Isn’t this is the same information 
that is carried in the Link ID sub-TLV?

In 6. you write:

“A RA may contain smaller RAs inter-connected by links. 
The limit of the subdivision results in
 a RA that contains two sub-networks interconnected by a single link.”

In G.8080 I read:
  “.... A routing area is defined by a set of subnetworks, the SNPP links that interconnect them, and the SNPPs representing the ends of the SNPP links exiting that routing area. A routing area may contain smaller routing areas interconnected by SNPP links. The limit of subdivision results in a routing area that contains ]one subnetwork.”

Why is the discrepancy?

Thanks,

Igor

---------------------------------
         [

---------------------------------
Sucker-punch spam with award-winning protection.
 Try the free Yahoo! Mail Beta.

---

From: [email-masked]
Date: Thu, 8 Mar 2007 22:23:21 +0100

igor

pls use version <draft-dimitri-ccamp-gmpls-ason-routing-ospf-02> (or 03 
when available to make comments)

in that version you will see in Section 5.2

" Note: The Link ID sub-TLV that identifies the other end of the link 
   (i.e. Router ID of the neighbor for point-to-point links) MUST 
   appear exactly once per Link TLV. This sub-TLV MUST be processed as 
   defined in [RFC3630]. "

now why this sub-TLV 17, well for the reason explained at the beginning of 
par.5.2
but also in RFC 4652 Section 5.7

hope this helps,
-d.

Igor Bryskin <[email-masked]>
08/03/2007 22:11
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked], "Brungard, Deborah A, ALABS" 
<[email-masked]>
        Subject:        Two questions on 
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

Dimitri,
 I have a couple questions wrt the 
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft.
In 5.2 a TE Link sub-TLV is introduced for the purpose of advertising 
local and remote TE Router ID:
 
  0                   1                   2                   3 
 
Although I do understand why there is a need for advertising the Local TE 
Router ID, I don’t understand why the Remote Te Router ID? Isn’t this is 
the same
 information 
that is carried in the Link ID sub-TLV?
In 6. you write:

In G.8080 I read:
“.... A routing area is defined by a set of subnetworks, the SNPP links 
that interconnect them, and the SNPPs representing the ends of the SNPP 
links exiting that routing area. A routing area may contain smaller 
routing areas interconnected by SNPP links. The limit of subdivision 
results in a routing area that contains ]one subnetwork.”
 
Why is the discrepancy?
 
Thanks,
Igor

 [

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 8 Mar 2007 15:03:06 -0800 (PST)

Dimitri, no, it does not help.

You didn't answer the first question, which is:

Is the LinkID is the same as Remote TE Router ID? If no, what is the difference? If yes, why do you need the latter? Both your pointers explain why do you need advertising of the local TE Router ID (advertising router may cover multiple data plane nodes), However, LinkID unambiguosly identifies remote data plane node, and the need for the advertising of Remote TE Router ID is not obvious

BTW, You didn't answer the second question either.

Igor

PS, I have a suggestion for the working group: Let us disallow responding to the comments/questions by just pointing to RFCs or drafts. In my view it is quite unfriendly. It is always possible to cut and paste a piece from the relevant RFC or draft confirming the points the writer is trying to make.

[email-masked] wrote: igor

pls use version  (or 03 

hope this helps,
-d.

Igor Bryskin 
08/03/2007 22:11

Dimitri,
 
  0                   1                   2                   3 

 
In G.8080 I read:
 
Why is the discrepancy?
 
Thanks,
Igor

 [

---------------------------------
Now that's room service! Choose from over 150,000 hotels 
in 45,000 destinations on Yahoo! Travel to find your fit.

---

From: [email-masked]
Date: Fri, 9 Mar 2007 00:10:24 +0100

igor,

> Is the LinkID is the same as Remote TE Router ID? 

no

> LinkID unambiguosly identifies remote data plane node,

no, it identifies the remote RC not the remote data plane "node" in case 
the remote RC is associate to n "nodes"

ps: second question is trivial, mathematical vs networking formulation (no 
real difference)

pps: if you want to put guidelines on e-mail responses probably directing 
your e-mail to the GEN AREA would be more suitable 

hope this helps,
-d.

09/03/2007 00:03
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked], "Brungard, Deborah A, ALABS" 
<[email-masked]>
        Subject:        Re: Two questions on 
draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

Is the LinkID is the same as Remote TE Router ID? If no, what is the 
difference? If yes, why do you need the latter? Both your pointers explain 
why do you need advertising of the local TE Router ID (advertising router 
may cover multiple data plane nodes), However, LinkID unambiguosly 
identifies remote data plane node, and the need for the advertising of 
Remote TE Router ID is not obvious

Igor

PS, I have a suggestion for the working group: Let us disallow responding 
to the comments/questions by just pointing to RFCs or drafts. In my view 
it is quite unfriendly. It is always possible to cut and paste a piece 
from the relevant RFC or draft confirming the points the writer is trying 
to make.

[email-masked] wrote:
igor

pls use version (or 03 

par.5.2

hope this helps,
-d.

Igor Bryskin 
08/03/2007 22:11

Dimitri,

0 1 2 3 

Although I do understand why there is a need for advertising the Local TE 
Router ID, I donâ€™t understand why the Remote Te Router ID? Isnâ€™t 
this is 
the same
information 
that is carried in the Link ID sub-TLV?
In 6. you write:

â€œA RA may contain smaller RAs inter-connected by links. 
The limit of the subdivision results in
a RA that contains two sub-networks interconnected by a single link.â€

In G.8080 I read:
â€œ.... A routing area is defined by a set of subnetworks, the SNPP links 

that interconnect them, and the SNPPs representing the ends of the SNPP 
links exiting that routing area. A routing area may contain smaller 
routing areas interconnected by SNPP links. The limit of subdivision 
results in a routing area that contains ]one subnetwork.â€

Why is the discrepancy?

Thanks,
Igor

[

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 9 Mar 2007 07:05:02 -0800 (PST)

Dimitri,

 no

 
 IB>> No, I disagree. You see that's why it's so important to quote the RFCs/drafts, because people often interpret them differently.
 
 In RFC 3630 we read:
 "
  
2.5.2.  Link ID

   The Link ID sub-TLV identifies the other end of the link.  For

   point-to-point links, this is the Router ID of the neighbor.

"

Note that it does not say whether this is the advertising Router ID 

(identifying neighbor RC) or TE Router ID (identifying the neighbor TE node). However, it does say that it &#8220;identifies the other end of the link&#8221;. Because a link is terminated by TE nodes (and not advertising routers) I conclude that LinkID identifies the remote TE node.

Furthermore, earlier in RFC 3630 we read:

&#8220;

2.4.1.  Router Address TLV

   The Router Address TLV specifies a stable IP address of the

   advertising router that is always reachable if there is any

   connectivity to it; this is typically implemented as a "loopback

   address".  The key attribute is that the address does not become

   unusable if an interface is down.  In other protocols, this is known

   as the "router ID"

I interpret that this is the same router ID as in the upper quote. It is advertised in the Router Address TLV, which is the only way today to advertise TE Router ID. Hence the router ID in the context of this RFC is the TE Router ID.

The conclusion #1: the TE Link TLV, as it is today, always contains the ID of the remote TE node. 

The conclusion #2: there is a need to advertise several TE Router IDs supported by the same RC (advertising router), which, I think, should be proposed in your draft

  IB>> Well, it changes one of the fundamental definitions of G.8080, and I am asking why is that in the draft which is supposed to define ways to support G.8080 
   
  Igor

 hope this helps,
 -d.

 
 Igor Bryskin 
 09/03/2007 00:03

 

 
 Igor

 pls use version (or 03 

 
 
 par.5.2
 
 hope this helps,
 -d.

 
 Igor Bryskin 
 08/03/2007 22:11

 Dimitri,
 
 0 1 2 3 

 
 In G.8080 I read:

 Why is the discrepancy?
 
 Thanks,
 Igor

 [

---

From: [email-masked]
Date: Fri, 9 Mar 2007 16:56:29 +0100

igor

the drafts says

"Note: The Link ID sub-TLV that identifies the other end of the link (i.e. 
Router ID of the neighbor for point-to-point links) MUST appear exactly 
once per Link TLV. This sub-TLV MUST be processed as defined in [RFC3630]. 
" 

which is exactly what you are saying - when i say "it identifies the 
remote RC not the remote data plane "node" in case the remote RC is 
associate to n nodes" read "it is set to the router_id that identifies the 
remote RC..."
in brief, we keep the semantic and add a discriminator (that does not 
apply in case of colocated 1:1 LSR) - this closes the first point -

concerning the second point, since there is a possibility to have multiple 
<Router_ID, TE Router_ID> associations in different LSAs i don't where the 
problem is ?

thanks,
-d.

09/03/2007 16:05

Dimitri,

no

IB>> No, I disagree. You see that's why it's so important to quote the 
RFCs/drafts, because people often interpret them differently.

In RFC 3630 we read:
"
2.5.2.  Link ID

"

(identifying neighbor RC) or TE Router ID (identifying the
 neighbor TE node). However, it does say that it “identifies the other end 
of the link”. Because a link is terminated by TE nodes (and not 
advertising routers) I conclude that LinkID identifies the remote TE node.
 
“
 
   unusable if an
 interface is down.  In other protocols, this is known
   as the "router ID"
 
I interpret that this is the same router ID as in the upper quote. It is 
advertised in the Router Address TLV, which is the only way today to 
advertise TE Router ID. Hence the router ID in the context of this RFC is 
the TE Router ID.
 
The conclusion #1: the TE Link TLV, as it is today, always contains the ID 
of the remote TE node. 
 
The conclusion #2: there is a need to advertise several TE Router IDs 
supported by the same RC (advertising router), which, I think, should be 
proposed in your draft

real difference)
 
IB>> Well, it changes one of the fundamental definitions of G.8080, and I 
am asking why is that in the draft which is supposed to define ways to 
support G.8080 
 
Igor

hope this helps,
-d.

Igor Bryskin 
09/03/2007 00:03

Igor

pls use version (or 03 

par.5.2

hope this helps,
-d.

Igor Bryskin 
08/03/2007 22:11

Dimitri,

0 1 2 3 

Although I do understand why there is a need for advertising the Local TE 
Router ID, I donÃ¢â‚¬â„¢t understand why the Remote Te Router ID? 
IsnÃ¢â‚¬â„¢t 
this is 
the same
information 
that is carried in the Link ID sub-TLV?
In 6. you write:

Ã¢â‚¬Å“A RA may contain smaller RAs inter-connected by links. 
The limit of the subdivision results in
a RA that contains two sub-networks interconnected by a single 
link.Ã¢â‚¬Â

In G.8080 I read:
Ã¢â‚¬Å“.... A routing area is defined by a set of subnetworks, the SNPP 
links 

that interconnect them, and the SNPPs representing the ends of the SNPP 
links exiting that routing area. A routing area may contain smaller 
routing areas interconnected by SNPP links. The limit of subdivision 
results in a routing area that contains ]one subnetwork.Ã¢â‚¬Â

Why is the discrepancy?

Thanks,
Igor

[

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Fri, 9 Mar 2007 11:33:42 -0600

Hi Igor,

To save Dimitri time on scanning G8080, I can quickly answer your 2nd question (if I determine it correctly as it is a long thread), you ask:
"In 6. you write:
A RA may contain smaller RAs inter-connected by links. The limit of the subdivision results in a RA that contains two sub-networks interconnected by a single link.
 
In G.8080 I read:
.... A routing area is defined by a set of subnetworks, the SNPP links that interconnect them, and the SNPPs representing the ends of the SNPP links exiting that routing area. A routing area may contain smaller routing areas interconnected by SNPP links. The limit of subdivision results in a routing area that contains one subnetwork.
Why is the discrepancy?"

And you continued to say in your follow up mail:
"IB>> Well, it changes one of the fundamental definitions of G.8080, and I 
am asking why is that in the draft which is supposed to define ways to 
support G.8080"

CCAMP has already agreed to update this definition to the new definition in the next version of the draft. CCAMP was informed via Q14/15's Liaison in November 2006 that the definition was changed. The draft used the definition of G.8080 (2001 and 2003). The definition was updated by an amendment in 2005 to the new definition which you reference. We did not receive any further details except to say that it was updated.

Deborah 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, March 09, 2007 10:56 AM
To: Igor Bryskin
Cc: [email-masked]; BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
Subject: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf 

igor

the drafts says

thanks,
-d.

Dimitri,

no

In RFC 3630 we read:
"
2.5.2.  Link ID

"

(identifying neighbor RC) or TE Router ID (identifying the
 neighbor TE node). However, it does say that it "identifies the other end 
of the link". Because a link is terminated by TE nodes (and not 
advertising routers) I conclude that LinkID identifies the remote TE node.

 

 

real difference)

Igor

hope this helps,
-d.

Igor Bryskin 
09/03/2007 00:03

Igor

pls use version (or 03 

par.5.2

hope this helps,
-d.

Igor Bryskin 
08/03/2007 22:11

Dimitri,

0 1 2 3 

Although I do understand why there is a need for advertising the Local TE 
Router ID, I donÃ¢â'¬â"¢t understand why the Remote Te Router ID? 
IsnÃ¢â'¬â"¢t 
this is 
the same
information 
that is carried in the Link ID sub-TLV?
In 6. you write:

Ã¢â'¬Å"A RA may contain smaller RAs inter-connected by links. 
The limit of the subdivision results in
a RA that contains two sub-networks interconnected by a single 
link.Ã¢â'¬Â

In G.8080 I read:
Ã¢â'¬Å".... A routing area is defined by a set of subnetworks, the SNPP 
links 

that interconnect them, and the SNPPs representing the ends of the SNPP 
links exiting that routing area. A routing area may contain smaller 
routing areas interconnected by SNPP links. The limit of subdivision 
results in a routing area that contains ]one subnetwork.Ã¢â'¬Â

Why is the discrepancy?

Thanks,
Igor

[

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 9 Mar 2007 10:13:19 -0800 (PST)

Thanks, that is exactly what I expected to hear.

Igor

"BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]> wrote: Hi Igor,

In G.8080 I read:

Deborah 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, March 09, 2007 10:56 AM
To: Igor Bryskin
Cc: [email-masked]; BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
Subject: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf 

igor

the drafts says

concerning the second point, since there is a possibility to have multiple 
 associations in different LSAs i don't where the 
problem is ?

thanks,
-d.

Igor Bryskin 

Dimitri,

no

In RFC 3630 we read:
"
2.5.2.  Link ID

"

 

 

real difference)

Igor

hope this helps,
-d.

Igor Bryskin 
09/03/2007 00:03

Igor

pls use version (or 03 

par.5.2

hope this helps,
-d.

Igor Bryskin 
08/03/2007 22:11

Dimitri,

0 1 2 3 

In G.8080 I read:

Why is the discrepancy?

Thanks,
Igor

[

---

From: "Ong, Lyndon" <[email-masked]>
Date: Fri, 9 Mar 2007 13:22:23 -0500

Hi Dimitri,

That was my understanding also, I don't see any issue with this.

Cheers,

Lyndon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, March 09, 2007 7:56 AM
To: Igor Bryskin
Cc: [email-masked]; Brungard, Deborah A, ALABS; [email-masked]
Subject: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf 

igor

the drafts says

"Note: The Link ID sub-TLV that identifies the other end of the link (i.e. 
Router ID of the neighbor for point-to-point links) MUST appear exactly once per Link TLV. This sub-TLV MUST be processed as defined in [RFC3630]. 
" 

which is exactly what you are saying - when i say "it identifies the remote RC not the remote data plane "node" in case the remote RC is associate to n nodes" read "it is set to the router_id that identifies the remote RC..."
in brief, we keep the semantic and add a discriminator (that does not apply in case of colocated 1:1 LSR) - this closes the first point -

concerning the second point, since there is a possibility to have multiple <Router_ID, TE Router_ID> associations in different LSAs i don't where the problem is ?

thanks,
-d.

Dimitri,

no

> LinkID unambiguosly identifies remote data plane node,

no, it identifies the remote RC not the remote data plane "node" in case the remote RC is associate to n "nodes"

In RFC 3630 we read:
"
2.5.2.  Link ID

"

 

 

real difference)

Igor

hope this helps,
-d.

Igor Bryskin 
09/03/2007 00:03

Igor

pls use version (or 03 

par.5.2

hope this helps,
-d.

Igor Bryskin 
08/03/2007 22:11

Dimitri,

0 1 2 3 

In G.8080 I read:

Why is the discrepancy?

Thanks,
Igor

[

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 9 Mar 2007 11:29:17 -0800 (PST)

Lyndon,
   
  Let me try to explain my point. 
   
  Basically, we have two solutions to address the situation when the relationship between a router controller and data plane switches (TE nodes or TE routers) are 1:N, that is, when a single controller manages multiple TE routers.
   
  Solution 1 (suggested in the draft):
   
  Each TE Link advertising is extended with Local/Remote TE Router IDs pair. In this case, what is in the LinkID sub-TLV is not important really.
   
  Solution 2 (mine)
   
  The Router Address TLV is extended to advertise all TE Router IDs controlled by the advertising controller as routable addresses. The TE Link TLV is extended to advertise the local TE Router ID. However, there is no need to advertise the remote TE Router ID, because this is the function of the existing LinkID sub-TLV, which is to identify the remote end of the advertised TE link &#8211; remote TE Router ID.
   
  Both these approaches solve the problem; however, an important question to answer is:
   
  Do we need the TE Router IDs to be routable addresses?

The answer is YES according to draft-ietf-ccamp-gmpls-addressing-05.txt. For example, if the network
 is built of unnumbered TE links, than ERO signaled in RSVP-TE Path will contain path in a form of TE_RtrID/ifIndex pairs, and having TE_RtrID routable solves the problem how to signal the Path message along the provisioned path..

If you agree with this, than you will also agree that all TE Router IDs should be advertised within Router Address TLV

Hope that this helps.

Igor

 "Ong, Lyndon" <[email-masked]> wrote:
  Hi Dimitri,

 Cheers,
 
 Lyndon 
 
 -----Original Message-----
 From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
 Sent: Friday, March 09, 2007 7:56 AM
 To: Igor Bryskin
 Cc: [email-masked]; Brungard, Deborah A, ALABS; [email-masked]
 Subject: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf 
 
 igor
 
 the drafts says

 
 concerning the second point, since there is a possibility to have multiple associations in different LSAs i don't where the problem is ?
 
 thanks,
 -d.

 Igor Bryskin 

 Dimitri,

 no

 
 
 In RFC 3630 we read:
 "
 2.5.2. Link ID

 
 
 "

 

 

 
 real difference)

 Igor

 hope this helps,
 -d.

 
 Igor Bryskin 
 09/03/2007 00:03

 

 
 
 Igor

 pls use version (or 03 

 

 par.5.2
 
 hope this helps,
 -d.

 
 Igor Bryskin 
 08/03/2007 22:11

 Dimitri,
 
 0 1 2 3 

 
 In G.8080 I read:

 Why is the discrepancy?
 
 Thanks,
 Igor

 [

 

 
---------------------------------
 Get your own web address.
 Have a HUGE year through Yahoo! Small Business.

---

From: [email-masked]
Date: Fri, 9 Mar 2007 21:58:55 +0100

igor 

but it doesn't solve the issue (and introduces different setting and 
processing of the link id value from rfc 3630) indeed, in ASON RC can be 
associated to multiple "nodes", each of these nodes can have overlapping 
id spaces (to identify the "links") 

for that reason the solution is that each TE link (top level) TLV has a 
new sub-TLV that associates the local and remote "node id" (the former and 
latter takes the TE Router ID as value)

it is the substance of what i have been pointing to you in my initial 
e-mail (see Section 5.2 but also in RFC 4652 Section 5.7: "the routing 
protocol MUST be able to disambiguate the advertised TE links so that they 
can be associated with the correct TE Router ID.")

-d.

09/03/2007 20:29
 
        To:     "Ong, Lyndon" <[email-masked]>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked], "Brungard, Deborah A, ALABS" 
<[email-masked]>, [email-masked]
        Subject:        RE: Two questions on 
draft-ietf-ccamp-gmpls-ason-routing-ospf

Lyndon,

Basically, we have two solutions to address the situation when the 
relationship between a router controller and data plane switches (TE nodes 
or TE routers) are 1:N, that is, when a single controller manages multiple 
TE routers.

Each TE Link advertising is extended with Local/Remote TE Router IDs pair. 
In this case, what is in the LinkID sub-TLV is not important really.
 
Solution 2 (mine)
 
The Router Address TLV is extended to advertise all TE Router IDs 
controlled by the advertising controller as routable addresses. The TE 
Link TLV is extended to advertise the local TE Router ID. However, there 
is no need to advertise the remote TE Router ID, because this is the 
function of the existing LinkID sub-TLV, which is to identify the remote 
end of the advertised TE link – remote TE Router ID.
 
Both these approaches solve the problem; however, an important question to 
answer is:

The answer is YES according to draft-ietf-ccamp-gmpls-addressing-05.txt. 
For example, if the network
 is built of unnumbered TE links, than ERO signaled in RSVP-TE Path will 
contain
 path in a form of TE_RtrID/ifIndex pairs, and having TE_RtrID routable 
solves the problem how to signal the Path message along the provisioned 
path..
If you agree with this, than you will also agree that all TE Router IDs 
should be advertised within Router Address TLV
Hope that this helps.
 
Igor

Cheers,

Lyndon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf 
Of [email-masked]
Sent: Friday, March 09, 2007 7:56 AM
To: Igor Bryskin
Cc: [email-masked]; Brungard, Deborah A, ALABS; 
[email-masked]
Subject: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf 

igor

the drafts says

" 

concerning the second point, since there is a possibility to have multiple 
associations in different LSAs i don't where the problem is ?

thanks,
-d.

Igor Bryskin 

Dimitri,

no

In RFC 3630 we read:
"
2.5.2. Link ID

"

of the remote TE node. 

real difference)

Igor

hope this helps,
-d.

Igor Bryskin 
09/03/2007 00:03

Igor

pls use version (or 03 

par.5.2

hope this helps,
-d.

Igor Bryskin 
08/03/2007 22:11

Dimitri,

0 1 2 3 

In G.8080 I read:

Why is the discrepancy?

Thanks,
Igor

[

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 9 Mar 2007 13:36:27 -0800 (PST)

Dimitri,

I don't see how we can manage the situation where TENodeIds are not unique. At the end of the day we must process EROs/RROs that are build
of TENodeID/TELinkID pairs. If TELinkID has node-scope and TENodeID is not unique, how then we can identify the specified link? So what do you suggest we put in each of these two fields?

-d.

Igor Bryskin 
 
        To:     "Ong, Lyndon" , Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked], "Brungard, Deborah A, ALABS" 
, [email-masked]
        Subject:        RE: Two questions on 
draft-ietf-ccamp-gmpls-ason-routing-ospf

Lyndon,

 

Solution 2 (mine)

 

Igor

"Ong, Lyndon"  wrote:
Hi Dimitri,

Cheers,

Lyndon 

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

igor

the drafts says

" 

thanks,
-d.

Igor Bryskin 

Dimitri,

no

In RFC 3630 we read:
"
2.5.2. Link ID

"

of the remote TE node. 

real difference)

Igor

hope this helps,
-d.

Igor Bryskin 
09/03/2007 00:03

Igor

pls use version (or 03 

par.5.2

hope this helps,
-d.

Igor Bryskin 
08/03/2007 22:11

Dimitri,

0 1 2 3 

In G.8080 I read:

Why is the discrepancy?

Thanks,
Igor

[

 

---------------------------------
8:00? 8:25? 8:40?  Find a flick in no time
 with theYahoo! Search movie showtime shortcut.

---

From: [email-masked]
Date: Sat, 10 Mar 2007 03:08:44 +0100

igor

not an issue of TE router ID uniqueness, without this additional sub-TLV, 
an unnumbered local id may not be unique per router_id, hence the addition 
of this sub-TLV (TE Router ID being unique per router_id) 

-d

09/03/2007 22:36
 
<[email-masked]>, "Ong, Lyndon" <[email-masked]>, 

Dimitri,

I don't see how we can manage the situation where TENodeIds are not 
unique. At the end of the day we must process EROs/RROs that are build
of TENodeID/TELinkID pairs. If TELinkID has node-scope and TENodeID is not 
unique, how then we can identify the specified link? So what do you 
suggest we put in each of these two fields?

-d.

Igor Bryskin 

Lyndon,

TE routers.

Solution 2 (mine)

answer is:

Igor

"Ong, Lyndon" wrote:
Hi Dimitri,

Cheers,

Lyndon 

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

igor

the drafts says

" 

remote RC..."

thanks,
-d.

Igor Bryskin 

Dimitri,

no

In RFC 3630 we read:
"
2.5.2. Link ID

"

of the remote TE node. 

real difference)

Igor

hope this helps,
-d.

Igor Bryskin 
09/03/2007 00:03

Igor

pls use version (or 03 

par.5.2

hope this helps,
-d.

Igor Bryskin 
08/03/2007 22:11

Dimitri,

0 1 2 3 

In G.8080 I read:
Ã¢â'¬Å".... A routing area is defined by a set of subnetworks, the 
SNPP 
links 

Why is the discrepancy?

Thanks,
Igor

[

---

From: Igor Bryskin <[email-masked]>
Date: Sat, 10 Mar 2007 05:10:45 -0800 (PST)

Dimitri,

But who said that linkID must be unique per routerID? Of course, not. It must be unique per TE Router ID. The fact that the same RC manages several TE RTRs does not change a thing. The paths are computed on the network TE graph, built of vertices (TE RTRs) interconnected by edges (TE links). TE links must be uniqely identifed either as numbered or unnumbered (combination of TERtrID and LinkID). How the links are advertised - by separate RCs, the same RC or via no RC (statically configured) - is of no importance.

Igor

-d

Igor Bryskin 
09/03/2007 22:36
 
, "Ong, Lyndon" , 

Dimitri,

-d.

Igor Bryskin 

Lyndon,

TE routers.

Solution 2 (mine)

answer is:

Igor

"Ong, Lyndon" wrote:
Hi Dimitri,

Cheers,

Lyndon 

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

igor

the drafts says

" 

remote RC..."

thanks,
-d.

Igor Bryskin 

Dimitri,

no

In RFC 3630 we read:
"
2.5.2. Link ID

"

of the remote TE node. 

real difference)

Igor

hope this helps,
-d.

Igor Bryskin 
09/03/2007 00:03

Igor

pls use version (or 03 

par.5.2

hope this helps,
-d.

Igor Bryskin 
08/03/2007 22:11

Dimitri,

0 1 2 3 

In G.8080 I read:

Why is the discrepancy?

Thanks,
Igor

[

 
---------------------------------
Don't get soaked.  Take a quick peek at the forecast 
 with theYahoo! Search weather shortcut.

---

From: [email-masked]
Date: Sat, 10 Mar 2007 14:44:01 +0100

igor 

the first sentence is the disconnect, per 3630 

"The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear 
exactly once."

" The Link ID sub-TLV identifies the other end of the link.  For
  point-to-point links, this is the Router ID of the neighbor."

you wrote

"TE links must be uniqely identifed either as numbered or unnumbered 
(combination of TERtrID and LinkID)."

this is totally incorrect, there is a local/remote sub-TLV defined for 
numbered TE links

in fact what the present document does is to define a sub-TLV to allow 
identification of unnumbered TE links (associated to the TE router ID 
rather than the Router ID)

thanks,
-d.

10/03/2007 14:10

Dimitri,

But who said that linkID must be unique per routerID? Of course, not. It 
must be unique per TE Router ID. The fact that the same RC manages several 
TE RTRs does not change a thing. The paths are computed on the network TE 
graph, built of vertices (TE RTRs) interconnected by edges (TE links). TE 
links must be uniqely identifed either as numbered or unnumbered 
(combination of TERtrID and LinkID). How the links are advertised - by 
separate RCs, the same RC or via no RC (statically configured) - is of no 
importance.

Igor

-d

Igor Bryskin 
09/03/2007 22:36

Dimitri,

-d.

Igor Bryskin 

Lyndon,

TE routers.

Solution 2 (mine)

end of the advertised TE link â€“ remote TE Router ID.

answer is:

Igor

"Ong, Lyndon" wrote:
Hi Dimitri,

Cheers,

Lyndon 

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

igor

the drafts says

" 

remote RC..."

thanks,
-d.

Igor Bryskin 

Dimitri,

no

In RFC 3630 we read:
"
2.5.2. Link ID

"

of the remote TE node. 

real difference)

Igor

hope this helps,
-d.

Igor Bryskin 
09/03/2007 00:03

Igor

pls use version (or 03 

par.5.2

hope this helps,
-d.

Igor Bryskin 
08/03/2007 22:11

Dimitri,

0 1 2 3 

Although I do understand why there is a need for advertising the Local TE 
Router ID, I donÃƒÂ¢Ã¢'Â¬Ã¢"Â¢t understand why the Remote Te 
Router ID? 
IsnÃƒÂ¢Ã¢'Â¬Ã¢"Â¢t 
this is 
the same
information 
that is carried in the Link ID sub-TLV?
In 6. you write:

ÃƒÂ¢Ã¢'Â¬Ã…"A RA may contain smaller RAs inter-connected by 
links. 
The limit of the subdivision results in
a RA that contains two sub-networks interconnected by a single 
link.ÃƒÂ¢Ã¢'Â¬Ã‚Â

In G.8080 I read:
ÃƒÂ¢Ã¢'Â¬Ã…".... A routing area is defined by a set of 
subnetworks, the 
SNPP 
links 

that interconnect them, and the SNPPs representing the ends of the SNPP 
links exiting that routing area. A routing area may contain smaller 
routing areas interconnected by SNPP links. The limit of subdivision 
results in a routing area that contains ]one 
subnetwork.ÃƒÂ¢Ã¢'Â¬Ã‚Â

Why is the discrepancy?

Thanks,
Igor

[

---

From: Igor Bryskin <[email-masked]>
Date: Sat, 10 Mar 2007 13:26:23 -0800 (PST)

Dimitri,

I probably do not make myself clear, but you don't seem to see what I am saying. Let's continue the discussion in Prague. Hoefully, we will also hear what the authors of RFC3630 have to say.

See you soon,
Igor

you wrote

thanks,
-d.

Igor Bryskin 
10/03/2007 14:10

Dimitri,

Igor

-d

Igor Bryskin 
09/03/2007 22:36

Dimitri,

-d.

Igor Bryskin 

Lyndon,

TE routers.

Solution 2 (mine)

answer is:

Igor

"Ong, Lyndon" wrote:
Hi Dimitri,

Cheers,

Lyndon 

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

igor

the drafts says

" 

remote RC..."

thanks,
-d.

Igor Bryskin 

Dimitri,

no

In RFC 3630 we read:
"
2.5.2. Link ID

"

of the remote TE node. 

real difference)

Igor

hope this helps,
-d.

Igor Bryskin 
09/03/2007 00:03

Igor

pls use version (or 03 

par.5.2

hope this helps,
-d.

Igor Bryskin 
08/03/2007 22:11

Dimitri,

0 1 2 3 

In G.8080 I read:

Why is the discrepancy?

Thanks,
Igor

[

 
---------------------------------
TV dinner still cooling?
Check out "Tonight's Picks" on Yahoo! TV.

---

From: "Zafar Ali \(zali\)" <[email-masked]>
Date: Sun, 18 Mar 2007 21:28:42 -0400

Dear Dimitri- 

Thanks for your comments and sorry for the delay in replying. Please see
in-line. 

Thanks

Regards... Zafar  

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Wednesday, March 07, 2007 7:28 PM
> To: Zafar Ali (zali)
> Cc: Adrian Farrel; Anca Zamfir (ancaz); [email-masked]; 
> Brungard, Deborah A, ALABS; Jean Philippe Vasseur (jvasseur); 
> [email-masked]
> Subject: Re: Next steps for 
> o) would it be possible to sum'up changes you have been 
> provided since so far ?
> 

Dimitri- 

The delta was to mainly addresses comments received. The major comments
were (quoting from respective email): 

"- not sure to understand why the PathErr/Notify can be processed by the

head-end only (what about segment recovery and stitching case) - why
only 
MBB is possible upon reception (pls use E2E recovery/Segment recovery 
capabilities as you address GMPLS networks)".

How this comment is addressed:

Re: segment recovery and stitching case, definition of the node that can
perform GS procedure has been extended to include Ingress LSR of an
S-LSP. See enclosed slides for details.

Re: why only MBB is possible upon reception. 

Text in the new version is modified such that it allows the following- 

- Graceful shutdown may be exercised using make-before-break or FRR/
segment recovery procedure. 
- When PLR/ branch node receive a Path Error with Graceful Shutdown
indication, 
  	o It MUST forward the Path Error to the Ingress node.
  	O Based on a local decision, PLR/ branch node MAY trigger FRR/
segment recovery.

"- in case shutdown of a protected component link (of a bundle) is 
initiated why can't link protection be used ?"

How this comment is addressed:

Based on a local decision, PLR/ branch node MAY trigger FRR/ segment
recovery to recover from failure of a component link. 

"- compared to path-reopt, error description is identical for the TE
link 
case which leads to the following point - if errors code/value are the 
same how to distinguish them"

This ID inherits the Ingress behavior from RFC 4736, which says, "Upon
receiving an RSVP PERR message with Error code 25 and Error sub- code 7
(Local link maintenance required) or 8 (Local node maintenance
required), the Head-end LSR SHOULD perform a TE LSP reoptimization". 
This drafts extends the handling of this error code/ sub-code at PLR/
branch node (which includes the case where  ingress node is PLR/ branch
node). IMO no need for adding a new perr subcode.  

> afaik you don't shutdown LSPs but Links - right ?

This is correct. We will change the wording to make it clear. 

> http://www3.ietf.org/proceedings/06nov/slides/ccamp-17/sld1.ht
> m, we have addressed all outstanding comments, except the 
> following comment from Dimitri, related to this ID. Should 
> you have any further comment, please share. 
>  
> The only remaining comment that is not closed is "should this 
> ID be informational or standard track". IMO the ID defines a 
> new error-subcode and some specific behavior, and should be 
> standard track. Can you please comment on this. 
>  
> The ID has been stable for quite some time and following the 
> closure of the above, we would like to request last call. 
>  
> Thanks
>  
> Regards... Zafar  
>