Subject: Re: [CCAMP] I-D Action: draft-fuxh-ccamp-boundary-explicit-control-ext-03.txt

From: [email-masked]
Date: Wed, 20 Jul 2011 12:15:20 +0800

Hi All,

We updated this draft. 
We added some new sections, suchs as the "requirement identification" and 
"boundary nodes determination mechanism".
Some content are related to OTN multi-layer scenarios.
If you review and have some comments, pls let us know.

Xihua

[email-masked] 
发件人:  [email-masked]
2011-07-08 下午 07:54
请答复 给
[email-masked]

收件人
[email-masked]
抄送

主题
I-D Action: draft-fuxh-ccamp-boundary-explicit-control-ext-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

                 Title           : RSVP-TE Extension for MRN/MLN 
Application
                 Author(s)       : Xihua Fu
                          Qilei Wang
                          Yuanlin Bao
                          Ruiquan Jing
                          Xiaoli Huo
                 Filename        : 
draft-fuxh-ccamp-boundary-explicit-control-ext-03.txt
                 Pages           : 16
                 Date            : 2011-07-08

   [RFC5212] defines a Multi-Region and Multi-Layer Networks (MRN/MLN).
   [RFC4206] introduces a region boundary determination algorithm and a
   Hierarchy LSP (H-LSP) creation method.  However, in some scenarios,
   there must be some additional information to facilitate hierarchy LSP
   creation.  This document extends RSVP-TE to meet this requirement.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-fuxh-ccamp-boundary-explicit-control-ext-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-fuxh-ccamp-boundary-explicit-control-ext-03.txt

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 20 Jul 2011 16:55:35 +0200

Hi Xihua,

I read the draft and I found it , as the first time, very interesting but a little unclear in some points.
Chapter 2.2.1
You say that boundary node “could” not determine which kind of ODUk FA-LSP should be triggered but you do not put any brief explanation of that. I think for completeness some words should be usefull.

Chapter 3.2.1
Not clear the sentence about L bit : MUST be included vs. SHOULD be included . I suppose you mean SHOULD not be included , Correct ?

Chapter 3.2.3
In chapter 3.2 you mention the possibility by ERBO to signal : FA nodes end points, and FA/component link.
Is the signal type sub-object devoted to this second scope ? I f yes, why named it explicitly (e.g. FA signal type ) and not just signal type , that is a little misleading. I would avoid the terms sub-layers already discusse in the mailing list since there is a different terminology and meaning for that in ITU. Let’s say level multiplexing or something along this lines.

Chapter 3.2.5
Not clear the sentence related to ERO : “If it is necessary , it must also extract the server layer/sub-layer routing information form ERO based on a pair of node. “ Could you clarify .

Chapter 3.3.1 and others :
L bit field : again the is the sentence Must be excluded vs Should be avoided . I do not believe a good idead permit anyway to use one resource that I’m considering to be excluded . I mean: it implies in case the SHOULD usage an interworking problem, right ?

Thanks

Sergio

________________________________
Da: [email-masked] [mailto:[email-masked]] Per conto di [email-masked]
Inviato: mercoledì 20 luglio 2011 6.15
A: [email-masked]
Oggetto: Re: [CCAMP] I-D Action: draft-fuxh-ccamp-boundary-explicit-control-ext-03.txt

Hi All,

We updated this draft.
We added some new sections, suchs as the "requirement identification" and "boundary nodes determination mechanism".
Some content are related to OTN multi-layer scenarios.
If you review and have some comments, pls let us know.

Xihua

[email-masked]

2011-07-08 下午 07:54
请答复 给
[email-masked]

收件人

[email-masked]

抄送

主题

A New Internet-Draft is available from the on-line Internet-Drafts directories.

                Title           : RSVP-TE Extension for MRN/MLN Application
                Author(s)       : Xihua Fu
                         Qilei Wang
                         Yuanlin Bao
                         Ruiquan Jing
                         Xiaoli Huo
                Filename        : draft-fuxh-ccamp-boundary-explicit-control-ext-03.txt
                Pages           : 16
                Date            : 2011-07-08

---

From: [email-masked]
Date: Thu, 21 Jul 2011 22:26:29 +0800

Hi Sergio,

Thank you for your comments.
Following is my response. 
Hope them be clear for your confuse.

Xihua

"BELOTTI, SERGIO (SERGIO)" <[email-masked]> wrote 
2011-07-20 PM 10:55:35:

> Hi Xihua,
> 
> I read the draft and I found it , as the first time, very 
> interesting but a little unclear in some points.
> Chapter 2.2.1
> You say that boundary node “could” not determine which kind of ODUk 
> FA-LSP should be triggered but you do not put any brief explanation 
> of that. I think for completeness some words should be usefull.
> 
[Xihua]: Agree. We will add some supplement for this point.
If there is no any explicite ODUk signal type indication in signal message 
or local configuration,
boundary node don't know which type of FA-LSP should be triggered.
In a word, as lack of explicite information, so boundary node (e.g., B) 
could not determine 
which kind of ODUk FA-LSP should be triggered for e2e ODU0 LSP.

> Chapter 3.2.1 
> Not clear the sentence about L bit : MUST be included vs. SHOULD be 
> included . I suppose you mean SHOULD not be included , Correct ?
> 
[Xihua]: No, it isn't.
Sometime, source node may not completely control the whole e2e LSP 
creation.
It may indicate there are several choices for boundary node to select. 
Source node has to indicate they should be included rather than "must" 
during signaling.
So boundary node may select one of choices.
That's why we define two value of L bit. 
"Must" means there is only one choice.
If there are several choices, for each element, it "should" be included.

> Is the signal type sub-object devoted to this second scope ? I f 
> yes, why named it explicitly (e.g. FA signal type ) and not just 
> signal type , that is a little misleading. I would avoid the terms 
> sub-layers already discusse in the mailing list since there is a 
> different terminology and meaning for that in ITU. Let’s say level 
> multiplexing or something along this lines.
> 
[Xihua]: The signal type is used in OTN/SDH multi-layer network. 
It is used to explicity inform boundary node which ODUk or STM-x FA-LSP 
should be triggered for ODUj LSP (k>j).
In this case, ERBO will include a pair of boundary nodes and signal type.
For example, in the following figure, ODU3 or ODU2 FA-LSP could be for 
ODU0 LSP.
If PCE determine ODU3 must be used for ODU0, there is a ERBO in path 
message including node B, ODU3 signal type and node E.
So ODU3 FA-LSP should be triggered or ODU3 FA TE link should be selected.
|--------------------ODU0 LSP------------------|
A                      B                                E       F
o--------------o                                o--------------o
                            \                            /
                              o---------------o
                              C                        D
                         |------ODU3-------|
                         |------ODU2-------|

We will avoid using sub-layers in the next version draft.

> Chapter 3.2.5
> Not clear the sentence related to ERO : “If it is necessary , it 
> must also extract the server layer/sub-layer routing information 
> form ERO based on a pair of node. “ Could you clarify . 
> 
[Xihua]:  Based on the previous figure, ERO in path message includes 
A-B-C-D-E-F and associated interfaces. 
ERBO in path message includes node B, ODU3 signal type and node E. 
When intermidate node (i.e., B) receives path message, it will know it is 
a real boundary node of ODU3 FA-LSP in terms of ERBO.
After node B determine other edge (i.e., E) of FA-LSP, 
it will extract the routing information (i.e., B-C-D-E) from ERO to 
trigger ODU3 FA-LSP creation.

> L bit field : again the is the sentence Must be excluded vs Should 
> be avoided . I do not believe a good idead permit anyway to use one 
> resource that I’m considering to be excluded . I mean: it implies in
> case the SHOULD usage an interworking problem, right ?
> 
[Xihua]: L bit in this draft inherits from rfc4874 and rfc6001. 
Please refer to the section  "3.1.  EXCLUDE_ROUTE Object (XRO)" in 
rfc4874.
"...to indicate that an abstract node MUST be excluded (value 0) or SHOULD 
be avoided (value 1).
The distinction is that the path of an LSP must not traverse an abstract 
node listed in the XRO with
the L bit clear, but may traverse one with the L bit set. 
"

> We added some new sections, suchs as the "requirement 
> identification" and "boundary nodes determination mechanism". 

Application